Re: Showstopper in the RPM submission procesdure

[Warren Togami <warren togami com>]

Eric S. Raymond wrote:
> regardless of how the process is actually implemented.  My present
> plan is to implement fedora-submit as a wrapper around a script for
> submitting Bugzilla bugs (which script I have just finished writing) 
> but that is an implementation detail about which the user should not
> have to care.  If you guys want to change the implementation mechanism,
> you just tell me and I'll make fedora-submit use it.
>
> So let's *not* get sidetracked onto whether the submission process 
> is right or not.  Just tell me what it actually *is*.


Fedora.us is not "The Fedora Project".  Fedora.us is the older packaging 
project for united volunteer packagers around the RH platform.

(Fedora.us continues in operation during the next few months while the 
new Fedora is in progress.  No packages will be published from the new 
Fedora for quite a while because all the infrastructure, policies, 
standards and procedures need to be formed.  It has been unofficially 
suggested by some RH elders to point people at fedora.us for package 
submission and approval during these next few months because 
fedora.redhat.com is NOT READY.  fedora.us is recognized as having some 
technical clue and over-paranoid reluctance in accepting stuff, so stuff 
that is accepted is likely to be accepted into Fedora Extras much more 
readily at a later date .... after legal approvals and stuff... stuff 
stuff stuff)

It was our (fedora.us) intention from the beginning to better automate 
the submission process with command-line based tools, and eventually 
write a (RDBMS) database driven management system.   Until the effort 
was put forward to make that happen, Fedora.us had used a Bugzilla based 
package submission, QA discussion and tracking system.  It worked great 
for the publication of hundreds of packages, with almost 200 more 
currently needing QA approval.

However this being said, there has been almost zero discussion about 
whether the new fedora.redhat.com will use anything like fedora.us' 
submission and approval process.  While we don't know yet 
fedora.redhat.com will become, now is the time to experiment with 
fedora.us to learn more about "What works" and "What doesn't".

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.

(Sopwith, the "hostile build" requirement with mach+vserver would be a 
boon in the "everyone else" category, because automation greatly reduces 
the amount of man-hours needed for package development while reducing 
the cost of entry for new-comers.)

Regarding your other comment regarding the over-complexity of package 
naming requirements in fedora.us documents: May I warn the feeling of 
"too-complex" may be partly from ignorance of the complexity of avoiding 
clashes.  There are a great many common problems that happen when people 
do not THINK when creating their package.

Those requirements for seemingly over-complex naming requirements was 
the result of arguing for almost 4 months with no useful packaging 
happening.  The guidelines were mainly about preventing common cases 
where "Epoch" needs to be incremented for poor reasons.  Unfortunately a 
large part of the other requirements were based upon assumption that Red 
Hat would not pay attention to our naming scheme or packages, and we 
needed to avoid any chance of conflicting with future RH updates.  In 
almost all cases the naming scheme has successfully avoided naming and 
version clashes with RH released, errata and beta packages.

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.
(We would need to have some common agreement with RH and fedora.us 
packagers in order to make this official, but I believe that will be an 
easy sell after I post my upcoming draft for "Fedora Project package 
naming conventions" for fedora.redhat.com.)

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.

You mention that you would like to help in rewriting that documentation. 
 We would greatly appreciate your help in doing so (and I personally 
like your writing skills), but may I highly suggest seeing the actual 
old and inefficient process in motion for a while before making any 
assumptions.

Also it is my opinion that while our current GPG requirements and manual 
Bugzilla usage seems like a "waste of time", that time requirement pales 
in comparison to the QA approval process.  fedora-submit and improved 
command line tools integrated with GPG would speed up the Bugzilla 
report communication process would be a plus to that process.

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

Warren Togami
warren togami com