Re: LTS and release methodology
2008/7/10 Matt Zimmerman <[EMAIL PROTECTED]>: > On Thu, Jul 10, 2008 at 10:13:00AM +0200, Krzysztof Lichota wrote: >> Well, IMO in most cases this would require just creation of >> appropriate packaging process and appropriate build tools. Build >> systems already support installing to different directory prefixes, >> with prefixes/suffixes to binary names, etc. > > Some build systems do, some don't. The only ones we would have to care about are the build systems for major apps: Firefox, Openoffice, etc. I guess they have such abilities. >> And I don't think this would require linear time. It would be one-time >> job to convert it and then the maintenance would be the same. So the >> tradeoff would be to make current version "mediocre". But to really >> tell it, we would have to start an experiment and try it. > > Indeed. If you believe that some one-time work will solve your problem, you > are in an ideal position to test this. OK, I will try to test it. Given my poor packaging skills and little spare time it will take much longer than if it was done by person who already knows application packaging/build system. >> > It is generally possible to keep obsolete packages installed after an >> > upgrade, so there's no forced upgrade here. However, the packages from >> > 6.06 >> > won't receive maintenance updates on 8.04. >> >> If you install OpenOffice from Hardy, you cannot keep the one from >> Dapper. > > No, but you were talking about PostgreSQL, where you can. But only because it supports multiple parallel versions. So I guess you support my point that parallel versions are useful? >> And I really don't think the one from Dapper would work on Hardy. > > I would be surprised if it stopped working. I will check it. >> Maybe this version in newer LTS should get "limited transition support" >> which ends when the support for older LTS ends. This way security fixes >> from older LTS would be simply forward-ported to newer LTS. > > It is already more complex than we would like for users and administrators > to understand which packages on their system receive maintenance and > support, and which don't. The idea of LTS is that one can deploy the system > and not think about it too much for a few years. Adding "time bombs" where > certain applications start to reach end-of-life earlier than others would > complicate what is presently a simple cycle to understand. Simple notification popup "Your OpenOffice 2.3 reaches end of lifecycle next month" would be doable and simple. Sending e-mail to customers would be even simpler. Limited transition support packages would be targeted at IT departments and are added value for transition periods, so I think IT departments would be aware how they have to handle end of lifecycle announcements. >> No additional security-related effort would be needed. > > First of all, porting changes to different versions of a package is real > work. Second, security updates are semi-automatically deployed to millions > of Ubuntu systems and need to be regression tested before being released. > Don't be fooled by the fact that they are available for free; this is not a > trivial service. It is not porting security changes, it is backporting security-fixed package again. Example from my Firefox packages: I am taking Firefox 2.0.0.14 from Feisty and backporting it to Dapper. When security update (Firefox 2.0.0.15) appears I am not taking security fixes and apply it to 2.0.0.14. Instead I am taking Firefox 2.0.0.15 from Feisty again and backport it to Dapper. It is much simpler (but of course it also requires regression testing). I am aware it is not always possible with each application and lifecycles might come into play, but it is possible for some apps. >> You must anyway ask which version of _Ubuntu_ user is using. And I >> think it is even harder to get this information, it is not in any way >> obvious to user. > > System->About Ubuntu. Slow to start, but discoverable enough. Novice user would not find it. And on Kubuntu it is even harder. Anyway, asking app version is equally difficult and can be guided by helpdesk person the same way. >> This is what IT departments define. Users would mostly use >> "OpenOffice" (the default set by IT department) unless support/power >> users would tell them to use other version. > > The vast majority of Ubuntu users don't have an IT department supporting > them. The development team must make sensible choices on their behalf. Yes, so the defaults would be the same as now. Nothing changes. Except from the fact that when default application version does not work, user can get to know on support forums/blogs/etc. how to run/install alternate version and not get one of the responses he gets currently: a) Install previous distribution release b) Wait for next distribution release c) Wait for fix (which might never come) All of them require significant changes and take significant time, while users expect they can do the job immediate
Re: LTS and release methodology
2008/7/10 Mario Vukelic <[EMAIL PROTECTED]>: > On Thu, 2008-07-10 at 10:15 +0200, Krzysztof Lichota wrote: >> The main point is that it is possible >> (and easy) to install Firefox 3 on Windows XP (released 2001), while >> try to install Firefox 3 on Dapper (released 2006). > > FWIW: download from firefox.com, unpack, run installer. Granted, it is > not under the control of the package manager in this case, but neither > is it in Windows (which lacks one altogether). Try it and you will see why it does not work. Firefox 3 requires GTK 2.10 which is not present in Dapper. -- Krzysztof Lichota -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: LTS and release methodology
On Thu, 2008-07-10 at 18:14 +0200, Mario Vukelic wrote: > FWIW: download from firefox.com <- nothing As was pointed out to me, FF3 needs gtk+ 2.10, which is not in Dapper. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Patch for xkb-data - Tamil99 Keyboard
Hi,
xkb-data has this mailing list as the Maintainer, hence sending the patch
here.
Purpose: Add Tamil99 keyboard
Tamil99 is the officially approved keyboard layout by regional government of
Tamilnadu (http://www.tamilvu.org/Tamilnet99/keystand.htm).
This layout is currently not part of the xkb-data package. This patch
implements only the layout recommendation without additional
key sequence suggestions. Implementation is fully functional (i.e., will
output all required characters) without these.
Please let me know if I need to approach anyone else for inclusion of this
patch, and whether I need to submit it upstream.
Thank you,
Sivaraj
diff -Naur old/rules/base.lst new/rules/base.lst
--- old/rules/base.lst 2008-07-12 19:09:38.0 +0530
+++ new/rules/base.lst 2008-07-12 16:18:20.0 +0530
@@ -276,6 +276,7 @@
tam_TAB in: Tamil TAB Typewriter
tam_TSCII in: Tamil TSCII Typewriter
tam in: Tamil
+ tamil99 in: Tamil 99 Pseudo
tel in: Telugu
urd in: Urdu
bolnagriin: Hindi Bolnagri
diff -Naur old/rules/base.xml new/rules/base.xml
--- old/rules/base.xml 2008-07-12 19:10:16.0 +0530
+++ new/rules/base.xml 2008-07-12 16:20:29.0 +0530
@@ -1380,6 +1380,12 @@
+tamil99
+Tamil 99 Pseudo
+
+
+
+
tel
Telugu
diff -Naur old/symbols/in new/symbols/in
--- old/symbols/in 2008-07-12 16:13:48.0 +0530
+++ new/symbols/in 2008-07-12 19:06:31.0 +0530
@@ -901,6 +901,73 @@
key { [ 0x1de, 0x1df ] };
};
+
+partial alphanumeric_keys
+xkb_symbols "tamil99" {
+// Tamil99 Phonetic layout for Tamil using Unicode
+// Author: Sivaraj D <[EMAIL PROTECTED]>
+// Date: 12 July 2008
+// See layout at http://www.tamilvu.org/Tamilnet99/keysta.htm
+// * This layout doesn't support additional intelligence as defined in
+// Annexure 2 because, (1) XKB doesn't support such intelligence,
+// (2) Often it is desirable to have a keyboard without such intelligence
+// * This layout doesn't support SHRI & KSHA - these ligatures should be
+// formed using their component characters (SHA +pulli +RA +Vowel sign I
+// & KA + pulli + SSA respectively)
+
+name[Group1]= "Tamil99";
+
+key { [ grave, asciitilde ] };
+key { [ 1, exclam ] };
+key { [ 2, at ] };
+key { [ 3, numbersign ] };
+key { [ 4, dollar ] };
+key { [ 5, percent ] };
+key { [ 6, asciicircum ] };
+key { [ 7, ampersand ] };
+key { [ 8, asterisk ] };
+key { [ 9, parenleft ] };
+key { [ 0, parenright ] };
+key { [ minus, underscore ] };
+key { [ equal, plus ] };
+
+key { [ U0BBE, U0B86, U0BB8 ] };
+key { [ U0BC0, U0B88, U0BB7 ] };
+key { [ U0BC2, U0B8A, U0B9C ] };
+key { [ U0BC8, U0B90, U0BB9 ] };
+key { [ U0BC7, U0B8F, U0BB6 ] };
+key { [ U0BB3, NoSymbol ] };
+key { [ U0BB1, NoSymbol ] };
+key { [ U0BA9, NoSymbol ] };
+key { [ U0B9F, bracketleft ] };
+key { [ U0BA3, bracketright ] };
+key { [ U0B9A, braceleft ] };
+key { [ U0B9E, braceright] };
+
+key { [ U0B85, U0B85, U0BF9 ] };
+key { [ U0BBF, U0B87, U0BFA ] };
+key { [ U0BC1, U0B89, U0BF8 ] };
+key { [ U0BCD, U0B83 ] };
+key { [ U0BC6, U0B8E ] };
+key { [ U0B95, NoSymbol ] };
+key { [ U0BAA, NoSymbol ] };
+key { [ U0BAE, quotedbl ] };
+key { [ U0BA4, colon ] };
+key { [ U0BA8, semicolon ] };
+key { [ U0BAF, apostrophe] };
+
+key { [ U0BCC, U0B94, U0BF3 ] };
+key { [ U0BCB, U0B93, U0BF4 ] };
+key { [ U0BCA, U0B92, U0BF5 ] };
+key { [ U0BB5, NoSymbol, U0BF6 ] };
+key { [ U0B99, NoSymbol, U0BF7 ] };
+key { [ U0BB2, NoSymbol ] };
+key { [ U0BB0, slash ] };
+key { [ comma, less ] };
+key { [ period, greater ] };
+key { [ U0BB4, question ] };
+};
+
partial alphanumeric_keys
xkb_symbols "tel" {
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Patch for xkb-data - Tamil99 Keyboard
On Sat, Jul 12, 2008 at 7:44 PM, Sivaraj D <[EMAIL PROTECTED]> wrote: > Hi, > > xkb-data has this mailing list as the Maintainer, hence sending the patch > here. > > Purpose: Add Tamil99 keyboard > Tamil99 is the officially approved keyboard layout by regional government > of Tamilnadu (http://www.tamilvu.org/Tamilnet99/keystand.htm). > This layout is currently not part of the xkb-data package. This patch > implements only the layout recommendation without additional > key sequence suggestions. Implementation is fully functional (i.e., will > output all required characters) without these. > > Please let me know if I need to approach anyone else for inclusion of this > patch, and whether I need to submit it upstream. > Hi, Glad to see your mail. I request you to consider joining Ubuntu tamil Team mailing list. So that we can discuss the same and do the needful. https://lists.ubuntu.com/mailman/listinfo/ubuntu-l10n-tam -- Regards, Sri Ramadoss M -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
