OSNews: http://www.osnews.com/story/19937/The_Blessings_of_Synchronised_Releases Exploring the Future of Computing en-us Copyright 2001-2012, David Adams adam+nospam@osnews.com Wed, 15 Feb 2012 12:14:32 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com alpha quality software http://www.osnews.com/thread?320674 http://www.osnews.com/thread?320674 I don't particularly care for the publicity factor of synchronizing releases like that. What i'm after is the result of doing so, because as it is right now, most distros ship with way too much alpha quality software, just because they cant seem to hit the sweet spot that very often. Mon, 30 Jun 2008 12:59:00 GMT donotreply@osnews.com (ple_mono) Comments A really bad idea http://www.osnews.com/thread?320675 http://www.osnews.com/thread?320675 Suppose one project is unquestionably ready on the date, and the other project is not, for example of the issues Fedora 9 has with KDE 4. Should Fedora have delayed however long it took for KDE 4.1 to be ready? or should KDE 4.1 have been "given" more resources by Mr. Shuttleworth (or someone at the Fedora project) in order to meet Fedora's deadline? What would serious coordination mean in this world?

So this strikes me as a really bad idea. Maybe this is not what he is getting at, but artificial deadlines seem to be part of the problem with Windows; some wit on this website remarked a while back that at the time Vista was released, all of its promised major features was present in each major OS except Vista. Having rollouts may be fun and enjoyable and leave everyone with good feelings for a week or so, but in the long run the current model is much, much better. Mon, 30 Jun 2008 13:24:00 GMT donotreply@osnews.com (jack_perry) Comments release early, release often? http://www.osnews.com/thread?320676 http://www.osnews.com/thread?320676 I have no interest in the political advantages of a patch tuesday or a Distro April. Delaying or rushing a project too meet someone's political mandate just seem slike a poor idea.

What does interest me is technical merits. If such a community wide release schedual provides me with a higher quality base platform to start with plus the ongoing daily updates we enjoy now; I'm more interested.

All in all, I'm still undecided as I'm only effected by the end user benifits. The developers who have to work within the framework will need to discuss that side of it which seems to be what they are doing now. Mon, 30 Jun 2008 13:32:00 GMT donotreply@osnews.com (jabbotts) Comments Kernal or DE http://www.osnews.com/thread?320679 http://www.osnews.com/thread?320679 Lets face it, as far as most end users are concerned the only 'real' update to a distro is either the Kernal or DE being updated.

An upgrade must be something tangiable to the end user. Try to think of it as if it was a new version of windows or osx.

Firefox reaching v.3 != Fedora 10, for example

I would recommend release cyles based on DE

KDE 4.0 = new version
KDE 4.1 = new version

The drawback of this is of course that v10 kde may not be release the same time as v10 gnome. This would encourage distros to be DE specific. Is that good or bad? Thats a new thread :-p Mon, 30 Jun 2008 13:51:00 GMT donotreply@osnews.com (Adurbe) Comments RE: A really bad idea http://www.osnews.com/thread?320682 http://www.osnews.com/thread?320682
Suppose one project is unquestionably ready on the date, and the other project is not,


This goes on now, and what happens is the first project takes what it has, applies some quick and dirty patches to get it more or less working, then shoves it out the door. Very common practice, what ends up happening is distro specific issues and bugs.

Slackware is one of the few that doesn't do this (note that pat still hasn't released slack with kde 4), and actually (gasp) waits until a project is ready for prime time before releasing it.

If projects at least aimed for a regular, synchronized release cycle, it would make the distros life easier. I mean, even if a project isn't ready, it could hardly be worse then the situation is now. Mon, 30 Jun 2008 14:07:00 GMT donotreply@osnews.com (google_ninja) Comments Comment by Kroc http://www.osnews.com/thread?320683 http://www.osnews.com/thread?320683 Perhaps a select number of release dates could be chosen for everybody to shuffle about a little to meet. A compromise as it were.

