FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Mike McGrath mmcgrath at redhat.com
Sat Feb 27 21:48:08 UTC 2010

On Sat, 27 Feb 2010, Till Maas wrote:

> On Sat, Feb 27, 2010 at 10:45:49AM -0600, Mike McGrath wrote:
> > On Sat, 27 Feb 2010, Till Maas wrote:
> > > Did you read what he wrote? I feel tempted to just copy the paragraph
> > > Kevin wrote again, because it already answers your question: Rawhide is
> > > not partly rolling as Fedora is.
> > > And a typical reason not to upgrade from F(current-1) to F(current) is
> > > because the major updates may make systems unusable, e.g. X not working
> > > anymore. But this does not mean that the same person does not want
> > > bugfixes for e.g. yum-builddep installing build dependencies again.
> > >
> >
> > This doesn't make sense.  They either update at the end of a release or
> > the begining or middle, still, they have to update or live with an
> > unsupported system.  It's not like you can not upgrade to F current for
> > very long.
> It allows to fix the bug in F(current) for 7 months until the user needs
> to upgrade from F(current-1). And then he could also skip one release
> and have a higher chance of the bug being fixed. Nevertheless, this is
> just a description of the situation. I like it more to have bugs fixed
> in F(current) at the cost of not fixing that much bugs in F(current-1)
> to keep it stable.
> > So instead of choosing when to make their system unstable, parts of it
> > become unstable throught the release without any coordination.  I wake up,
> > go to work, suddenly I've got a different version of KDE then I had
> > yesterday.  And you guys think that makes me think more highly of Fedora
> > and not less?
> Afaik the KDE updates work very well and I know a fanatic KDE user who
> cannot expect to wait for the next KDE update, because he knows of bugs
> that are fixed in it. Usually he does not even need to report them,
> because they are already in the KDE upstream bug tracker. So this
> "release becoming unstable" is imho a little exaggerated, because nobody
> is proposing to track unstable upstream releases/upstream SCM with
> updates.

I'm sure that guy loves it.  Me?  I don't like not being able to predict
what my desktop looks like tomorrow.  Just so I'm clear, if we had
implemented what you are proposing...  Fedora 11, Fedora 12, Fedora 13
branched and rawhide would all be identical right now as far as package
version numbers go?


More information about the devel mailing list