| |||||||||||||
|
| |||||||||||||
The Xorg 7.4 release planThe Xorg 7.4 release planPosted Feb 27, 2008 16:33 UTC (Wed) by pr1268 (subscriber, #24648)Parent article: The Xorg 7.4 release plan
As much as I admire Xorg's diligence in releasing new versions, I'm a little concerned about how they're targeting a release date based solely on some Linux distro's release (i.e. Fedora 9). Seems a lot of defects slip through the cracks when hard deadlines approach (a broad generalization, for sure), and considering Xorg has little influence on the F9 release date, then they'd likely push out whatever they have on that day, regardless of quality. Okay, I admit that was curt, and perhaps blatantly wrong on two levels (someone please correct my statements above or below):
Congratulations to the Xorg development team for maintaining a lively release cycle.
(Log in to post comments)
The Xorg 7.4 release plan Posted Feb 27, 2008 19:08 UTC (Wed) by i3839 (subscriber, #31386) [Link] > we're way past the initially projected release date by now [1], > so it's time to shape up anyway. He just forgot to link to the original schedule. But it seems they basically just missed the first deadline, and now are using another one to keep up the motivation. ;-)
The Xorg 7.4 release plan Posted Feb 27, 2008 19:20 UTC (Wed) by i3839 (subscriber, #31386) [Link] Update: From: Adam Jackson <ajax <at> redhat.com> Subject: Re: Xorg 7.4 release plan Date: 2008-02-27 18:53:34 GMT (23 minutes ago) On Tue, 2008-02-26 at 14:06 -0500, Adam Jackson wrote: > Right, we've been slackers for a bit here, it's time to ship something > that works. My motives are not entirely altruistic here, I really want > something that isn't a git snapshot in Fedora 9, but we're way past the > initially projected release date by now [1], so it's time to shape up > anyway. D'oh. All that and I forgot to footnote the original release plan. http://xorg.freedesktop.org/wiki/Events/XDS2007/Notes#hea... I should make a note here of what we had initially targetted for 7.4, and what I think the current status of each is. So. XGE probably not going to make it, Peter's schedule isn't particularly friendly and iirc we didn't think it was ready at LCA. XACE is merged and pretty well ingrained by this point; the subsequent X-SELinux extension looks like it's making good progress (thanks Eamon!). RANDR 1.3 ain't happening. Input transformation ain't happening. pciaccess is in. XKB 2 isn't. Enforcing server ABI with linker scripts (the cryptically named "_X_EXPORT" in that list) isn't done but is pretty straightforward; I'd happily take a patch if one showed up, otherwise I'll see if I can work it in. The DRI memory manager work and GLX 1.4 are more or less in, afaik, and we'll just have to figure out a Mesa build solution to make them happen. Glucose ain't happening. So, ten things targetted, four included, one probable. 50% feature completion per release seems to be about par for the course for us, no? - ajax
Time-based release actually works well Posted Feb 27, 2008 19:14 UTC (Wed) by dwheeler (guest, #1216) [Link] It's not necessarily a bad idea. Indeed, changing your schedule so that it meets your customers' is a good idea, and most people use X.org from a distro - not directly.But more importantly, Martin Michlmayr (Debian developer and formerly Debian Project Leader) is completing his doctoral thesis at the University of Cambridge with a thesis entitled “Quality Improvement in Volunteer Free, and Open Source Projects: Exploring the Impact of Release Management. He argues that time-based releases (e.g., where releases reliably happen every 6 months) is actually a reasonable approach. In FLOSS, you can typically decide what to include - or not include - on a particular date, depending on what's ready. By having a date, people can try to get the various bits ready... and if a snag happens, omit that part. GNOME already uses this approach. So if X.org can switch to this in general (not just have a one-off deadline), it'd be good for all.
Time-based release actually works well Posted Feb 27, 2008 20:28 UTC (Wed) by drag (subscriber, #31333) [Link] Yes. The FLOSS world is full of interdependencies. Gnome depends on improvements in X for newer features. Fedora/Ubuntu depend on improvements to Gnome and to X for their new releases. Application developers depend on Gnome and X and other libs to be improved for their improvements. Everybody depends on Users who actually need binary releases from distributions. That is, to say, that if X does not pay attention to the needs of Distros they also ignore the needs of end users and application developers. If there are no releases done with distros are released, then there is really no point to even having a release. Nobody can use it, nobody will use it. If you do feature-releases then your timeline is going to fluctuate. Users/Application developers/distros can not depend on you to ship a product so they can't take advantage of improvements you offer. Delays build up, users get irritated, developers get bored, important improvements and bug fixes remain unavailable to most users, and development stagnates. Coordination is key. A convoy at sea is only as fast as it's slowest ship. Fedora is important in this regard because they are the early adopters. They get things first and flush out problems for other distributions. Ubuntu also follows the same pattern of Fedora with 6-8 month release times so they are helped also by these timed releases. More users mean more testing, bugs get found quicker and ultimately they get fixed quicker. etc etc.
Time-based release actually works well Posted Feb 28, 2008 11:49 UTC (Thu) by pointwood (guest, #2814) [Link] KDE is using a time based release schedule as well now: http://tuxenclave.wordpress.com/2008/02/02/kde-41-roadmap...
Time-based release actually works well Posted Feb 28, 2008 20:59 UTC (Thu) by Sho (guest, #8956) [Link] KDE point releases within a major release series (e.g. 3.x) have actually always been date-driven. 4.0 didn't have a date for much of the release cycle because it was a generational jump and greater flexibility was required in the face of the task.
Time-based release actually works well Posted Mar 1, 2008 23:05 UTC (Sat) by sbergman27 (subscriber, #10767) [Link] """ It's not necessarily a bad idea. Indeed, changing your schedule so that it meets your customers' is a good idea, and most people use X.org from a distro - not directly. """ I find the increasing popularity of time-based releases to be refreshing and encouraging... after years of hearing the phrase "it's ready when it's ready" used to cover for a lack of a proper release plan by some projects. Deadlines mean that people have to buckle down and do the unfun stuff rather than perpetually working on cool new stuff that's never quite ready for release.
The Xorg 7.4 release plan Posted Feb 28, 2008 18:12 UTC (Thu) by nim-nim (subscriber, #34454) [Link] I'll take a release synchronized with a major distro over a free-for-all one every day. Synchronizing with a major distro schedule means your new code is actually tested by a large pool of users (distro testers) and bugs are actually reported and tracked (by the distro maintainers that want to ship a solid release). There is no possible comparison with a release that has only been tested by people who can and bother building vcs snapshots. For example hal auto input code landed in Fedora devel last week (among much grief) but that also means this code is going to be beaten into shape now instead of festering in an almost-working state as it has for the last months. (Fedora is good that ways, it enables the features everyone is afraid of and gets their upstream to stabilize them instead of waiting for others to take the first step). IIRC Linus publicly singled out the kernel versions that were released in sync with a Fedora version as being more stable than the average ones, thanks in no little part to the Fedora stabilization drive.
|
|
||||||||||||