Have January, April, July & October as standardised release months, and have everybody shuffle up or down a month or two so that everybody benefits from a larger number of releases occurring at the same time, rather than a month or two apart, and thus slipping past a DE release (*ahem*Firefox3*ahem*).

If both Ubuntu & Firefox had chosen a standardised July release instead of barely just apart, they could have shipped together. Mon, 30 Jun 2008 14:07:00 GMT donotreply@osnews.com (Kroc) Comments Don't - please !!! http://www.osnews.com/thread?320687 http://www.osnews.com/thread?320687 That will only lead to halfbaked apps being rushed out in order to meet a release date or things being left out.

Can't those people learn from microsoft how you don't do things.

One of the great advantages of free software is that it is decentralized and now this is supposed to be replaced by a central release commitee run by whom? Mon, 30 Jun 2008 15:54:00 GMT donotreply@osnews.com (klimg) Comments why? http://www.osnews.com/thread?320692 http://www.osnews.com/thread?320692 synchronizing all those teams for marketing reasons?

I think it will slow down development. A lot of energy will go to synchronizing all the different releases. There are some typical organization that do this kind of big bang synchronizations: MS, Apple (osx delay?), ...

If open source development is taking this route, they are competing more and more on the terms of the commercial organizations. The chaos inherent in the heterogeneous and smaller organizations will need to be "ordered". In nature the more ordered the more energy it costs. I think that is just the same here.

bye
roelEdited 2008-06-30 16:10 UTC Mon, 30 Jun 2008 16:09:00 GMT donotreply@osnews.com (roel) Comments A Step Backwards? http://www.osnews.com/thread?320695 http://www.osnews.com/thread?320695 I think so.
Having the different distro's release on different dates in IMHO a good thing. You get effectively a system of continuous improvement. If distro A find a problem in package, Distro B can put the fix into their release and so on.
Now, if we think of the problems that ISP's are going to put in the way of the huge increase in Torrents is the likes of Ubuntu, Fedora, SUSE & Mandiva (to name just a few) all release on the same day. How much throttling will they apply to downloaders?
Having the releases appear at different times means that people can try out a new release of a different distro at regular intervals without having to decide between the latest & greatest release of Fedora, SUSE etc and then waiting possibly days for the download to complete. Mon, 30 Jun 2008 16:17:00 GMT donotreply@osnews.com (shotsman) Comments release and stable branches http://www.osnews.com/thread?320696 http://www.osnews.com/thread?320696 Personally, I think Ubuntu should switch to a release branch and a stable branch of their dev tree. The release branch would stick hardcore to the main version of the big apps / kernels it was released with. The stable branch would allow for updates of items like xorg or KDE 4.0 -> 4.1 or firefox 2 -> 3, etc...

This way they can do their release cycles and still allow for larger items being upgraded.

Probably means more testing on their part and maybe it's a political thing since they want to force the major releases on people. Mon, 30 Jun 2008 16:39:00 GMT donotreply@osnews.com (rhavenn) Comments RE: Don't - please !!! http://www.osnews.com/thread?320698 http://www.osnews.com/thread?320698
That will only lead to halfbaked apps being rushed out in order to meet a release date or things being left out


...as opposed to half baked apps getting a few quick and dirty patches and rolled into a distros release cycle? Mon, 30 Jun 2008 17:11:00 GMT donotreply@osnews.com (google_ninja) Comments KDE and GNOME http://www.osnews.com/thread?320700 http://www.osnews.com/thread?320700 I think that KDE and GNOME should synchronize their release cycles to occur in the same month. Currently GNOME releases in September and March and KDE releases in July and January. It would be helpful if they released at the same time I believe as it would enable more collaboration on their part. Are there disadvantages to having them release in the same month that I'm just not seeing? Would collaboration and standardization (FreeDesktop.org and LSB) be better or worse with a same-month DE release synchronization? Are there any good opinions about why they should or should not be synchronized?

