From Fedora Project Wiki

 
(23 intermediate revisions by 3 users not shown)
Line 2: Line 2:


== Update styles ==
== Update styles ==
{{admon/note||Re-add the definitions and examples of these that mediawiki deleted}}


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


* Rolling
* Rolling -- This is essentially what our current no-frozen-rawhide is.  Every packager can update their packages whenever they want.  Although breakage is discouraged, breakage can occur with some regularity due to packages being upgraded while their dependent packages are not, the inherent greater risk of regression in the updates occurring in rawhide, and the current world where updates in rawhide are not always tested by the people who are packaging.  Updates to new major versions are expected.  Note: no one has expressed a desire to consume this.
* Semi-rolling
* Semi-rolling -- Major updates do occur but they are worked on as a set to avoid breaking deps.  The updates undergo extensive testing (KDE SIG pushes the packages through kde-redhat, rawhide, and updates-testing before they hit updates repo) before going to stable.  Critical bugfixes and bugfixes evaluated as low risk are pushed directly to stable.  Other changes (enhancements, for instance) are pushed through updates-testing first.  This is the current practice of the KDE SIG.  There is a proposal that rawhide should somehow be moved to a more semi-rolling model so that people would be willing to consume it directly instead of pushing changes to released Fedoras.
* 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, updates-testing with exceptions for low risk updates and critical fix updates, simply adding AutoQA tests that must be passed to go to updates, requiring some amount of karma before a package can go to updates.
* QA'd -- This is a large category that we may want to break into further subdivisions.  It includes separate proposals to force updates to go through updates-testing first, forced updates-testing with exceptions for low risk updates and critical fix updates, simply adding AutoQA tests that must be passed to go to updates, requiring some amount of karma before a package can go to updates, only allowing bugfixes into updates. (feel free to list others)
* Critical bugfix-only
* Critical bugfix-only -- this style only allows critical bugfixes (including security updates) to go to updates.  Note that in Fedora, this would likely drag in some enhancements due to package dependencies and no requirement to backport.  An extreme example of this is the practice employed by updates to a RHEL-5.N release (and to a lesser extent by RHEL5.N to 5-M).


=== Additional Considerations ===
=== Additional Considerations ===


