[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fwd: Fedora & openSUSE meeting / cooperation ?]

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.


* http://www.flickr.com/photos/christopherblizzard/376867422/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]