Edit: Accidentally posted early!Edited 2008-06-30 17:30 UTC Mon, 30 Jun 2008 17:24:00 GMT donotreply@osnews.com (asupcb) Comments RE[2]: Don't - please !!! http://www.osnews.com/thread?320703 http://www.osnews.com/thread?320703
...as opposed to half baked apps getting a few quick and dirty patches and rolled into a distros release cycle?

Yeah. Is failure to release on a schedule a good release policy? Or poor release planning? Good release planning starts when the feature set is determined, and before the first patch goes into the dev repository. Resistance to a project schedule is often a sign that the project devs have a poor level of discipline. Mon, 30 Jun 2008 18:10:00 GMT donotreply@osnews.com (sbergman27) Comments RE: A Step Backwards? http://www.osnews.com/thread?320705 http://www.osnews.com/thread?320705 I don't see why it has to be "one way" or nothing? What if you could, say, have 4 synchronizations a year, so that whatever distro want to release at such a time can do so at their own choosing.
There is no need to shove this down the throat of developers that don't want to be a part of this, but it could help stabilize the majority of the open source eco system. Mon, 30 Jun 2008 18:20:00 GMT donotreply@osnews.com (ple_mono) Comments Comment by moleskine http://www.osnews.com/thread?320707 http://www.osnews.com/thread?320707 In what sense would synchronizing development releases be helpful? And helpful to whom?

There is a risk here that it would be most helpful to the marketing department, which would naturally like to take a fairly complex product and reduce it to "The Blingtastic Latest and Greatest". Because that's easy to sell and failures of the strategy can be blamed on upstream - we can only sell what the devs give us by date x, etc.

I'm not arguing against synchronization, just pointing out that there are commercial pressures here that aren't all that healthy. Thus do marketing folks get further and further through the door of what developers actually develop.

As someone has wisely already said, "ready for release" and ready for prime time are not the same thing at all. The first can easily be twisted into a marketing call. The second means sticking your rep and judgement on the line. It also means sticking up for your users. It's quite hard to say, with some recent distros, that inflicting, say, Pulse Audio in its present state on your users is really giving them something that's ready for prime time rather than going with marketing and "ready for release". Mon, 30 Jun 2008 18:33:00 GMT donotreply@osnews.com (moleskine) Comments RE: Comment by moleskine http://www.osnews.com/thread?320716 http://www.osnews.com/thread?320716
In what sense would synchronizing development releases be helpful? And helpful to whom?


Helpful to users and projects.

Synchronised release cycles allow people to plan.

Users can plan upgrades. Users can plan on having certain hardware support or other functionality available.

Businesses can plan rollout and release cycles. They can plan for training, etc.

Other developers can plan on depending on certain functionality being available because they know X is available in Y on Z date.

I don't know why the "open source" world thinks they are somehow exempt from the last 50 years or so of software engineering and release principles.

Every major commercial successful product launch involves a lot of planning.

Given Ubuntu's success, it should be obvious how great of a benefit release planning can bring. Mon, 30 Jun 2008 19:54:00 GMT donotreply@osnews.com (binarycrusader) Comments The Problem http://www.osnews.com/thread?320719 http://www.osnews.com/thread?320719 The problem isn't with synchronized releases, it's with synchronized non-releases - the dead spot in between major pushes of user-facing software puts less pressure on companies to keep the 'latest and greatest' going (like fedora 9's pressuring ubuntu on more than a few technical fronts.) Yes, the development is still going on behind the scenes, but it's harder to 'point to' what features users might find important for the next release, if no mainstream distro has it. Mon, 30 Jun 2008 20:01:00 GMT donotreply@osnews.com (jadeshade) Comments meh... http://www.osnews.com/thread?320723 http://www.osnews.com/thread?320723 make a system thats robust enough to have major parts upgraded without having to basically build the house of cards all over again...

and the simplest way to do that? have the ability to install multiple versions of libs side by side...

