Jeff Spaleta <jspaleta@xxxxxxxxx>: > 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> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
