Desktop Proposal

[Stephen John Smoogen]

On Tue, Oct 13, 2009 at 7:11 AM, Paul W. Frields <stickster at gmail.com> wrote:
> 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.

Ok speaking as a systems admin and not the guy who has to wrangle
cats... but could a system based more on the git workflow be something
to work towards? Instead of developers pushing stuff into rawhide,
stuff is pulled into rawhide. If it doesn't meet some minimal test
requirements the merge is dropped. Project teams/developers work on
their own 'spins' that can be pulled up through a similar signoff
mechanism as the kernel uses.


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning