Showstopper in the RPM submission procesdure

[Eric S. Raymond]

Warren Togami <warren at togami.com>:
> Your suggestion of a fedora-submit script sounds like a good way to 
> reduce overhead in submitting Bugzilla reports for packages.  I am glad 
> somebody finally wants to implement it.  I suggest to you to read 
> through many of the fedora.us reports to see the steps involved in this 
> process.   Your script would need to (off the top of my head)
> 
> 1) Check for duplicates.
> 2) Submit a new report for a package, along with GPG signatures.
> 3) Submit revised packages along with new GPG signatures after some 
> discussion points out flaws.
> 4) Upload packages to *somewhere* which we still haven't worked out.  We 
> obviously cannot give CVS access to everyone, and there may be issues 
> with a public upload location at an official server.  I much prefer the 
> GPG signatures + submitter controlled URL process that fedora.us 
> currently uses, but perhaps a future process may have a hybrid.  The 
> more senior trusted packagers have upload access to an official staging 
> area or CVS, while everyone else uses GPG + URLs.

On point 1, the design of fedora-submit should not try to wire in
repository policy.  In particular, putting dup checking in there would
probably be a bad idea, as your concept of a dup is likely to evolve
over time.  For example, is it a dup when the same-named RPM is
submitted for two different trees?  You want to be able to change the
answers to questions like that without replacing every client instance
in the world.

Points 2 and 3 look right to me.  As a toolbuilder I'm agnostic on point 4,
but I share your preference.  There's no reason for your server to have
to pay storage costs for RPMs not yet accepted when a URL pointer can
be functionally equivalent to having a copy.
 
> Fortunately now that we are no longer an unaffilited 3rd party, I 
> believe we no longer need the many weird corner case naming 
> requirements.  The naming document can be greatly simplified, dropping 
> the leading "X.fdr." part of the %release tag and all related naming 
> policies because they are not needed any longer.

Good.  Then by all means nuke 'em.  

> In the mean time, please submit your packages to fedora.us in any matter 
> that you wish.  Don't worry if you don't understand the overly complex 
> naming guidelines, because the QA people will quickly point out errors.

OK.  I'll write fedora-submit and do some testing, then.  I think I've
essentially finished the bug-bugzilla tool that the first implementation
of fedora-submit will use; it's now in evaluation and testing with Christian
Reis of the Bogzilla project.
 
> BTW, your fedora-submit tools may be good for our RPM development 
> toolkit package "fedora-rpmdevtools" which is briefly documented here:
> http://www.fedora.us/wiki/FedoraRPMDevTools

Ahh, that's good to know.  Yes, that is obviously the right place. 
I see I even got the naming convention right :-).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>