when you have that you can pop in a new DE side by side with the old, use apps from the old until a replacement comes along that works with the new DE, and then clean house.

that housecleaning bit is what most os get wrong when they have the multiple lib versions right. end result? leftover libs and other files that no-one knows where belongs... Mon, 30 Jun 2008 20:09:00 GMT donotreply@osnews.com (hobgoblin) Comments RE: release and stable branches http://www.osnews.com/thread?320738 http://www.osnews.com/thread?320738
Personally, I think Ubuntu should switch to a release branch and a stable branch of their dev tree. The release branch would stick hardcore to the main version of the big apps / kernels it was released with. The stable branch would allow for updates of items like xorg or KDE 4.0 -> 4.1 or firefox 2 -> 3, etc...

This way they can do their release cycles and still allow for larger items being upgraded.

Probably means more testing on their part and maybe it's a political thing since they want to force the major releases on people.


Maybe ubuntu should do 3 trees instead and call them Stable, Testing and Unstable? ;)
Ubuntu is pretty much a second testing tree of debian as they go for the latest packages rather being a 2nd etch. Mon, 30 Jun 2008 22:52:00 GMT donotreply@osnews.com (stabbyjones) Comments Mark could be a charismatic leader? http://www.osnews.com/thread?320802 http://www.osnews.com/thread?320802 "...nd the open source world doesn't (seem to) have a Steve Jobs and a devoted clapping crowd."

No, but what about Ubuntu's Mark Shuttleworth? He's not Steve today, but he's got some charismatic features, and maybe he'll get better.

(Steve Jobs wasn't always the talented presenter he is today, people improve.) Tue, 01 Jul 2008 10:43:00 GMT donotreply@osnews.com (TLZ_) Comments RE: A really bad idea http://www.osnews.com/thread?320805 http://www.osnews.com/thread?320805
Suppose one project is unquestionably ready on the date, and the other project is not, for example of the issues Fedora 9 has with KDE 4. Should Fedora have delayed however long it took for KDE 4.1 to be ready? or should KDE 4.1 have been "given" more resources by Mr. Shuttleworth (or someone at the Fedora project) in order to meet Fedora's deadline? What would serious coordination mean in this world?


KDE, in this case, should say, with plenty of warning, that they won't make the deadline and Fedora should then plan to make their next release without the latest KDE version.

Let's say that software projects chooses the 1st week of April and 1st week of October as their release dates and distors 3rd week of April and October (distros projects wouldn't need to release every 6 month of course and could skip a date if they felt the need) . Then all the distros would know by March and September what software they would be including. And they would also know that they will have at least two weeks for testing and integrating the final version of each project before release. Tue, 01 Jul 2008 11:48:00 GMT donotreply@osnews.com (dagw) Comments RE[2]: A really bad idea http://www.osnews.com/thread?320823 http://www.osnews.com/thread?320823 I don't think that two weeks is enough time to do proper testing. Why not do a Ubuntu-style release schedule that closely follows GNOME about a month after the release of a new version of GNOME? GNOME release in March and September and then Ubuntu releases in April and October so I guess they already do what you are asking. Surely Ubuntu takes longer than two weeks for their release. I personally would prefer they wait for the 2.x.1 version in order to fix anything that may have been initially missed.

Currently KDE is on a January/July release schedule. Tue, 01 Jul 2008 15:41:00 GMT donotreply@osnews.com (asupcb) Comments RE[3]: A really bad idea http://www.osnews.com/thread?320828 http://www.osnews.com/thread?320828
I don't think that two weeks is enough time to do proper testing.


Well I'm assuming the distros are closely following the daily snapshot/beta/RC progress of the packages in question so most of the problems should get taken care of continuously at those stages. The two weeks will be the time they'll have to test the final version of the software and to catch anything they missed or has changed since the final RC. Tue, 01 Jul 2008 16:18:00 GMT donotreply@osnews.com (dagw) Comments