{{admon/note||Add additional considerations here}}
{{admon/note||Feel free to add more 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.
* 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.
Line 22: Line 20:
{{admon/note||Fill in definitions and have jkeating review for accuracy}}
{{admon/note||Fill in definitions and have jkeating review for accuracy}}


* Rawhide
* Rawhide -- Anyone can submit a package at any time.  Breakage is discouraged but in practice does occur.  There is no testing repository, updates go directly into rawhide.  Packages built are available for building against very shortly afterwards.  Rawhide is composed once a night with possibly broken deps across packages if people are in the middle of a multipackage rebuild.  Koji tags have been used for some large updates to try to mitigate the latter.
* Alpha
* Alpha -- begin to use bodhi with updates-testing repo ("stable" updates go to the actual release tree).  Major features should be in place but backwards incompatible changes can still occur.  critpath packages get more scrutiny (need to be acked by releng) than non-critpath packages.
* Beta
* Beta
* Preview
* Preview
* Release/F-Current
* Release/F-Current
* F-(Current-1)
* F-(Current-1) -- Currently the same as F-Current
* F-(Current-2)
* F-(Current-2) -- Currently the same as F-Current
* EOL -- from the yum update numbers, EOL is a reasonably active time for users even though there isn't any further development for maintainers.
* EOL -- No further package updates.  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 ==
== Areas that we can change ==
{{admon/note|To merge|Ideas from [http://dmalcolm.livejournal.com/5013.html dmalcolm's blog post]}}


* Length of time in updates-testing
* Length of time in updates-testing
Line 42: Line 42:
* Enforce different policies on rawhide
* Enforce different policies on rawhide
* AutoQA test requirements
* AutoQA test requirements
* Multiple update streams (security, bugfix, enhancement)
* Different policy for critpath (or other subset of important/popular packages)
* Length of support for releases
* Differing support lengths for different releases
* Length of development for a release


=== Technical things that can help ===
=== Technical things that can help ===


* Program to make submitting karma to bodhi very easy
* Program to make submitting karma to bodhi very easy
** make ABRT pop up and ask "is this working for you? yes/no
** Panel applet or something that pops up a list of testing packages you have that you (1) Haven't submitted karma for yet, (2) Have used so you can submit +1 karma
* Program to get more users selectively using updates-testing
* Program to get more users selectively using updates-testing
* Previous two as tabs in packagekit
* 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.)
* 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.
* 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.
* More repositories that have different policies
* Make it easy to use different build tags in koji (tag to rebuild a set of packages and their dependencies.  Once the rebuild is done, push it back into the main tree.)
* The Bugzilla comments that Bodhi sends probably need some work.  They're currently very complete and factual but they don't include any information for the less experienced users who are often filing bugs.  Those people have reached out to contribute something, they want to continue that engagement (i.e. get a fix), and we could have a mutually positive exchange with them.  By not giving them clear information we're putting that opportunity at risk. (stickster)
* A notification mechanism for people to opt-in to.  If they have a package installed that has known bugs.  The notification mechanism should "pleasantly coerce" the user to test, but letting them know we can't promise it will work.  If it doesn't, our tools should be able to undo that transaction gracefully -- start from current updates, try test, if failing 'yum history undo' back to current update. (stickster)
* Being able to achieve karma right after the build is done (jkeating) (is this already doable in bodhi?)
* Better description for bodhi-client package; enhance bodhi-client man page to show how end-users can use it to comment (if that's possible ATM)


== Proposals ==
== Proposals ==


{{admon/note||Pull in other proposals, have kkofler review the semi-rolling proposal.  Format the proposals to wiki syntax}}
{{admon/note||Moved to [[Release Lifecycle Proposals]]}}
 
== What other distros do ==


=== Semi-rolling (kkofler) ===
{{admon/note||This section is informational only.  Fedora should neither do something listed here to copy another distro nor avoid something here because other distros do it. This can be a place to draw ideas from but whether they make sense Fedora depends on how they map to Fedora's goals and the needs of people consuming updates}}
<pre>
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
* Ubuntu - https://wiki.ubuntu.com/StableReleaseUpdates
upgrades which "break things", e.g.:
* RHEL - http://www.redhat.com/security/updates/errata/
* 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).


</pre>
[[Category:Policy]]
[[Category:Draft documentation]]

Latest revision as of 19:01, 9 March 2010

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

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

  • Rolling -- This is essentially what our current no-frozen-rawhide is. Every packager can update their packages whenever they want. Although breakage is discouraged, breakage can occur with some regularity due to packages being upgraded while their dependent packages are not, the inherent greater risk of regression in the updates occurring in rawhide, and the current world where updates in rawhide are not always tested by the people who are packaging. Updates to new major versions are expected. Note: no one has expressed a desire to consume this.
  • Semi-rolling -- Major updates do occur but they are worked on as a set to avoid breaking deps. The updates undergo extensive testing (KDE SIG pushes the packages through kde-redhat, rawhide, and updates-testing before they hit updates repo) before going to stable. Critical bugfixes and bugfixes evaluated as low risk are pushed directly to stable. Other changes (enhancements, for instance) are pushed through updates-testing first. This is the current practice of the KDE SIG. There is a proposal that rawhide should somehow be moved to a more semi-rolling model so that people would be willing to consume it directly instead of pushing changes to released Fedoras.
  • QA'd -- This is a large category that we may want to break into further subdivisions. It includes separate proposals to force updates to go through updates-testing first, forced updates-testing with exceptions for low risk updates and critical fix updates, simply adding AutoQA tests that must be passed to go to updates, requiring some amount of karma before a package can go to updates, only allowing bugfixes into updates. (feel free to list others)
  • Critical bugfix-only -- this style only allows critical bugfixes (including security updates) to go to updates. Note that in Fedora, this would likely drag in some enhancements due to package dependencies and no requirement to backport. An extreme example of this is the practice employed by updates to a RHEL-5.N release (and to a lesser extent by RHEL5.N to 5-M).

Additional Considerations

Note.png
Feel free to add more 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

Note.png
Fill in definitions and have jkeating review for accuracy
  • Rawhide -- Anyone can submit a package at any time. Breakage is discouraged but in practice does occur. There is no testing repository, updates go directly into rawhide. Packages built are available for building against very shortly afterwards. Rawhide is composed once a night with possibly broken deps across packages if people are in the middle of a multipackage rebuild. Koji tags have been used for some large updates to try to mitigate the latter.
  • Alpha -- begin to use bodhi with updates-testing repo ("stable" updates go to the actual release tree). Major features should be in place but backwards incompatible changes can still occur. critpath packages get more scrutiny (need to be acked by releng) than non-critpath packages.
  • Beta
  • Preview
  • Release/F-Current
  • F-(Current-1) -- Currently the same as F-Current
  • F-(Current-2) -- Currently the same as F-Current
  • EOL -- No further package updates. 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

Note.png
To merge
Ideas from dmalcolm's blog post
  • 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
  • Multiple update streams (security, bugfix, enhancement)
  • Different policy for critpath (or other subset of important/popular packages)
  • Length of support for releases
  • Differing support lengths for different releases
  • Length of development for a release

Technical things that can help

  • Program to make submitting karma to bodhi very easy
    • make ABRT pop up and ask "is this working for you? yes/no
    • Panel applet or something that pops up a list of testing packages you have that you (1) Haven't submitted karma for yet, (2) Have used so you can submit +1 karma
  • Program to get more users selectively using updates-testing
  • Previous two as tabs in packagekit
  • 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.
  • More repositories that have different policies
  • Make it easy to use different build tags in koji (tag to rebuild a set of packages and their dependencies. Once the rebuild is done, push it back into the main tree.)
  • The Bugzilla comments that Bodhi sends probably need some work. They're currently very complete and factual but they don't include any information for the less experienced users who are often filing bugs. Those people have reached out to contribute something, they want to continue that engagement (i.e. get a fix), and we could have a mutually positive exchange with them. By not giving them clear information we're putting that opportunity at risk. (stickster)
  • A notification mechanism for people to opt-in to. If they have a package installed that has known bugs. The notification mechanism should "pleasantly coerce" the user to test, but letting them know we can't promise it will work. If it doesn't, our tools should be able to undo that transaction gracefully -- start from current updates, try test, if failing 'yum history undo' back to current update. (stickster)
  • Being able to achieve karma right after the build is done (jkeating) (is this already doable in bodhi?)
  • Better description for bodhi-client package; enhance bodhi-client man page to show how end-users can use it to comment (if that's possible ATM)

Proposals

What other distros do

Note.png
This section is informational only. Fedora should neither do something listed here to copy another distro nor avoid something here because other distros do it. This can be a place to draw ideas from but whether they make sense Fedora depends on how they map to Fedora's goals and the needs of people consuming updates