| fedora-submit |
bugzilla-submit
rather than bug-bugzilla.fedora-submit prototype now has a
character-set-conversion option.fedora-submit.
All my to-do items are either closed or waiting on
bugzilla-submit actually shipping.
fedora-submit will be a command-line tool that ships RPMs
to the Fedora project for inclusion in their repository. It will ship
with a future release of Fedora Core.
This tool will substantially reduce the friction cost of submitting and updating RPMs — in particular, it will mean that submission can be automated into a project's release machinery.
I'm working on this because I maintain thirty-six projects. An amount of pointy-clicky web-interface form-filling that would be acceptable for somebody with only one or two projects will drive me up a wall in short order.
Fedora practice is to accept RPM submissions as Bugzilla bug reports with attached content that is the RPM. This problem breaks naturally into two pieces: an engine that can script Bugzilla submissions, and a wrapper that generates the right Bugzilla submission by looking at the RPM. The engine is all mechanism, the wrapper is all policy.
The engine will be a program called bugzilla-submit
written by Christian Reis (of the bugzilla project) and myself. It
has already shipped with the Bugzilla unstable release, and there is
agreement from the Bugzilla folks that it will enter the main line.
The wrapper will be fedora-submit itself, and the Fedora
folks have agreed to carry that. I have a proof-of-concept, but it
hasn't been tested, because some other things need to happen first.
More on this below.
This page exists because most of the issues in making this work are
release management and integration problems. There is consensus from
both the Bugzilla and Fedora sides that fedora-submit is
a good idea, but the devil is in the details. Thus, it's useful for
there to be a scoreboard of progress and issues that everyone can
refer to.
Here are the Fedora and Bugzilla bug reports associated with these issues.
Release management: Currently bugzilla-submit
ships only in the Bugzilla contrib directory. This isn't really
appropriate. Most people who will want to install or package
bugzilla-submit won't be running a Bugzilla instance and
don't want or need the whole Bugzilla distribution.
bugzilla-submit needs to be its own Bugzilla product,
downloadable separately from a stable location on the Bugzilla site.
Stability: bugzilla-submit needs to be coded
so that it can detect an instance of Bugzilla it's not compatible
with. Field-name cleanup in Bugzilla has been postponed, so this
will have to be done by API version stamp.
This ties into the release-management issue in that a user who gets
a version-skew error from bugzilla-submit needs to be able
to download a replacement without having to cope with the whole
Bugzilla release.
For fedora-submit to be available in Fedora Core,
a couple of things need to happen:
The maintainer for the Fedora RPM-tools package should
incorporate fedora-submit into it, with a dependency on
the bugzilla-submit RPM. Obviously this can't happen until
the script is ready.
The good news is that fedora-submit is so trivial that I
expect it to be effectively zero-maintainence once it's incorporated.
An RPM for bugzilla-submit needs to become part of Core.
It needs a packager. That could be me, but I don't know the right
RPM black magic. The right person to do this is probably the maintainer
for the Fedora RPM-tools package, which will be depending on
bugzilla-submit.
I have written a proof-of-concept.
This demonstrates the hard part, which is mining the appropriate data
for the bug out of the RPM and generating the request for
bugzilla-submit to chew on. It doesn't do the easy part,
which is actually invoking bugzilla-submit.
fedora-submit needs to be finished. That's waiting on
a production version of bugzilla-submit shipping; it's maybe
two hours' work, max.
These are issues that should not hold up an initial release.
Validation: Because of the RDF brokenness, the validation
bugzilla-submit does is somewhat crude. Instead of
scripting CGI, it should probably go through the XML-RPC interface of
Bugzilla, validating against the RDF.
Fortunately this change should be user-invisible. Unfortunately, a good solution is contingent on the RDF being stable, which is in turn conditional on the internal-fieldname cleanup that has been postponed. At this point it's a wish-list item that should not hold up release of a working version.
bugzilla-submit, after
extensive hacking by ESR. Principal contact on the Bugzilla side.