From esr at thyrsus.com Sun Dec 24 20:52:24 2006 Content-Type: multipart/mixed; boundary="===============0117668174141338080==" MIME-Version: 1.0 From: Eric S. Raymond To: devel at lists.fedoraproject.org Subject: Re: ESR "fedora-submit" Date: Sun, 24 Dec 2006 20:52:11 -0500 Message-ID: <20061225015211.GE19176@thyrsus.com> In-Reply-To: 604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com --===============0117668174141338080== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Jeff Spaleta : > 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? -- = Eric S. Raymond --===============0117668174141338080==--