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

Till Maas opensource at till.name
Thu Mar 4 22:09:58 UTC 2010


On Thu, Mar 04, 2010 at 03:59:16PM -0500, Doug Ledford wrote:

> 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

> So, I'm going to reiterate my policy suggestion:
> 
> Make Fedora releases (all of them) stable in nature, not semi-rolling.
> Make rawhide consumable as a semi-rolling release itself.

Imho this semi-rolling is too blurry, because only the technical
implementation give a grasp of what is rolling.

I thought I was pro semi-rolling, but the technical proposal did not
seem to fit my expectation. Here is what I would like to have as
semi-rolling. What I would like to have semi rolling is as many updates
that fix known bugs, even if only upstream knows them, as long as they
fit these criteria:
http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html

And they must pass all AutoQA tests, which is not a big issue currently,
but will be if AutoQA becomes what I would like it to be.

All other updates should only be mandatory like every six to twelve months.
Also I would like to have packages that are required to fix broken
updates be taken a little bit more care of. Afaik this is what is
happening with the critical path nowadays.

These are my desires as mostly a user. As a packager I would like to
also have some staging instance (like updates-testing), where I can
stage updates that are supposed to match the criteria, but can be easily
used to verify this. So I can tell users to verify that a bug is fixed,
if there is no easy way to reproduce it myself, e.g. if it requires a
complex setup.

Since there also needs to be a repo where things can be arbitrarily
broken to develop fixes, to satisfy this semi rolling approach and the
stable one is to create two more repos per stable release, so we would
have these:
fedora                 - initial release
updates-testing        - testing updates targeted at updates
updates                - semi rolling wrt. to above policy outline
updates-stable-staging - used to test updates for updates-stable
updates-stable         - only gets updates wrt. to a stable policy

To lower the demand of resources, the updates/updates-testing could not
be provided for the full lifetime of the release, but e.g. only for
around nine months. A Milestone could be the Alpha release of the
Rawhide branch of N+2, e.g.

F13 updates will be supported until F15 Alpha is created, so
everyone has a about a three month update window to get from FN-updates to
F(N+1)-updates or F(N+1)-updates-stable.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100304/fd3a1876/attachment.bin 


More information about the devel mailing list