To semi-rolling or not to semi-rolling, that is the question...

[Hans de Goede]

Hi,

On 03/04/2010 09:59 PM, Doug Ledford wrote:
> Obviously, some people want this and some don't.  It isn't appropriate
> to simply hand down an edict that things will be one way or the other if
> we truly consider Fedora a community run project.  It must be a
> community decision.  That means, as Adam Williamson pointed out, this is
> likely a decision to be made by the board, based upon what the community
> wants and what's best for Fedora.
>
> But let's be clear.  That's a *policy* decision.  One of the things that
> got very confusing in the previous thread(s) was the intermixing of
> policy decisions and technical issues.  For instance, Kevin's response
> to my proposal was all about technical issues he saw.  Technical issues
> are almost always solvable if you have a specific policy you are trying
> to implement.  So one thing I think people should keep in mind is that
> policy decisions should always lead to technical decisions, *not* the
> other way around.  We should decide what we want ourselves to be and
> what our policies are, and then that should guide our infrastructure,
> our tools, our work flows, and our processes.  We should never allow
> things to flow in the reverse direction.  We should never allow a
> current tooling limitation to set our policy, modulo that our policy
> should acknowledge and accommodate for the time necessary for tooling
> changes to take place or for the limitations of our resources.
>
> So, I'm going to reiterate my policy suggestion:
>
> Make Fedora releases (all of them) stable in nature, not semi-rolling.

One size does still not fit all, although this is a great idea for
most packages in Fedora for packages in certain niches this is a bad idea.

I've said this before (and got 0 response), I believe there should
be some divide made between core packages (with core being quite big, not
the bare essentials, but also most of all desktop environments, etc.) and
non core packages.

For example I really see no reason not to upgrade
some EDA tool to the latest and greatest if the maintainer thinks that
there are good reasons to do this, because the group of EDA users bitten by
potential regressions is small and EDA users are highly technical skilled,
so know how to downgrade if needed.

Another example is multiplayer games. In quite a few online gaming
communities, most of the community moves over to the latest release once it
is sanctioned stable by upstream. If the client <-> server version need to
be in sync (which they often do because they need the exact same maps),
then this means that our "stable" version in F-released might become
worthless pretty quickly as there are no or very little "stable" version
servers available to play on.

I strongly urge FESco to come up with a policy which is flexible enough to
handle these kind of special cases, without requiring going to rel-eng for
an exception each and every time. And to mandate that the tools are
flexible enough too.

Also I cannot get rid of the collective punishment feeling here, because
a few people do crazy things, ALL of us loose the right to apply common
sense and have to adhere to strict policy and jump to even more hoops to
get updates out there. How about a FAS flag which decides if a maintainer
can skip updates-testing, which default to yes, and take this away from
people who show to little restraint in skipping updates-testing ?

> Make rawhide consumable as a semi-rolling release itself.

We already have this it is called early branching of the next release. I
would fully agree with you if it were not for the early branching
feature, which means we effectively already have such a release, except
the first 2 months or so after a release, at which time rawhide
tends to be very volatile in general (*), so a stabilized rawhide would
pretty much boil down to the latest release anyways.

Given that we pretty much already have this my reaction to this is
please not another tree!

* (we still need to see if no frozen rawhide changes this)

Regards,

Hans