Desktop Proposal

[Paul W. Frields]

On Mon, Oct 12, 2009 at 09:22:50AM -0700, Jesse Keating wrote:
> On Mon, 2009-10-12 at 10:42 -0500, Mike McGrath wrote:
> > This is not what updates testing is for.  Stuff in updates testing for F11
> > is for packages that are, ultimately, destined for F-11.  The experimental
> > repo for F-11 would be for packages that are destined for F-12 if at all.
> 
> Isn't that what rawhide is for?  If you're on F11, but want to test
> experimental stuff, well install it from rawhide.  You'll get to keep
> all the pieces.  If we're concerned about quality, I really don't think
> adding some weird mashup repos to the mix is going to help that at all.
> The more repos you throw out there, the more complex an environment may
> be and the complexity of the test matrix exponentially increases.

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;

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

* 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

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.

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

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