Release Lifecycle Proposals

Pull in other proposals, have kkofler review the semi-rolling proposal. Format the proposals to wiki syntax. Set up a way to organize feedback. Evaluations should be based in part on how well they satisfy people's prefered update styles

Semi-rolling (kkofler)

Because that comes with some types of disruptive changes which we do not
perform in releases and which I do not advocate performing in releases.
Rolling releases like Rawhide, Debian unstable, Gentoo etc. have no set
points to do disruptive changes. So e.g. you wake up in the morning and your
system no longer boots because your kernel upgrade from yesterday enabled
libata and you had hd* hardcoded in some place. (Yes, I know that particular
change is now a done deal, but there will definitely be similar changes in
the future.)

As I have explained several times, AIUI, a stable release MUST NOT get
upgrades which "break things", e.g.:
* require manual adjustment to config files, databases etc.,
* break support for existing user data (documents, configuration, savegames
etc.),
* knowingly introduce regressions,
* remove features,
* radically change the UI (but I don't think minor changes like a menu entry
moving to a different place are a serious issue),
* bump the soname of a core library on which dozens of packages depend (but
I don't personally see a grouped update with a soname change and a rebuild
of ALL packages using that library as a problem as long as it's only for a
few packages),
* change the API of a library in a way that existing applications using it
fail to rebuild and cannot easily be fixed (in fact soname bumps MUST be
accompanied by rebuilds of everything affected)
etc. (and I think we all agree there. But that's why Rawhide is not the
answer!), but IMHO (and there opinions differ), it SHOULD get upgrades
which:
* fix bugs, even if they're not critical or security,
* introduce features in a non-disruptive, backwards-compatible way (e.g.
there's now a new menu entry which does something cool, at worst that new
menu entry might not work perfectly, but it shouldn't affect anything else).

Snapshot (mmcgrath)

The idea behind this proposal is that when we release a new Fedora, it is a snapshot of rawhide at that time. Throughout its life-cycle, it should stay as close to that snapshot as feasible until it is EOLed. The policy is simple and quick to read. As a user I know what to expect from this policy and as a packager I know what is expected of me.

This will slow down updates on stable releases and allow developers / packagers to focus on the next release.

Stable Releases

• Enhancement-only updates would be discouraged.
• Backporting is preferred but understand not everyone has the time/know how to do it.
• We could treat crit path packages with even more scrutiny
• We could create a list of update types that we would not allow. For example: Fixing a br, license change, added doc, etc.
• Bug and security should be examined to determine if they actually impact Fedora and it would be up to the packager to decide if the update was worth the risk to our users or not.
• Provide facilities to sigs and developers to host 'add-on' repos so groups who want additional testing of $PACKAGE, besides just rawhide, could provide a yum repo for people to _manually_ add and test. For example, we could have an LXDE F-12 repo that has the latest versions of LXDE should the LXDE sig choose to do it. (My proposal is certainly not all or nothing, I could see this as causing more harm then good)

Special notes for rawhide updates:

• Anything that does not knowingly break things is fair game
• Things that require manual changes need to get sent / notified to the user (do we need to invent a mechanism for this?
• Such changes should end up in the release notes
• Changes which knowingly break things should be reported to the list/ announced with a timeline and rollback procedure.

Note: I'm not actually on FESCo so if people have a problem with that and ignore my proposal I won't take it personally ;-)

Choice (james)

Give the users choice, and do the expected thing by default

The idea behind this proposal is that a Fedora user installing a release N has a lot of choice if they wish to get newer packages:

• They can move to rawhide.
• They can install specific packages from rawhide.
• With NFR, they can now move to a pre-release of N+1.
• They can install specific packages from N+1.
• They can enable updates-testing.
• They can install specific packages from updates-testing.
• If they are on an older Fedora release, they can update to the latest Fedora release.

...but they have almost no options if they are happy to stay with the software that they have. It's also a common user expectation that updates within a release are mainly to fix bugs, and even then very minor bugs might not get fixed (but, if you need it fixed you have lots of choice above).

The way to add choice is to lower the numbers of updates that a user would see by default, and to lower the number of changes that those updates contain. This should be obvious, if you have 500 pending updates there is little choice but to just update everything and hope for the best. In the same way if a package contains 3-6 months of upstream changes then the user just has to hope for the best.

Due to the fact that Fedora cannot reward packagers for doing backports, or employ more developers, the only real option we have is to "punish" the kinds of updates which remove choice from our users. This will likely mean that some updates might not happen, that users would want if they looked at it independtly. But this is exected, as above, and as a known general rule perfect is the enemy of good.

Proposal

We deal with everything in "days spent in updates-testing" (DSUT). For each package this starts out at 4 days, which is roughly enough for the package to make it into a compose it to get to most of the mirrors and for interested users to easily test it. Each time a package moves from updates-testing => updates the DSUT for that package is doubled. So on the third update for a package the DSUT would be 16 days, however putting an updated package into updates-testing three times would keep the DSUT at 4 days.

For the current stable release we then apply a number of DSUTs to an update, depending on how complicated it is:

• High severity security bugs would get treated mostly as they do now, there would hopefully be more resources to backport fixes instead of rebasing ... but we need to get those out quickly, so they would have 0 DSUT.
• Lower severity security bugs would get 1 DSUT.
• New packages would get 2 DSUT.
• Backport fixes would have 3 DSUT.
• Fixes which include some new features (Eg. a minor upstream rebase, which is mostly fixes) would have 5 DSUT.
• Updates which contain lots of features/improvements (which may, or may not contain bug fixes) would havbe 10 DSUT.
• Any update not containing enough errata information to easily fit into one of the above slots would get 20 DSUT. This would include update information like "updating to upstream version 2.4.8".

Older stable release would be dealt with using a simple rule "all updates must first be in a newer release". This does mean that if you want to update to the version released in the current stable Fedora, it works just as above. This has a number of nice features allowing significantly tested packages that don't change much to easily make it back to older releases without causing any update problems.

Notes

While this may seem complicated compared to the other proposals it has a number of good properties and users should find it very simple to understand. Namely that released updates of packages will not update many times and will contain less changes.

Nice properties:

• If you are a "normal" part time packager, releasing new versions in new Fedora releases and just doing bug fix updates in stable releases nothing changes. You do a small update once, or maybe twice, a release and wait 1-2 weeks for testing before all users can get it.

• This is easy to implement on the rel-eng side, as no subjective decisions need to be made. All that happens is something takes the two numbers and multiplies them together (how many updates have moved to "updates" with this package name, and the one above given by the changes in the update) and anything can be pushed to stable after that amount of time. This could even be automated.

• Fedora wouldn't be dictating anything extra to packagers, if a packager wanted they could release a huge update at GA without any real explanation and users would still get it, eventually.

Slowing rate of change in older releases (mdomsch)

This proposal aims to address updates from a User, not a developer, perspective.

Terminology:

• Release N+2: aka Rawhide, the code base planned for release in 6-12 months.
• Release N+1: The code base currently branched from rawhide, under active development. (e.g. Fedora 13)
• Release N: The latest stable release currently advertised. (e.g. Fedora 12)
• Release N-1: The previous stable release, still capable of receiving updates. (e.g. Fedora 11)
• Release N-2: The previous previous stable release, which can only receive updates for 1 month after Release N (e.g. Fedora 10).

Reasons for doing versioned releases of a distribution

The _only_ reason to name something with a 'version' or a 'release' is to provide a set point for consistency, either in people's minds (marketing), or to provide a technical baseline for interoperability. If we continue to take the technical baselines, and move them ad-hoc, it's no longer a meaningful value.

Expectations by release

1. Users expect major package updates in Release N+2, as well as closely following upstream releases.
2. Users expect major package updates in Release N+1. While in development, both major and minor bug fixes, and behavioral changes are expected. After the Feature Freeze, these should be minimized.
3. Users expect updates for Release N to include all security and bug fixes, minor package updates, and minimal changes in functionality.
   1. Major Desktop environment upgrades would be unexpected.
   2. Library soname bumps would be unexpected, and should be the exception, not the rule.
4. Users expect updates for Release N-1 to be restricted to all security, and major bug fixes only. No major package updates, change in functionality, library soname bumps, or behavioral changes.
5. Users expect updates for Release N-2 to be restricted to showstopper bug and security fixes only, and only very clearly targeted and tested updates. No major package updates, change in functionality, library soname bumps, or behavioral changes.
   1. Major Desktop environment upgrades are unexpected and must be avoided.
   2. Library soname bumps are unexpected and must be avoided.

Contribution Quality Assurance (sadmac)

Keep things as they are, but define what precisely it is developers do which makes Fedora painful for users and create mechanisms to discourage or prevent maintainers from creating those problems on an as-warranted basis.

We would add one hard rule to updates against a released version to determine when measures should be taken: absolutely no regressions, or "if it worked yesterday it had damn well better work today."

Via Bugzilla statistics or whatever mechanism is most appropriate, it should be logged when this guideline is broken for a package, and how many times. A periodic mailing list posting should list regressions caused, in what packages, and by who.

Update Policy Adjustments

Maintainers continue to be the sole authority on what is appropriate for a release so long as they do not break the "one hard rule." Upon failing to uphold this rule one or more times, any one of the following can occur:

• Disabling of pushing direct to stable
• Mandatory karma requirements to push an update to stable
• Requiring approval by a package sponsor for all updates

This way, we allow maintainers to continue to decide individually what is appropriate for a release, bringing to that decision experience with their individual package, but we encourage caution and careful consideration of the end user.

Irresponsible Maintainer Process?

This proposal does not outline an irresponsible maintainer process, but it is possible that for packagers who display a profound ineptitude at maintaining package quality coupled with a general poor attitude toward other developers, contempt for Fedora policy and governance, or overall failure to "be excellent to each other" might be dealt with by such a process, wherein a consequence of having maintainership revoked or being forced to have packages re-reviewed might be imposed after due process by the appropriate bodies. Loss of provenpackager status might also be decided thus.

Semi-rolling rawhide plus rawhide-unstable

Policy statement

Make Fedora releases (all of them) stable in nature, not semi-rolling. Make rawhide consumable as a semi-rolling release itself.

Technical proposal

Make rawhide consumable.

 A) Create rawhide-unstable.  Any time a known disruptive change is
    being worked on, it should be built here by the developer.   In
    addition, add rpmdiff checks to all builds from devel into
    dist-rawhide and if any of certain rpmdiff checks trip positive,
    move the package from rawhide to rawhide-unstable.  Additional
    checks can be added as AutoQA gets into full swing, and so we can
    add more ways to catch breakage and move things to rawhide-unstable
    as needed.
 B) Non disruptive changes go into rawhide directly, and on a regular
    basis we run a compose on the rawhide tree to create install
    disks/images for use.  I suggest once a week we recreate the
    images.
 C) On a regular basis, we have a flag day to move items from
    rawhide-unstable to rawhide.  I originally said as-needed in my
    first proposal, but on more reflection I would like to suggest
    we make this a regular scheduled event on a monthly basis.  In
    this way we have 6 regular rawhide-unstable==>rawhide checkpoints
    between each release cycle, and we can make the last one or two
    prior to the next fedora release do double duty as both the
    normal checkpoint and the fedora alpha/beta freeze.  This also has
    the side benefit that people working on major changes, like say
    anaconda install updates, have more points at which they can get
    their code into a consumable segment of the repo and start getting
    feedback.
 D) Anyone who likes that rawhide allows them to develop directly
    on their OS can simply enable the rawhide-unstable repo in their
    yum configs.  Like enabling updates on a regular release, it
    would inherit from rawhide and also include all the distruptive
    changes.  This makes a system with rawhide-unstable enabled
    identical to rawhide today.
 E) Without rawhide-unstable, you get a semi-rolling release that
    allows for regular checkpoints to introduce disruptive changes,
    soname bumps, etc. only on a more frequent basis than the current
    fedora release cycle.  It is hoped that by having this higher
    frequency, disruptive changes in the semi-rolling release that is
    rawhide can be handled more easily.  Kind of along the lines of
    easier to deal with by taking more, smaller bites instead of huge,
    hard to swallow bites.

Make Fedora releases adhere to a stable release policy. This already covered rather well in proposals put forth by other people. Mike McGrath's snapshot proposal and Matt Domsch's Slowing rate of change in older releases proposal are the two I would pair with my proposal in order to satisfy both groups. I don't see any reason to rehash them here.