On Sun, 2008-05-11 at 11:37 +0300, George Billios wrote: > > Upstream maintainer and people > > closely following development think of a module as a list of new > > features and current bugs, shrinking and growing by time. If Adam > > thinks it's fine to include a prerelease of xorg in Fedora, then, well, > > it's fine. > > You (and others here) miss the point, that not everybody is a developer, > not everybody monitors the bug list but almost everybody can notice the > word 'prerelease' in the F9 release notes and would like a reason why > this happened. > > Take this for example: > > http://fedoraproject.org/wiki/Features/XserverOnePointFive > > It mentions that it is a prelease version but it doesn't justify why > including a prelease version is ok. It's the least buggy X server branch with the features we want. I admit, it's not a release, and that's entirely process failure on my part. Having lots of masters to obey is not easy, and in this case my time got chewed up by other business obligations. Thanks RHEL, you're awesome. So the thing I chose to sacrifice was the (actually fairly labor-intensive) process of badging the tarball as a release. It still got bug fixes. It's ABI-stable. Leaving it in was way less disruptive than reverting back to 1.3 would have been. It just isn't 1.5.0. I actually went on a long rant about this at xdevconf: http://xorg.freedesktop.org/wiki/Events/XDC2008/Notes The essential problem is that we're a victim of our own success. There's lots of great stuff happening in X and unfortunately the thing to suffer there is the stabilisation effort. I do the best I can but I'm not a superhero. Nor, really, should I have to be. And come to that, I'm actually quite bad at the release management job. I don't communicate effectively, I don't delegate enough, and I don't deliver on the schedules I promise. Mea maxima freakin' culpa. If someone else steps up to the job, huzzah. Until then we're sort of stuck. My question to the gallery is how do I fix this? How do _we_ fix this? X needs more people. It's way less scary than you've been led to believe. How do we get more people involved? How do we step up the testing effort? How do we get to a culture of frequent releases and incremental improvement? Without these things, release management is going to continue to be bursts of heroic effort that almost certainly misses deadlines, as it has been ever since Xorg 6.7. I mean, in some sense, it's fine. It's software just like any other, the number on the side of the box is merely a talisman, a dusting of holy penguin pee. But the release is also the primary artifact of the development process. Skipping that obligation is a disservice both to ourselves and our consumers. I hope we find an answer, but I just don't have one right now. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
