Showstopper in the RPM submission procesdure
Warren Togami
warren at togami.com
Mon Sep 29 11:24:58 UTC 2003
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 at togami.com
More information about the fedora-devel-list
mailing list