ESR "fedora-submit"
Eric S. Raymond
esr at thyrsus.com
Mon Dec 25 01:52:11 UTC 2006
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>
More information about the fedora-devel-list
mailing list