ESR "fedora-submit"

[Jeff Spaleta]

On 12/24/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Jeff Spaleta <jspaleta at gmail.com>:
> > cvs commits into the cvs trees are of course scriptable.  Once your
> > package has been reviewed and you have gotten approval, its just a set
> > of cvs operations to keep the package updated.
>
> Aha!  This begins to sound like a constructive response!
>
> > Update the spec file and the patch files, update the source
> > look-aside, make tag, make build, not much to it really.
>
> What's a "source look-aside" in this context?

the look-aside cache is the magical place where cvs can hold binaries,
like an upstream tarball.  make new-sources  is the makefile target
which does the necessary magic which I don't care enough about to
understand completely.  As Micheal pointed out, the process to update
an srpm in fedora extras is pretty simple now and is controlled via
Makefile.common available in the cvs trees.  While you can use the
available cvs-import.sh script for all the srpm's uploaded into cvs, I
personally don't like do it, because I've gotten into trouble with
incorrect cvs tagging across release branches when I've used
cvs-import incorrectly.

> I wholeheartedly agree.  The reason I did Bugzilla scripting in 2003 was
> that I understood that to be the mechanism in plan for updates.  Trying
> to script initial submission would be loopy, and I never proposed it.

Things have changed, 2003 was a long time ago for project policy and
infrastructure.  We are in the 2nd age of fedora contributor
infrastructure now, with a reasonably scriptable cvs server and build
automation.  In fact we will soon see the birth of a 3rd age of
infrastructure when Core and Extras merge into a common buildsystem.

> See, now *this* is material to the issue in a way that Warren Togami
> stupidly and arrogantly telling me I'm "on crack" is not.

Shrug, just as long as you realize that nothing I'm saying now should
be interpreted as endorsement of any idea you may have now, may have
had in the past, or might have in the future.  And you should know
that I reserve the right to verbally rip out your spleen through your
left ear if I find that you have decided to quote anything I say out
of context and without direct citation back to this mailinglist
archive.

> Note: I am *not* describing this because I necessarily want or need to
> drop my RPM directly into a Fedora repo.  I'm describing this so you
> understand that I could actually build an rpmlint check into shipper.

What rpmlint does is not fully equivalent to what people do when they
read over specfiles.
One concern is that the specfiles state somewhat human-readable, and
depending on how one automates the creation of their specfiles, this
could leave some decidedly un-intuitive artifacts which hamper a
human's ability to read the specfile without causing an rpmlint
warning or error.

> Jef, am I answering the question you were trying to ask?

Not really, the only thing that's going to answer all questions is to
shove one of your
packages through the review process and see if your scripts can deal
with an ever-evolving Fedora Packaging Guideline policy and if
reviewers can deal with any automation artifacts that are a result of
your scripts.

It would help however if you got re-acquainted with the fedora
contributor policy state-of-the-art.

http://fedoraproject.org/wiki/Extras/Contributors

-jef