Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

[Simo Sorce]

On Fri, 12 Mar 2010 18:59:30 +0000
Andy Green <andy at warmcat.com> wrote:

> On 03/12/10 18:06, Somebody in the thread at some point said:
> 
> >>> In this context, if you're writing homegrown apps, you're a
> >>> "developer", not a "user", so the above sentence obviously does
> >>> not apply. Instead, my original point does (you'll be compiling
> >>> your own software very often anyway).
> >>
> >> It's a bit of a false dichotomy because I may be developing my
> >> stuff and using someone else's, but I take your point.
> >
> > You can call it a straw man, no problem calling things as they are.
> >
> > I love people quoting other people slightly out of context and
> > putting their spin on it to make a point ...
> 
> My dear Simo your IFF is malfunctioning.  "I take your point" is me 
> agreeing that I took his words out of context when I went back and
> read what he clearly quoted.  Having understood his larger point, I
> don't think splitting people into "developers" and "users" is a
> worthwhile distinction because all developers are users of something
> else.

I think we misunderstood each other on how we are referring to what.
Given the matter is completely knotted I give up commenting and
preemptively apologize to anyone that feel I said something wrong or
wrongly attributed something.

> At the company I am working for this whole subject has been a matter
> of great debate these last days about the best way to update our own
> stable packages for our own repo on top of a Fedora basis, by focus
> on backport or elevating our equivalent of rawhide into stable after
> thorough testing.

In general I think that point releases are a mean to provide users with
something usable somewhat consistent and that doesn't change too much,
so they can stick with it.
The others can adventure into rawhide.

If everything turns into rawhide why are we even doing point releases
at all ? Just have rawhide and push to ""stable"" stuff once enough
karma accumulates and have a constantly rolling release with no numbers
or anything.
Needless to say I don't think a constantly rolling release helps our
users. Even developers need to have something that doesn't move too
much under your feet. Developers are users too and need a distro they
can use for most of their tasks or the will move and develop elsewhere.

Although *some* developers need bleeding edge, they are normally a
minority, and they don't need bleeding edge everything, they can easily
pick from testing or rawhide what they need, or just rebuild from sprm
themselves.

> AFAICS the best way through it is a mixture depending on the exact 
> situation of each package and the divergence in the sources and libs. 
> If a fix we would like to have in stable is dependent on new APIs in 
> uplevelled libs, backporting becomes Hell given the need to retain
> the old APIs for packages that don't get updated while integrating
> new ones for the fix.

I agree with you. It is not a clear cut ban this, approve that.
But it is more a matter of tendency. The unstable repositories should
tend to upgrade often, the released stable repos shouldn't and
sometimes you have to just let a bug there and tell people to use the
newer release rather than breaking more stuff in a "stable" release to
cram in an update to fix a minor bug.

Security releases are more delicate and if necessary exceptions can be
made there, that's where rel-eng comes in.

> It pushes me towards thinking a solution by bringing in the new libs
> and accepting the damage in terms of uplevelling and retesting the
> users of the library can often be the right way.  And that seems to
> be Kevin's POV which is why I was surprised to misread what I misread.

I am not sure what's Kevin POV anymore, probably he has some sort of
view of what is the target user base and which packages should be fast
movers, but I can't make it up from his emails anymore.

If the position is that the status quo is fine, I have to disagree, we
have way too many updates in F-12, so from my POV something should
change to slow down the pace a bit. Whether that should be only done
for CRITPATH first and exclude some category of software that is not
installed by default I don't know; we can discuss that.
But the current status is not good IMO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York