Thorsten Leemhuis wrote:
I think the answer should be: as upstream maintainer get involved or at least in contact with the distributions. That's why I'd like to see upstream maintainers as co-maintainers in Fedora if possible.
I agree with that model especially in the case of components that are important to everyone else. i.e. gtk, gstreamer, the kernel, glibc, etc. But the farther down the stack the less important that becomes. For me it's a measure of how interdependent the various parts are.
<dreaming>Another possible solution: all (important) software agrees to use a similar, time based release scheme. E.g. everyone releases a stable version twice a year (March and September) and applies only bugfixes to the stable versions, while the devel stuff gets into the devel repo. The distributions could then push the updates to the stable distribution and the devel version to their devel tree, that gets a release in April and October. In other words: let the whole world aligns to the gnome release model and its foreseeable schedule</dreaming>
Heh, I would love that, too! But the number of items that are part of a particular release each increase the risk of that release slipping. Isn't this similar to the model that they have used in debian? If so, I fear for the kittens[*].
And I tend to think: that's not possible (or very very hard). The software packages in our distribution often has heavy inter-dependencies. So if you update one, then chances are high to break something else. Just take Firefox (galeon, liferia, yelp, several more use exactly the firefox version for which it was build), or gaim (some plugins like otr, libnotify) for example (there are a lot more), that are used by several other packages.
It's hard, sure. Isn't this also what Ximian used to do before they were eaten by the giant N? I remember a discussion of a database driven app that would create your spec files on the fly, etc, no matter what you were using. Not sure how it worked, either. I guess Luis can relay some of that if he chooses.
Then there are situations where one bug in packages foo and bar gets fixed with a update of package baz, but another one introduced in package foobar (the recent gtk2 update for FC6 for example, that broke drag and drop in thunderbird and firefox). Read: a lot of PITA, which I remember from the pre-Extras days (when you had to mix repos for add-on stuff), that still happens now and then these days in 3rd pary add-on repos that ship stuff Fedora can't ship. So IMHO the the distributor has to make sure people get what they want. My preferred solution for now would be two have different update channels: One that gets only "Security fixes and crucial bug fixes" (so more careful then Fedora Core currently), one that gets new versions of most package (rolling release, similar like Extras was, so a bit more bold then Fedora Core currently), while the crucial new stuff (new python for example) gets developed in the devel repository.
You've just described the RHEL/Fedora split quite effectively. --Chris * http://www.flickr.com/photos/christopherblizzard/376867422/ _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
