Apples and oranges (Was: Re: FC2 Wishlist Items)

[Eric S. Raymond]

Jef Spaleta <jspaleta at princeton.edu>:
> Yikes!!!!!! Calling other people unimaginative in what is suppose to be
> a consensus process according to the leadership draft is probably not a
> good way to keep the 'important' people listening to you in the
> discussion.

Then it's a good thing that Warren Togami has enough imagination to
have encouraged me in pushing bugzilla-submit forward, isn't it?

Don't overinterpret what I said.  I referred to the right kind of imagination
as apparently being in *shorter* supply here for a reason, because I know
very well it's not absent.  At least some of the key Fedora people clearly
get what I am driving at and like it.
 
> > That degree of imagination is certainly present at cAos and
> > freshmeat.net and the bugzilla project, all of whom are actively
> > cooperating with my efforts to reduce the hassle factor in shipping
> > releases.  I find it disappointing that such imagination seems to be
> > in shorter supply here.
> 
> What you call hassle...i call at best healthy discussion..and at worse
> premature discussion considering the state of affairs inside Fedora in
> terms of public facing infrastructure.

I wasn't referring to the hassle of discussing or inventing a
submission policy, but strictly to the hassle and mechanical friction
costs of shipping releases.  Please don't inject political content
where there isn't any intended.

Frankly, I am not very interested in QA policy questions; you guys can
politic all you like about that and I will care very little.  What I
want to do is make sure the software is in place to reduce the purely
*mechanical* friction in the submission system to as near zero as
possible.  I am putting my coding effort where my mouth is on this;
freshmeat-submit, shipper, and bugzilla-submit (all of which I've
shepherded out the door within the last three months) are substantial
progress.  fedora-submit is the next logical and necessary step.

>       Let's look instead to educating the Fedora community about the
> cAos process and see if there are valuable lessons and ideas that can
> influence the discussion about what the final fedora submission process
> will look like.

Indeed.  I think the basic cAos idea of allowing scripted submissions
to an untrusted repository and then filtering that is very sound.  Among
other things, it lets the project experiment with different QA strategies out
of sight of the basic submission tools, with the untrusted repository as
a buffer.

>             I'm pretty sure no one of merit, thinks there isn't room
> for significant automation of the process, but what exactly the
> automation looks like is going to be colored by other factors about how
> much interaction the final policies demand between packager/submitter
> and QA as part of the submission process.

However that interaction works, the basic requirements are going to look like
this:

1. Submitters need to be able to drop source archives and associated
   metadata in an incoming queue.  Whether the submission package is
   just an SRPM or a tarball plus some kind of associated job card 
   like an LSM is a lower-level detail; I lean towards SRPMs myself
   but I don't fundamentally care.

2. QA people will be processing the queue, a task which will come down
   to accepting/rejecting incoming packages and communicating with the
   developer about resubmissions of fixed versions of the rejects.

3. There will need to be some master record that anchors the QA process
   relating to a particular package -- a pointer at the current submission,
   a private email list for the developer/QA conversation, etc.  fedora.us
   uses Bugzilla records to implement this.

The bit I'm interested in automating is the "drop it in the queue" part.
This implies (1) knowing how to put submissions in the right place, 
and (2) some ability to mechanically add "looky here!" updates to the 
master record (hence, bugzilla-submit).

Whatever goes on in the QA conversation is mostly orthogonal to this 
level of the design.

>                                        Using the current fedora.us
> policy as a baseline (because its the only baseline that exists) I don't
> see an inherent incompatibility between fedora.us's current policy and
> setting up an incoming srpms/specs holding pin as a pre-QA que step.

Agreed.  I have, as you might expect, thought this through fairly
carefully.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>