Stable release updates vision

[David Malcolm]

On Thu, 2010-03-11 at 10:40 -0800, Jesse Keating wrote:
> On Thu, 2010-03-11 at 13:22 -0500, Paul W. Frields wrote:
> > As noted in our previous minutes[1], the Board was tasked with
> > producing a vision statement for updates to Fedora stable releases.
> > That vision can be found here:
> > 
> > https://fedoraproject.org/wiki/Stable_release_updates_vision
> > 
> > This statement is the result of many Board discussions which have
> > taken into consideration issues raised recently in numerous other
> > venues such as the devel list.  After considering these issues
> > carefully, along with other factors such as the broad user base for
> > which we should strive[2], the Board feels this vision will best meet
> > the needs of our millions of users, including our contributor base.
> > 
> > The Board would like FESCo to read through this vision statement, and
> > use it as a basis for implementing changes that will help achieve this
> > vision.  We look forward to working with FESCo and across the whole
> > Fedora Project to continue improving the Fedora distribution.
> > 
> > 
> > * * *
> > [1] http://meetbot.fedoraproject.org/fedora-board-meeting/2010-03-04/fedora_board.2010-03-04-17.12.html
> > [2] https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html
> > 
> 
> As a first stab, I've linked to and incorporated some of the text into a
> document that tries to categorize the types of updates we do in Fedora.
> This document is meant to just categorize and explain, leaving any
> policy regarding -testing, -stable, or karma to other future documents.
> 
> https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal

In the hope that it's helpful, I wrote up some ideas yesterday about
Fedora package updates here:
http://dmalcolm.livejournal.com/5013.html
trying to enumerate the various differences that can exist between
different updates.  I tried to merely give a set of variables that could
be used to build a policy, rather than to give a policy, though in a few
places I suggested specifics (e.g. "having a meaningful %check is good")

I think we managed to not overlap - is it meaningful to merge my list
into yours, or is that for another document?  I think your document
considers updates from a "functionality" standpoint whereas mine does it
more from a "riskiness" standpoint.  Not sure.


I feel that our "updates system" is in some ways the emergent behavior
that happens when you combine all of our technical systems (bodhi, koji,
CVS, bugzilla, autoqa, PackageKit and other UIs etc, mailing lists,
forums) and all of the individual humans involved, and that bodhi is
merely one part of the picture; the overall "update system" emerges when
you consider all of these together, and it has both good and bad
qualities.

All of the underlying software systems are amenable to change, and I
believe (though this may be just faith) there are minor tweaks that are
possible that would greatly improve everyone's happiness with the
resulting (different) emergent behavior.


Hope this is helpful
Dave