Release Lifecycle(draft)

This page is a start at defining expectations for updating packages within the release. It's current aim is to document what people want, what we have now, and making proposals in how to change what we have now to satisfy more people more of the time.

Update styles

Re-add the definitions and examples of these that mediawiki deleted

These are the update styles that people have expressed as wanting.

• Rolling
• Semi-rolling
• QA'd -- This is a large category that we may want to break into further subdivisions. It includes forcing updates to go through updates-testing first, forcing updates through low risk
• Critical bugfix-only

Additional Considerations

Add additional considerations here

• Backporting -- Fedora does not currently require backporting of fixes. This means that in any style of update, a fix to one package could require updating other packages due to changes in the fixed package.
• Should new packages be considered as a special case of updates to existing packages and therefore have different rules?

Present lifecycle

Fill in definitions and have jkeating review for accuracy

• Rawhide
• Alpha
• Beta
• Preview
• Release/F-Current
• F-(Current-1)
• F-(Current-2)
• EOL -- from the yum update numbers, EOL is a reasonably active time for users even though there isn't any further development for maintainers.

Areas that we can change

• Length of time in updates-testing
• Review of update submission
• Where people start being able to use a release
• Criteria for making an update
• Requirement to backport
• Define different policies for F-Current, F-Current-1, and F-current-2
• Change the EOL time frame
• Enforce different policies on rawhide
• AutoQA test requirements

Technical things that can help

• Program to make submitting karma to bodhi very easy
• Program to get more users selectively using updates-testing
• Mark package updates with type (security, critical bug, major bug, minor bug, enhancement, etc) and have a yum plugin to allow clients to filter for the updates they want (note that the packages must still satisfy dependencies so a security fix may pull in various enhancements via package deps.)
• Have updates be placed into a set and pushed on a weekly/biweekly/monthly schedule so that QA can be run over a complete update set.

Proposals

Pull in other proposals, have kkofler review the semi-rolling proposal. Format the proposals to wiki syntax

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).