Stable release updates vision

[Kevin Fenzi]

On Thu, 11 Mar 2010 13:22:58 -0500
"Paul W. Frields" <stickster at gmail.com> 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
...snip...

Thanks Paul and the Board for working on this. 

I'd like to provide my personal feedback here. Note that I am speaking
only for myself, not fesco. 

> The update repositories for stable releases of the Fedora distribution
>should provide our users with a consistent and high quality stream of updates.

I agree with this. 

>Stable releases should provide a consistent user experience throughout the lifecycle, 
> and only fix bugs and security issues.

I agree with the spirit of this, but I think it could be bad if it's taken to the letter of the statement. 
For example: 
- A design flaw causes a security problem, requiring a new version to fix. 
- A security fix is not backportable to an old upstream release, requiring a new version. 
- Software we ship thats under very rapid upstream development (ie, they don't have the 
interface locked down when we first ship it, then do, shouldn't we be able to ship the new version
with the finallized interface) (yes, you might argue we shouldn't ship it at all, but... )

So, while I think this is good to aspire to, there will be corner cases and exceptions. 
Does the Board think this should be subject to exception? Or is this an absolute?

>Stable releases should not be used for tracking upstream version closely 
>when this is likely to change the user experience beyond fixing bugs and security issues.

Sometimes it's hard to know... but agreed. 

>Close tracking of upstream should be done in the Rawhide repo wherever possible, 
> and we should strive to move our patches upstream.

Agreed completely. 

> More skilled and/or intrepid users are encouraged to use Rawhide along with 
> participating in testing of stable branches during the development and pre-release period.

I think making rawhide more day to day consumable is a good goal as well. 

> Stable releases, pre-release branches, and Rawhide have a graduated 
> approach to what types of updates are expected. For example, a pre-release branch 
> should accept some updates which a stable release would not, 
> and rawhide would accept updates that are not appropriate for either a stable release or a pre-release.

Different releases are different, sure. ;) 

> Project members should be able to transparently measure or monitor 
> a new updates process to objectively measure its effectiveness, and 
> determine whether the updates process is achieving the aforementioned vision statements.

Ideas on how to do this? Currently we have some people who see no
problem at all, and others who do feel there is a problem but find it
hard to qualify. 

I guess the only thing I could think of is graphing bugs filed over
time, and see if that changes when a new updates policy is put in
place, but if we are doing more testing there could likely be MORE
bugs, not less. An increase in usage of updates system might be some
indicator, but not sure thats success or failure. 

Any other ideas how the Board would like to see success or failure
measured? 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100312/59b678b5/attachment.bin