ESR "fedora-submit"

[Eric S. Raymond]

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?
 
> Scripting of the submission into the review process is as scriptable
> as opening a bugzilla ticket is. But I see little or no value here in
> scripting the opening of review tickets, since even if a person
> maintains 100+ projects, its certaintly not a good idea to initiate
> 100+ review tickets in one push.  And you cerntaintly can't script the
> communication you have with the reviewers on each of your open
> submission tickets.

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.

> The potential problem with scripted interactions, as I see it, is can
> you have scripted actions that producee the spec files that conform to
> the current Fedora Packaging guidelines? If the automation ends up
> adding non-obvious specfile elements which impair human reading of the
> specfile, then we are going to have a problem.

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.

Let me tell you what I do on my projects.  I normally have a spec.in
file in which I keep my project changelog.  I start my release process
with 'make dist', which generates a spec file with the current version
number plugged in.

When I invoke 'shipper', one of the things it does is build RPMs from
the generated specfile.  Those get uploaded to whatever channels I
have designated for the project.

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.
If it doesn't pass, shipping would get aborted *immediately*, before
anything got shipped to anywhere.  This would be in conformance with
shipper's design philosophy -- part of which is, if you automate
testing *you will do more of it*.

I think I can ensure that bad things don't get written into the spec file
you see by (a) rpmlinting every time I generate, and (b) keeping an eye
on the semantic correctness of the stuff in the spec.in file header.  
And (b) probably won't involve much -- only the version number and
the changelog typically change on a point release.

Jef, am I answering the question you were trying to ask?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>