Desktop Proposal

[Jesse Keating]

On Mon, 2009-10-12 at 14:37 -0400, Paul W. Frields wrote:
> 
> Do you agree that our test coverage would improve if all the following
> happened?
> 
> * One or more experimental branches were offered beyond Rawhide for
>   daily work that might break critical path;

Each added repo increases the test matrix exponentially.  More repos
frankly == less likelihood of getting QA coverage.  Once we've frozen
rawhide and are ready to polish it into a release, an updates-testing
repo for the pending release makes sense.  Allow people to propose
freeze breaks, test them across a wide audience, and eventually push
them into the pending release (or drop them on the floor).  It does get
hard though if you want to push say a new gecko stack, and have to
rebuild 15~ packages along the way, then have to roll them back somehow.

> 
> * Rawhide itself -- at least the critical path -- was allowed to break
>   less in general so it was installable more often over a cycle; and

Of course this would improve QA coverage, however you need QA coverage
to prevent the breakage.  That's like saying "Would me giving you more
money improve your lack of money situation?"

> 
> * Our releases, once they arrive as GA, restricted updates to a degree
>   determined by FESCo to help maintain a more stable distro for our
>   target user

While I'd like to see a "calming" effect on our updates, perhaps it
really only matters for the critical path, changes that everybody sees,
but not across every package in the distribution.  One size policy,
while it's easier to write down, doesn't fit all very well :/

> 
> This might allow us to have a clearer separation from the product we
> push to everyone (including less experienced users), and the branch
> that our developers often install/run (when they can!).  As a result,
> regular contributors and power users might be able to migrate over to
> using Rawhide more often and as a result benefit the stable release
> through more regular testing, rather than waiting for some population
> of testers to download an Alpha or a Beta.
> 
> I'm not trying to drag the discussion away from the suggestion above.
> Rather, I wanted to counter-suggest that a three-pronged (stable,
> development, unstable) approach could work to better attain our goals.
> However, doing this obviously would require FESCo support and
> leadership over policy, some engineering work to rearrange these
> branches (?), and of course the general agreement that this was a
> worthwhile pursuit.

This is essentially the no frozen rawhide proposal that has already been
acked by FESCo.  Rawhide is every moving, never stopping, "unstable".
We branch it away at some point (feature freeze) and start polishing it
up for a release.  Some development is going on, fixing bugs in
features, etc..  This is "testing".  It'll eventually turn into the
"stable" release.  I can't very well ascii draw this.
> 
> I do agree that in this scenario, someone who wanted more
> latest-and-greatest should still update a package subset to Rawhide,
> and they would continue to have a reasonable chance of things working
> day to day -- which is not necessarily the case right now.
> 
> Of course, it could be a concern that Rawhide wouldn't move as fast or
> in concert if we had everyone doing private work, but I think there's a
> chance for us to do something innovative in terms of how that work is
> managed -- in other words, something like git for Rawhide++ (where
> Rawhide++ is the $TOTALLY_SCARY_RAWHIDE seen in bullet one above).
> 
> 

I think many people are struggling with the duality that is the repo we
call "rawhide".  For a period of time it is a repo where wild and crazy
changes happen and experimentation is done.  Then suddenly we throw a
switch and expect all that to settle down and to start treating rawhide
the repo as a stabilization point for all those wild changes.  Then we
throw another switch and expect rawhide to slow way down and basically
halt as we test and polish it up for a release.  That's a lot of
different ways to treat a single repo of packages.

That's why the no frozen rawhide proposal breaks that up.  rawhide the
path is always rawhide.  Always wild and crazy, always moving forward.
We create a new repo for the pending release (and give it a
updates-testing like repo for proposed changes for the pending release).
This allows us to slow down and stabilize without losing the benefit of
wild and crazy change in rawhide.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20091012/38e9a0da/attachment.sig>