Jeff Spaleta <jspaleta(a)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
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
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?