Avoiding feature regressions should be more important than (exact) time based releases

I really like the fact that Ubuntu releases are time based. However I think that we should not let so easily core/main features just stop working and let the release ship nevertheless.

Some examples with Intrepid :

I mean basic printing, burning/using CDs not working in a 2008 operating system, than can’t be real, right ?

My (humble) proposal :

  • Any default feature that was previously working and is not working anymore should be a release blocker (of course explicit exception could be granted by the release team on a case by case basis).
  • There should be an easy way in launchpad to mark and track such regressions.
  • Release dates should be planned in the beginning of the month instead of the very end of the month so that if more time is needed we won’t have to renumber the release.

The fact that Intrepid release notes are so big should be an other indication as to why it was too early to release Intrepid IMHO.

I’m not whining or blaming anybody here, I can fix all these problems for my specific computers. However I think that users expect that what was working before will somewhat continue to work in the new release (I’m not speaking about performance regressions, regressions in packages not in main here, I know that we cannot avoid every regression). This is far more important than releasing on the exact planned day.

31 réflexions sur « Avoiding feature regressions should be more important than (exact) time based releases »

  1. Or if you’re a KDE user:

    1) Panel is not capable of hiding (auto or manual) anymore.
    2) Taskbar cannot have more than one row.
    3) No bluetooth.

  2. Definitely agree with you here.

    I had a total of 5 severe regressions on my desktop which took me 45+ minutes each to solve. And I do this for a living.

    These are regressions with my printer, my bluetooth kb/mouse and layout. Basic stuff that was all working beforehand.

    I do feel there’s an imbalance here regarding bugfixing and feature implementation.

  3. Maybe Ubuntu users prefer to get their install CD on the one-year-before-fixed date and keeping making joke about lenny’s releasing date …

  4. Not very likely to happen. Marks major point for Ubuntu are time based releases .. you basically want Debian.

    What realistically could happen is a later release date .. let Fedora and other distros release earlier than Ubuntu and incorporate all their fixes… Say ship with Gnome X.Y.2 etc. That would add a lot stability and regression wise.

    It will be a bit detrimental to marketing/hype .. but the out of the box experience would be better if we had Ubuntu 8.12 and 9.06… maybe even later.
    And no Dapper is not a argument against this proposal, because it wasn’t planned with such a roadmap.

  5. >Any default feature that was previously working and is not working anymore should be a release blocker (of course explicit exception could be granted by the release team on a case by case basis).

    You do realize that this policy just means that new features will be removed from release, just because once added, we can’t get rid of it, when nobody maintains it or when it becomes a problem in other areas.

    I don’t really think for regular releases regressions should matter much. The normal releases are upstreams’ rock. It’s sort of stable, but it is what upstream made it to be. It’s where they can experiment. They should be free to change their mind. Perhaps eventually we can even get upstream to think in normal and LTS releases.

    What I think is more important, is to focus _purely_ on regressions between different LTS versions.
    The trick is easy though.

    – Just have the 6 months releases.
    – And ever 2 years, after the latest 6 month release, make a list of critical bugs/regressions.
    – Keep fixing those bugs in the proposed/backports repository.
    – Don’t timestamp the LTS releases per month, only the year.
    – When all bugs are closed, relabel release as an LTS release. (re-release sort of speak)
    – If the release in general is perceived to be unstable, aim for LTS the next release in the same year.
    – Support LTS releases for 3 years, so there is a nice margin of a year to update for both the user, and the developer to move the date up.

    Imagine 8.04.2 being the official LTS

    1. @Meneer R,

      >You do realize that this policy just means that new features will be removed from release, just because once added, we
      >can’t get rid of it, when nobody maintains it or when it becomes a problem in other areas.

      Yes I do, that’s why there could be exceptions. However I don’t consider features like network printing and using my CD drive to be something than can be gotten rid of. If some feature should be removed because nobody maintains it, I’m fine with having a « regression exception » granted, but then :
      1) remove it completely, don’t let the user think it should work by keeping the UI and making the underlying feature broken.
      2) every such exception should be mentioned in the release notes (for example for Intrepid : « Receiving files using the bluetooth applet is not supported anymore, in order to restore this functionality you have to do this and that »)

      Your plan for LTS releases being even more regression-free and only year specified sounds good too. However I think normal releases could be month/year specified but we should keep some weeks for making sure that the release notes don’t grow too much.

      1. @jernst,

        >Yes I do, that’s why there could be exceptions.

        First we need to define what features are currently delivered. Then we need to check wether they are still available.
        It’s a lot of bureaucracy.

        Currently, the release-time has all the ‘bureaucratic’ freedom to move a release date or turn certain bugs into release blockers. They just don’t really have that user-centric POV.

        >However I don’t consider features like network printing and using my CD drive to be something than can be gotten rid of.

        The import thing here is not that they are regressions, but that they are very serious bugs. Complete use-cases that are not functioning.

        > However I think normal releases could be month/year specified but we should keep some weeks for making sure that the release notes don’t grow too much.

        Yes and no. Often time is not the critical factor here, and a certain amount of testing only happens after a release.
        I personally just think it’s not possible to deliver the level of quality every 6 months that you are suggesting here.

        And that all wouldn’t be a problem, if the LTS releases were any good. But they are not. Not really anyway. They usually become slightly acceptable with the second-point-release.

        If there is any increase in quality control and regression control, i would prefer them to focus on LTS releases.

  6. I haven’t installed the Intrepid Ibex yet. Regarding this post, some reactions of other users and my poor technical skills, I think I might stick with 8.04 a bit longer.

  7. I completely agree. I really like Ubuntu but with the current known issues list for Interpid (especially the cd-tray bug) I ask myself: why didn’t they delay the release a bit to fix such obvious bugs. I’m sure no one would complain about a few weeks of delay for the sake of polishing it. IIMHO Ubuntu ruins its reputation among casual users who don’t care about release notes and known issues list, don’t track launchpad bugs and can’t fix or workaround such bugs by themselves.

  8. Agree. Also note that by the release of Intrepid PPTP could not use password from the keyring, which made a difficult task to access Internet for many people. They have to enter the Internet access password manually each time. This is fixed by now only in PPA, not in the official repo.

    It still do not save ststic IP which makes very difficult to access Internet people who do not receive IP through DHCP. They need to enter IP each time manually.

    In 8.04 keyboard layout switching did not work after restart (this affected any language other than English), and it is still not fixed in 8.04 (although there is a workaround by editing xorg.conf).


  9. There is great value in making regular, scheduled releases, as others in the comments have pointed out. At the same time, clearly each release of Ubuntu has bugs which affect different people in different respects.

    An alternative to your proposal would be to extend the release schedule so that more time is spent on polish of the release; so the release schedule could be 9 months instead of 6, but with the extra three months strictly dedicated to polish, and *not* the introduction of new features. The risk is that however long the release cycle, the temptation of developers to introduce new features even at the last minute will result in some regressions. Developers are also under pressure from users to provide the « latest and greatest » software.

    Getting a balance between polish and features is a very difficult question which particularly affects open source projects where new features appear « upstream », not just at the beginning of a release cycle, but throughout it. (The problem would be seriously reduced if open source projects harmonised their release cycles.)

    Generally, my personal feeling is that most open source projects don’t *quite* get this balance right, with the « features » getting slightly too much attention at the expense of the « polish ». As I said, it’s a difficult question, and one on which many people will have different opinions. But ultimately, in the interests of producing a more professional desktop, I think there should be a greater emphasis on polish.

  10. 8.04 gave me an issue with networking. After boot, in order to access a wireless connection, I had to first be connected to a wired connection. So I updated to 8.10 in the hopes of solving this issue, and it did. But it caused numerous other issues:

    1. UnMaximising certain apps on initial load of the app, unmaximises then IMMEDIATELY re-maximises, setting that to the unmaximised size. Thanks.

    2. Changing Gnome themes will close Firefox. Brilliant.

    3. mail-notification has decided we no longer need an option to decide AS USERS when WE WANT to have it display in our tray. Thus it is only displaying when we have email? Good luck changing any settings without CLI, since you cant even get it to pop up. This is a great new feature, restricted rights.

    4. Sound Recorder? Yes, three seconds in I want it to report that I have recorded 20 minutes of sound and for the stop, pause and other buttons to FAIL. Much obliged for thsi feature.

    Ubuntu, The Operating system that Just [doesn’t] work.

    I know some folks are making excuses. But there are no excuses for removal of existing features and functionality. Sometimes this removal is on purpose (ala Pidgin) and sometimes it is by oversight.

    The 9 month schedule sounds perfect. 6 months for you to experiment with the features no one gives a rip about. 3 months to put it back into a working state.

  11. @Matthew: I understand the value of making regular, scheduled releases. I also agree there will always be bugs affecting different people; this is not possible to resolve them all and in most cases this should not be a reason for delaying releases. However, the issues we talk about here are bugs that affect most or all users. I think for such bugs there should be no mercy.

  12. I strongly believe in time based releases. Delaying releases always becomes a slippery slope that eventually degrades to « Debian » status. That being said, I also believe that new packages with serious regressions should not be included in the release. Ubuntu has always shipped with the Gnome release schedule but nothing says Ubuntu has to include the newest version of Gnome. The same is true for other packages.

    In the past, Ubuntu has chosen NOT to include the latest version of a package because of serious bugs/regressions. Where has that system stopped working with the latest release? Additionally I’m getting sick of hearing the « if you don’t like it, use LTS » excuse. LTS versions include long-term support which is a feature for those who need it. The fact that LTS builds exist is NOT and excuse for bad decision making in the most current release.

  13. I like the idea that every release should get a .1 release 3 or 4 months after the .0 .. but I guess that won’t happen because it would cast Canonical money and wouldn’t give them anything in return except more happy conservative users.

    At the moment you cannot give every Ubuntu release to someone without broadband. It just doesn’t work. The amount of updates you need would need weeks to download with a 56k modem.

  14. Imagine if MSFT had shipped Vista with these same problems. So now we know why Microsoft spends so much $$ on testing and releases get delayed. It’s almost as if making a stable release for a consumer desktop across a wide range of hardware is very hard or something.

  15. Yeah, i don’t mind a release being a little late. As long as it’s near the planned release date.

    This should doubly be a priority with LTS releases.

  16. I completely agree. There are so many regressions, see the site below, and that list is even far from complete…


  17. By the way, I would say the LST is nothing more stable, for example the aforementioned bug with keyboard layouts that afects any non-English speaking user still had not been fixed in Hardy although the fix already available upstream and included in Intrepid,. They simply decided not to fix Hardy and encourage people to transfere to Intrepid (which will bring them a number of new bugs and regressions).

  18. I still consider myself an ubuntu noob even though I have been using it almost exclusively since Dapper. Its the best distro to run here in SA as Ubuntu has a local mirror which is blindingly quick. In order to assist others I have previously used openSUSE 10.3 to help them in a way that’s familiar to them(in other words, YAST). I hated using it and told myself I’d go back to Ubuntu with Gutsy. I did and it was good times. Some stuff seemed broken, but there was tons of documented fixes. I lived with it and thought that Hardy would be rock solid, being a LTS release.

    Boy was I mistaken, samba issues, printing, all kinds of stuff that worked fine in OpenSUSE 10.3/ Mandriva / Gutsy. When openSUSE 11 came out, despite my aversion to rpm’s, yast & the lack of local mirrors, I gave it a try. I was amazed at how well it all worked out of the box. Contrary to a lot of snide remarks I got on the web, I had a *relatively* easy transition. I am still using it today on my work laptop. My home laptop I upgraded a week later and miraculously, most of the issues went away. Of course I had others, but it *seemed* less problematic. Feeling guilty about the Novell / Microsoft Patent deals, etc, I vowed to switch back to Ubuntu with Intrepid.

    Once more, I get samba breakages, apps refusing to work (e.g. Lazarus compiling to GTK or QT), printing is flaky, etc. I look around and other people are complaining as well. I try to post bug reports, but there are duplicates registered already.

    Bottom line?? The above isn’t a criticism of Ubuntu vs openSUSE. Its about the difference between a 6 month and a 9 or 12 month release cycle. I think the SUSE dev’s simply have more time to polish the code. I think 12 months may be too long to wait for some, but 9 months wouldn’t be too bad, in my opinion.

    Also, we have to promote the use of *STABLE* vs beta software. I know we live on the edge, but the shipping iso’s should be rock solid stable. Some apps are getting a bad name because supposedly stable releases are adopting bleeding edge technology. PulseAudio gets a bad rep and not all of it is due to the authors fault. Its an easy project to pick on, but there are other examples.

    Finally, I still regard myself as a bit of an ubuntu fanboy ( i still have 1 gutsy machine left at home) and its still my first choice for anybody I convert to Linux, but Mandriva, openSUSE, Mint, etc, are all improving and I believe that Ubuntu will get it together soon.

    Sorry for the rambling post.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *