Desktop Proposal

[Paul W. Frields]

On Mon, Oct 12, 2009 at 03:13:45PM -0700, Jesse Keating wrote:
> 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.

These experimental branches are not intended for test matrix
coverage.  They'd be purely for the developers to have WIPs that
aren't ready for public consumption.

> > * 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?"

I guess this goes hand in hand with the previous bullet.  If, for
example, a developer working on nautilus or glibc has changes in
progress and is working on those in a personal experimental package
branch, Rawhide itself would be more likely to run day to day. Someone
working on Bluetooth would be more able to live on Rawhide, again,
working on their stack in a personal experimental branch of some sort.

> > * 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 :/

I agree that there are probably thousands of edge packages that
wouldn't really need to be covered.

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

Not really -- the No Frozen Rawhide proposal doesn't yield any more
potential stability until after the first freeze point when it takes
effect.  What I'm talking about above would potentially provide a
Rawhide that was more often installable and usable throughout the
cycle.

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

I agree that NFR potentially does this after the first freeze point,
see above.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug