Re: LTS and release methodology
2008/7/9 Matt Zimmerman <[EMAIL PROTECTED]>: > On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote: >> It is a lot of effort, but if we want to compete with Windows, which >> makes it possible (and easy), it should be done. > > As far as I'm aware, Windows provides no tools or infrastructure to make > this easier. It is completely up to the ISV how their software is > installed, and many of them detect an existing installation and upgrade it > rather than install in parallel. Every application does it differently. Yes, some do not allow parallel versions, but many do. But at least they allow installing different versions without hassle. Linux users must jump through the hoops if they need OpenOffice 2.4 on Dapper which has 2.0. The argument about ISV doing their packaging in this way is void (at least for FOSS software) as in Ubuntu, Ubuntu packagers are doing packaging, not ISVs. It is not a question how it is done, but that it is possible (and easy) to install various versions of apps. To the point that it is easier to explain user how to run Firefox 3 through Wine on Dapper than to explain him how to get it running on Ubuntu itself. >> BTW. It is already done for example for PostgreSQL - Dapper has >> packages for PostgreSQL 7.4, 8.0 and 8.1. They can coexist and run >> along each other. User chooses which package to install and then which >> versions to run. >> >> I know Postgres is not desktop package, but it shows it is possible to do. > > No one would argue that it is impossible, but with the current tools, it is > done at a linear increase in developer effort. Ubuntu developers can much > more effectively spend their limited time making one version very good than > making two versions mediocre. 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. 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. >> The problem is that Dapper ships PostgreSQL 7.4, 8.0 and 8.1 while Hardy, >> next LTS release ships 8.2 and 8.3. So there is no way for smooth >> transition from Dapper to Hardy by upgrading database for example to 8.1, >> switching to Hardy and upgrading further. This is the "functionality >> overlap" I was talking about. > > 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. And I really don't think the one from Dapper would work on Hardy. > Providing 10 years of support for an old version of PostgreSQL to support > this use case would not be a wise choice. 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. No additional security-related effort would be needed. >> I don't think it is a big deal. You can ask what version of application >> person is running. Helpdesks all around the world do it all the time. > > They do, and it works reasonably well because the user generally only has > one version of the application. In many corporations there are different versions for example of Word. To get to know which version of application it is you just have to ask user to go to Help->About. 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. >> > and the question "do I have the necessary security updates installed?" >> > no longer has a simple answer. >> >> Why not? If someone has necessary repositories installed, the answer >> is very simple. Provided that security fixes go to the same repository >> as application which is installed. > > You miss my point. Implicit in your proposal is a need for twice as many > security updates. Where do you think these updates would come from? They > do not fall from the sky. You must maintain security fixes for newer packages anyway in newer versions of Ubuntu. You backport package from newer version together with security fixes. I am doing this all the time - yesterday I have backported Firefox 2.0.0.15 to my Firefox 2 repository (http://ola-os.com/addons/pool/dapper/firefox2/ ). >> > Which version of OpenOffice should launch when you click on a document >> > in Firefox? >> >> The default. > > The default version should be the default? Simple enough. :-) The default depends on company/person policy. If you run an application, for example click on OpenDocument file, you should hav
Re: LTS and release methodology
2008/7/9 Mackenzie Morgan <[EMAIL PROTECTED]>: > On Wed, Jul 9, 2008 at 3:47 AM, Krzysztof Lichota <[EMAIL PROTECTED]> wrote: >> It is a lot of effort, but if we want to compete with Windows, which >> makes it possible (and easy), it should be done. > > Er, not really. You can't have FF2 and FF3 or IE6 and IE7 both > installed on Windows, or if it is somehow possible, it's certainly not > easy. Maybe, it has been really long time since I last used Windows. But I remember it was possible for some applications. This is secondary point, though. 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). -- 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
LTS and release methodology
I think resume of all this is very clear - avoid regressions at any costs. You don't need two versions of OO.o if newest one works as old one (except bugs of course) and features works as they supposed to be. All this can be achieved with careful testing (using spec-like test cases) and spotlighting such bugs early in development cycle so they can be fixed in time. 2008/7/10 Krzysztof Lichota <[EMAIL PROTECTED]>: > 2008/7/9 Matt Zimmerman <[EMAIL PROTECTED]>: >> On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote: >>> It is a lot of effort, but if we want to compete with Windows, which >>> makes it possible (and easy), it should be done. >> >> As far as I'm aware, Windows provides no tools or infrastructure to make >> this easier. It is completely up to the ISV how their software is >> installed, and many of them detect an existing installation and upgrade it >> rather than install in parallel. Every application does it differently. > > Yes, some do not allow parallel versions, but many do. > But at least they allow installing different versions without hassle. > Linux users must jump through the hoops if they need OpenOffice 2.4 on > Dapper which has 2.0. Non-existance of Windows installing system is nightmare for admins and fact that many installators are clearly broken and allow two different versions is not a feature. It is bug. Actually it is biggest issue why Windows tends to be unstable after myriads of installs and uninstalls of different software. > The argument about ISV doing their packaging in this way is void (at > least for FOSS software) as in Ubuntu, Ubuntu packagers are doing > packaging, not ISVs. ISV can do packaging without big problems, if they know how to do it. Skype has never been a problem for me. It has deb and it installs perfectly. Maybe someone could create superduper packaging service for ISV for cheap money. > It is not a question how it is done, but that it is possible (and > easy) to install various versions of apps. To the point that it is > easier to explain user how to run Firefox 3 through Wine on Dapper > than to explain him how to get it running on Ubuntu itself. Firefox is not the best example, because a) download tar.gz, b) extract it via gui in home directory, c) create link. Vola! Why you would want them to install it via Wine is beyond my understanding. >>> BTW. It is already done for example for PostgreSQL - Dapper has >>> packages for PostgreSQL 7.4, 8.0 and 8.1. They can coexist and run >>> along each other. User chooses which package to install and then which >>> versions to run. >>> >>> I know Postgres is not desktop package, but it shows it is possible to do. >> >> No one would argue that it is impossible, but with the current tools, it is >> done at a linear increase in developer effort. Ubuntu developers can much >> more effectively spend their limited time making one version very good than >> making two versions mediocre. Having different versions of server programs is understandable, because they sometimes differ greatly in features and working principles. However, newer desktop app usually should support data from old app. Of course it is not always so, but we should try to achieve that. Multiple versions of OpenOffice.org won't create better desktop, it will mess it up. It is short term vision which is not worth to implement because for now everyone can download .tar.gz and extract it in home directory and run it. I think one version policy is what make open source/free software desktop so great. It is foundation and you shall build upon it. Mess with regressions, don't mess with apps. Just my two cents, Peter. -- 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, Jul 10, 2008 at 10:13:00AM +0200, Krzysztof Lichota wrote: > 2008/7/9 Matt Zimmerman <[EMAIL PROTECTED]>: > > As far as I'm aware, Windows provides no tools or infrastructure to make > > this easier. It is completely up to the ISV how their software is > > installed, and many of them detect an existing installation and upgrade it > > rather than install in parallel. Every application does it differently. > > Yes, some do not allow parallel versions, but many do. > But at least they allow installing different versions without hassle. > Linux users must jump through the hoops if they need OpenOffice 2.4 on > Dapper which has 2.0. > > The argument about ISV doing their packaging in this way is void (at > least for FOSS software) as in Ubuntu, Ubuntu packagers are doing > packaging, not ISVs. > > It is not a question how it is done, but that it is possible (and > easy) to install various versions of apps. To the point that it is > easier to explain user how to run Firefox 3 through Wine on Dapper > than to explain him how to get it running on Ubuntu itself. It is possible (and easy) to install multiple versions of applications which are packaged that way. Few packages are, because it requires more effort (both initially and ongoing) to do so. > >> I know Postgres is not desktop package, but it shows it is possible to do. > > > > No one would argue that it is impossible, but with the current tools, it is > > done at a linear increase in developer effort. Ubuntu developers can much > > more effectively spend their limited time making one version very good than > > making two versions mediocre. > > 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. > 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. > >> The problem is that Dapper ships PostgreSQL 7.4, 8.0 and 8.1 while Hardy, > >> next LTS release ships 8.2 and 8.3. So there is no way for smooth > >> transition from Dapper to Hardy by upgrading database for example to 8.1, > >> switching to Hardy and upgrading further. This is the "functionality > >> overlap" I was talking about. > > > > 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. > And I really don't think the one from Dapper would work on Hardy. I would be surprised if it stopped working. > > Providing 10 years of support for an old version of PostgreSQL to > > support this use case would not be a wise choice. > > 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. > 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. > In many corporations there are different versions for example of Word. > To get to know which version of application it is you just have to ask > user to go to Help->About. > 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. > > Which one? The older, or the installed last? Which one does the user > > consider their preferred version? Which one works best for their purposes? > > 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 vas
Re: LTS and release methodology
You may be interested in the "LSB Package API" discussion on the Linux Standard Base's packaging mailing list. https://lists.linux-foundation.org/pipermail/packaging/2008-June/000732.html Regards, Denis Washington On Thu, 2008-07-10 at 11:47 +0300, Peteris Krisjanis wrote: > I think resume of all this is very clear - avoid regressions at any > costs. You don't need two versions of OO.o if newest one works as old > one (except bugs of course) and features works as they supposed to be. > > All this can be achieved with careful testing (using spec-like test > cases) and spotlighting such bugs early in development cycle so they > can be fixed in time. > > > 2008/7/10 Krzysztof Lichota <[EMAIL PROTECTED]>: > > 2008/7/9 Matt Zimmerman <[EMAIL PROTECTED]>: > >> On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote: > >>> It is a lot of effort, but if we want to compete with Windows, which > >>> makes it possible (and easy), it should be done. > >> > >> As far as I'm aware, Windows provides no tools or infrastructure to make > >> this easier. It is completely up to the ISV how their software is > >> installed, and many of them detect an existing installation and upgrade it > >> rather than install in parallel. Every application does it differently. > > > > Yes, some do not allow parallel versions, but many do. > > But at least they allow installing different versions without hassle. > > Linux users must jump through the hoops if they need OpenOffice 2.4 on > > Dapper which has 2.0. > > Non-existance of Windows installing system is nightmare for admins and > fact that many installators are clearly broken and allow two different > versions is not a feature. It is bug. Actually it is biggest issue why > Windows tends to be unstable after myriads of installs and uninstalls > of different software. > > > The argument about ISV doing their packaging in this way is void (at > > least for FOSS software) as in Ubuntu, Ubuntu packagers are doing > > packaging, not ISVs. > > ISV can do packaging without big problems, if they know how to do it. > Skype has never been a problem for me. It has deb and it installs > perfectly. Maybe someone could create superduper packaging service for > ISV for cheap money. > > > It is not a question how it is done, but that it is possible (and > > easy) to install various versions of apps. To the point that it is > > easier to explain user how to run Firefox 3 through Wine on Dapper > > than to explain him how to get it running on Ubuntu itself. > > Firefox is not the best example, because a) download tar.gz, b) > extract it via gui in home directory, c) create link. Vola! Why you > would want them to install it via Wine is beyond my understanding. > > >>> BTW. It is already done for example for PostgreSQL - Dapper has > >>> packages for PostgreSQL 7.4, 8.0 and 8.1. They can coexist and run > >>> along each other. User chooses which package to install and then which > >>> versions to run. > >>> > >>> I know Postgres is not desktop package, but it shows it is possible to do. > >> > >> No one would argue that it is impossible, but with the current tools, it is > >> done at a linear increase in developer effort. Ubuntu developers can much > >> more effectively spend their limited time making one version very good than > >> making two versions mediocre. > > Having different versions of server programs is understandable, > because they sometimes differ greatly in features and working > principles. However, newer desktop app usually should support data > from old app. Of course it is not always so, but we should try to > achieve that. Multiple versions of OpenOffice.org won't create better > desktop, it will mess it up. It is short term vision which is not > worth to implement because for now everyone can download .tar.gz and > extract it in home directory and run it. > > I think one version policy is what make open source/free software > desktop so great. It is foundation and you shall build upon it. Mess > with regressions, don't mess with apps. > > Just my two cents, > Peter. > -- 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
2008/7/8 Matt Zimmerman <[EMAIL PROTECTED]>: > There is a 'regression' tag, and we do try to prioritize these on an ad-hoc > basis, but understand that with such incomplete information, it's difficult > at best. Ok, I haven't seen that tag, even on bug bugs where users explicitly say that is has worked on a specific earlier distribution, such as bug #88746. Maybe it could be encouraged to be much more widely used? > This is already our policy; in fact, we delayed the first LTS release for > that reason. 8.04 released with some regressions, but these were > considered > either a) not severe enough to warrant delaying the entire release, or b) > planned to be fixed with 8.04.1. > Ok, I see. Well, then I suppose that I would like either a) the policy to be enforced more strictly, or b) that it should be communicated in some way much more clearly that the release is not really stable for production use yet for many users. For example by calling the release "8.04 Early Adopters", or something similar. And by the time of 8.04.1, or whenever it is deemed stable for a sufficiently large user base, the "Early Adopters" could be dropped. When the software is released as stable, most people expect it to be so, and will get disappointed and lose trust in the Ubuntu releases over time. However, if it is clearly stated that it still contains too many bugs, trust won't fall, as people get what they had expected. (See my earlier post for more details.) The important point is that a normal user should not need to hang out on forums, mailing list, LP, and so on, to know if the release is stable enough to use. IMHO, it should be enough to see from the name if the release is ready-for-use. For me (and probably many others) the name 8.04 Long Term Support communicates a message that it is so stable. In short: either change the name of the release, or the release itself. Regards Pär -- 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: Did we really release 8.04? - users as developers
> The first step is maybe to start taking in much higher account users > contributions. My experience is that patches can stay in launchpad for > months and in those cases it is entirely up to who contributed those to > bother people until they ack a fix. I am not talking about my often > blind one-liners but of many fixes I have actually seen and used. This > is clearly due to lack of manpower to review patches, but this is a cat > eating its tail: one user learns how to help because there are too few > developers, and there are too few developers to take advantage of her > work. > > Maybe a patch queue could be created, and some people allocated to work > on patch review, merging and backporting (via the backport repository I > mean). Publicizing this would encourage people to provide fixes (or at > least, keeping patches in launchpad for months without looking at them > will discourage people to contribute at all). > > Vincenzo I've been working a lot in volunteer organizations (not so much in Ubuntu though) and IMHO the paid people should focus their work on activating the volunteers, and on taking as much advantage as possible of the volunteers work. This includes doing all the boring stuff that volunteers don't want to do, and certainly caring about (and acting fast on) volunteer submitted patches. This would require the paid developers to spend less time on implementing new features themselves, to free up time working with the volunteers. And that is probably a change that is hard to make, as it may seem counterproductive in the short run, and may be contrary to the way people are used to do things.If I've understood things correctly, the Fedora project works much in this way. Regards Pär -- 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, Jul 10, 2008 at 01:45:55PM +0200, Pär Lidén wrote: > 2008/7/8 Matt Zimmerman <[EMAIL PROTECTED]>: > > > There is a 'regression' tag, and we do try to prioritize these on an ad-hoc > > basis, but understand that with such incomplete information, it's difficult > > at best. > > Ok, I haven't seen that tag, even on bug bugs where users explicitly say > that is has worked on a specific earlier distribution, such as bug #88746. > Maybe it could be encouraged to be much more widely used? It is already documented, but most people file and respond to bugs without reading the documentation (and why should they have to?). Perhaps the only way to track regressions more accurately would be to represent them as first-class data in Launchpad. This is tricky, though, as we've learned that the more visible a knob is, the more it is turned, regardless of whether it is appropriate or not. If the data is too noisy, it becomes useless (this is why Importance is controlled). > > This is already our policy; in fact, we delayed the first LTS release > > for that reason. 8.04 released with some regressions, but these were > > considered either a) not severe enough to warrant delaying the entire > > release, or b) planned to be fixed with 8.04.1. > > Ok, I see. Well, then I suppose that I would like either a) the policy to be > enforced more strictly, or b) that it should be communicated in some way > much more clearly that the release is not really stable for production use > yet for many users. I agree that we need to communicate better around our release activity, particularly with LTS. We made operational provisions for the new approach, for example delaying automatic upgrades from 6.06 LTS until 8.04.1, but the differences between 8.04 LTS, 7.10 and 6.06 LTS were perhaps not clear enough to everyone affected. This is one of the difficult things about having no contact with most of the user base. > The important point is that a normal user should not need to hang out on > forums, mailing list, LP, and so on, to know if the release is stable enough > to use. IMHO, it should be enough to see from the name if the release is > ready-for-use. For me (and probably many others) the name 8.04 Long Term > Support communicates a message that it is so stable. I by no means imply that 8.04 was not ready to use. There were some flaws, which there always are in software releases, and in my view we addressed them appropriately with updates and 8.04.1. To you, "LTS" may mean "so stable", but to another, it means that problems are actively fixed (which implies some change and therefore instability) even after release. One thing it can never mean is that there are no bugs in it, for that is a practical impossibility. -- - mdz -- 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
How to add a config parameter into the kernel
Hi, I'm trying to modify the kernel and as I do so I realize that a compile time option would be best to include or exclude my modifications. I want to add a config option that would set a macro such as CONFIG_ECS. Which I can then use to replace some functions or add functionality to existing ones. I'm using Hardy, on a x86-64. I tried adding the line CONFIG_ECS=y into the .config file in /debian/config/amd64 but when I run the script that validates the various config files (/debian/scripts/misc/oldconfig amd64), it complains about the entry and removes it. How can I add my own config option so I can use #ifdef CONFIG_ECS? I'm not sure if it's relevant, but I'm using the compilation technique provided in https://help.ubuntu.com/community/Kernel/Compile using fakeroot. Thanks in advance John -- 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 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). -- 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
2008/7/10 Matt Zimmerman <[EMAIL PROTECTED]>:
> It is already documented, but most people file and respond to bugs without
> reading the documentation (and why should they have to?). Perhaps the only
> way to track regressions more accurately would be to represent them as
> first-class data in Launchpad. This is tricky, though, as we've learned
> that the more visible a knob is, the more it is turned, regardless of
> whether it is appropriate or not. If the data is too noisy, it becomes
> useless (this is why Importance is controlled).
Hmm, yes, I see. It was something like that first-class data thing I meant,
but I understand that I can be quite tricky.
I agree that we need to communicate better around our release activity,
> particularly with LTS.
Good!
> I by no means imply that 8.04 was not ready to use. There were some flaws,
> which there always are in software releases, and in my view we addressed
> them appropriately with updates and 8.04.1.
Yes, at least for me, every problem of importance I had with the original
8.04 has been fixed now. I'm happy for that, and am grateful to the
developers about it. Maybe I'm repeating my point, and maybe you already
agreed to this, but IMHO there should have been some message somewhere that
the software has not the same level of stability as for example 6.06, and
those wanting that stability should wait till 8.04.1.
> To you, "LTS" may mean "so stable", but to another, it means that problems
> are actively fixed (which implies some change and therefore instability)
> even after release.
Hmm, from what I've understood from the official texts, the LTS are supposed
to be more stable. From the release announcement for Hardy [1]:
Ubuntu 8.04 LTS Desktop Edition features incremental improvements to
familiar applications, with an emphasis on stability for this second Ubuntu
long-term support release
That sounds to me that the LTS should be more stable than other releases
("emphasis on stability"). Maybe I'm reading it wrong; perhaps it should be
understood as "stability in the long term", not neccessarily stability right
when it's released, but over time instead. I've also understood stability
in these texts as "low bug-count", or something similar. Maybe I've also
misunderstood that. If so, I'm probably not the only one to misunderstand
such statements, and it would be wise to consider making them more clear.
> One thing it can never mean is that there are no bugs in it, for that is a
practical impossibility.
Yes, I definitely understand that, and if the ambition was zero known bugs,
it would take many years before it could ever be release (as the newest
Emacs for example). Maybe a complex product such as an OS could never be
released if that was the ambition.
Thanks for taking your time to answer my questions. I hope my thoughts could
be of some benefit for Ubuntu releases, and Ubuntu users, in the future. And
thanks for the effort you all developers are putting in making Ubuntu the
best Linux distro for my needs (except perhaps stability sometimes).
Regards
Pär
[1] https://lists.ubuntu.com/archives/ubuntu-announce/2008-April/000110.html
--
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, Jul 10, 2008 at 12:47 PM, Pär Lidén <[EMAIL PROTECTED]> wrote:
> 2008/7/10 Matt Zimmerman <[EMAIL PROTECTED]>:
>> To you, "LTS" may mean "so stable", but to another, it means that problems
>> are actively fixed (which implies some change and therefore instability)
>> even after release.
>
> Hmm, from what I've understood from the official texts, the LTS are supposed
> to be more stable. From the release announcement for Hardy [1]:
>
> Ubuntu 8.04 LTS Desktop Edition features incremental improvements to
>
> familiar applications, with an emphasis on stability for this second Ubuntu
> long-term support release
>
> That sounds to me that the LTS should be more stable than other releases
> ("emphasis on stability"). Maybe I'm reading it wrong; perhaps it should be
> understood as "stability in the long term", not neccessarily stability right
> when it's released, but over time instead. I've also understood stability
> in these texts as "low bug-count", or something similar. Maybe I've also
> misunderstood that. If so, I'm probably not the only one to misunderstand
> such statements, and it would be wise to consider making them more clear.
I think usually when we say "stable" about a release, it means
un-changing, not necessarily bug-free. Stable-as-bugless is more a
Debian "we won't release anything until the bug count is below x"
thing.
--
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo
--
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: Xubuntu on PowerPC (ports)
It is a bug with the daily build of the port and not the port its self. I've made some strides in getting this fixed and will see about getting the finally bits completed so it builds daily. Cheers, On Thu, Jul 10, 2008 at 2:37 PM, Jim Campbell <[EMAIL PROTECTED]> wrote: > Hi all, > > I wanted to inquire about the state and plans of the PowerPC build of > Xubuntu (and PowerPC for other Ubuntu flavors). We've been getting a daily > error on the Xubuntu PPC Intrepid builds for some time [1], and I haven't > heard any talk on the matter recently, so I wanted to check with the group. > > From my perspective, there are a couple of factors involved. Of course, > Macs aren't currently being shipped with PowerPC processors, so anyone > trying to run X/K/Ubuntu on a Mac is going to be running older hardware. > The flip-side of that is those running older hardware would be most likely > to want to run Xubuntu (vs. Ubuntu or Kubuntu). Do we have anyone who is > working to maintain this port for Xubuntu? I don't think that we do. > > I'm a bit naive on this matter - there may be a team that's working on this > - I know that there's an ubuntu-powerpc IRC channel. Of course, the issue > may also just be something on the Ubuntu server end that is preventing the > builds from being generated correctly, making this a moot point. Does > anyone have any thoughts or insights on this? > > Jim > > > [1] date Jul 10, 2008 12:18 PM > subject CD image xubuntu/intrepid/ports_daily failed to build on > 20080710 > mailed-by antimony.canonical.com > > = Syncing Xubuntu mirror = > Thu Jul 10 18:13:01 BST 2008 > = Building britney = > Thu Jul 10 18:18:52 BST 2008 > make: Entering directory `/srv/cdimage.ubuntu.com/britney/update_out' > make: Nothing to be done for `all'. > make: Leaving directory `/srv/cdimage.ubuntu.com/britney/update_out' > = Extracting debootstrap scripts = > Thu Jul 10 18:18:52 BST 2008 > zcat: /srv/ > cdimage.ubuntu.com/ftp-universe/dists/intrepid/main/debian-installer/binary-powerpc/Packages.gz: > No such file or directory > > -- > xubuntu-devel mailing list > [EMAIL PROTECTED] > https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel > > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- 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
Add Limewire to the Main respository.
Limewire is a very popular PTP sharing software. This is the license for it.http://wiki.limewire.org/index.php?title=Gnu -- 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: Xubuntu on PowerPC (ports)
On Thu, Jul 10, 2008 at 10:37 AM, Jim Campbell <[EMAIL PROTECTED]> wrote: > From my perspective, there are a couple of factors involved. Of course, > Macs aren't currently being shipped with PowerPC processors, so anyone > trying to run X/K/Ubuntu on a Mac is going to be running older hardware. > The flip-side of that is those running older hardware would be most likely > to want to run Xubuntu (vs. Ubuntu or Kubuntu). Do we have anyone who is > working to maintain this port for Xubuntu? I don't think that we do. Hi, Jim -- I'm on the list but I'm not a yet developer (I'm actually a student and I am still learning to code), but I am a Xubuntu user on the PowerPC platform. Your point above is right on the mark -- of all the *buntus that a PowerPC Mac user would use, I think Xubuntu is best suited (As a Mac user, I find it best suited, anyway). If you'll allow me to get on my soapbox: The Mac hardware running PowerPCs tend to have a long shelf life (with a couple of exceptions), and with Apple upgrading its predatory-cat operating systems far past the ability to be used by the older hardware, GNU/Linux becomes a viable option for PowerPC users "stuck" on OS 9 or OSX 10.1 or 10.2. Having said this, I think it benefits a distro to continue to develop for the PowerPC platform because there are many machines out there that could be spared from a landfill by using Xubuntu (not to mention having satisfied users not having to dish out hundreds or thousands of dollars on a new computer by using Xubuntu), and that distro could get a foothold in this area. Fedora and Debian, I think, are the only major distros that are still developing for PowerPC. Now I'm off the soapbox. Again, I wish I were in a position to help maintain the PowerPC version, but I don't yet think my abilities are up to it yet. There may be a point where I can contribute, and I hope when that time comes, there will still be a PowerPC version. However, I hope there is interest in maintaining this from people more experienced than me. Sorry if this tangent is off topic, but I had to weigh in. Larry Cafiero -- 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
Xubuntu on PowerPC (ports)
Hi all, I wanted to inquire about the state and plans of the PowerPC build of Xubuntu (and PowerPC for other Ubuntu flavors). We've been getting a daily error on the Xubuntu PPC Intrepid builds for some time [1], and I haven't heard any talk on the matter recently, so I wanted to check with the group. >From my perspective, there are a couple of factors involved. Of course, Macs aren't currently being shipped with PowerPC processors, so anyone trying to run X/K/Ubuntu on a Mac is going to be running older hardware. The flip-side of that is those running older hardware would be most likely to want to run Xubuntu (vs. Ubuntu or Kubuntu). Do we have anyone who is working to maintain this port for Xubuntu? I don't think that we do. I'm a bit naive on this matter - there may be a team that's working on this - I know that there's an ubuntu-powerpc IRC channel. Of course, the issue may also just be something on the Ubuntu server end that is preventing the builds from being generated correctly, making this a moot point. Does anyone have any thoughts or insights on this? Jim [1] date Jul 10, 2008 12:18 PM subject CD image xubuntu/intrepid/ports_daily failed to build on 20080710 mailed-by antimony.canonical.com = Syncing Xubuntu mirror = Thu Jul 10 18:13:01 BST 2008 = Building britney = Thu Jul 10 18:18:52 BST 2008 make: Entering directory `/srv/cdimage.ubuntu.com/britney/update_out' make: Nothing to be done for `all'. make: Leaving directory `/srv/cdimage.ubuntu.com/britney/update_out' = Extracting debootstrap scripts = Thu Jul 10 18:18:52 BST 2008 zcat: /srv/ cdimage.ubuntu.com/ftp-universe/dists/intrepid/main/debian-installer/binary-powerpc/Packages.gz: No such file or directory -- 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: Add Limewire to the Main respository.
Trevor Schauls wrote: Limewire is a very popular PTP sharing software. This is the license for it.http://wiki.limewire.org/index.php?title=Gnu Feel free to package it, but Frostwire does the same thing, and is community managed. Plus, just because something is poplular doens't mean it will be added to "main". "universe", maybe... -FFM signature.asc Description: OpenPGP digital signature -- 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: Add Limewire to the Main respository.
2008/7/10 Trevor Schauls <[EMAIL PROTECTED]>: > Limewire is a very popular PTP sharing software. This is the license for > it.http://wiki.limewire.org/index.php?title=Gnu There is a long standing needs packaging bug on this application. Not all the source is available which is the stumbling block. Caroline -- 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: Add Limewire to the Main respository.
On Thu, Jul 10, 2008 at 4:36 PM, ffm <[EMAIL PROTECTED]> wrote: > Trevor Schauls wrote: >> >> Limewire is a very popular PTP sharing software. This is the license for >> it.http://wiki.limewire.org/index.php?title=Gnu > > Feel free to package it, but Frostwire does the same thing, and is community > managed. Not just does the same things in terms of being a P2P app, but it's exactly the same interface and everything...don't they even share a codebase on top of that? -- Mackenzie Morgan Linux User #432169 ACM Member #3445683 http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff apt-get moo -- 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
2008/7/10 Matt Zimmerman <[EMAIL PROTECTED]>: > > The important point is that a normal user should not need to hang out on > > forums, mailing list, LP, and so on, to know if the release is stable > enough > > to use. IMHO, it should be enough to see from the name if the release is > > ready-for-use. For me (and probably many others) the name 8.04 Long Term > > Support communicates a message that it is so stable. > > I by no means imply that 8.04 was not ready to use. There were some flaws, > which there always are in software releases, and in my view we addressed > them appropriately with updates and 8.04.1. > > To you, "LTS" may mean "so stable", but to another, it means that problems > are actively fixed (which implies some change and therefore instability) > even after release. One thing it can never mean is that there are no bugs > in it, for that is a practical impossibility. > After some thought, I'd like to clarify on this one: instead of writing "ready-to-use" I should have written "few bugs are encountered for the average user in their normal tasks". Those releases on which I have encountered the least bugs are Dapper and Feisty (and I think many would agree with me). So maybe a (somewhat subjective) way of defining "few bugs" would be "as few as on Dapper or Feist for the averagre user". And IMHO, and from what I've read on the Internet, Hardy exceeded that, and that's not what I (and many others) would except when the release has "LTS" in its name. However, 8.04.1 works very good for me, and I'm very satisfied that with the path Ubuntu has taken with regular support releases, working on and fixing bugs also after the release. Maybe it's not so important that that the first Hardy release was a bit buggy, whats more important is that those issues are being adressed. And that is exactly what is happening now. Regards Pär -- 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
Op woensdag 09-07-2008 om 10:16 uur [tijdzone -0400], schreef Mackenzie Morgan: > Er, not really. You can't have FF2 and FF3 or IE6 and IE7 both > installed on Windows, or if it is somehow possible, it's certainly not > easy. It's not too difficult with Firefox AFAIK, but with IE it certainly is far from trivial... -- Jan Claeys -- 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
