On 12/24/06, Eric S. Raymond <esr@xxxxxxxxxxx> wrote:
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?
the look-aside cache is the magical place where cvs can hold binaries, like an upstream tarball. make new-sources is the makefile target which does the necessary magic which I don't care enough about to understand completely. As Micheal pointed out, the process to update an srpm in fedora extras is pretty simple now and is controlled via Makefile.common available in the cvs trees. While you can use the available cvs-import.sh script for all the srpm's uploaded into cvs, I personally don't like do it, because I've gotten into trouble with incorrect cvs tagging across release branches when I've used cvs-import incorrectly.
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.
Things have changed, 2003 was a long time ago for project policy and infrastructure. We are in the 2nd age of fedora contributor infrastructure now, with a reasonably scriptable cvs server and build automation. In fact we will soon see the birth of a 3rd age of infrastructure when Core and Extras merge into a common buildsystem.
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.
Shrug, just as long as you realize that nothing I'm saying now should be interpreted as endorsement of any idea you may have now, may have had in the past, or might have in the future. And you should know that I reserve the right to verbally rip out your spleen through your left ear if I find that you have decided to quote anything I say out of context and without direct citation back to this mailinglist archive.
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.
What rpmlint does is not fully equivalent to what people do when they read over specfiles. One concern is that the specfiles state somewhat human-readable, and depending on how one automates the creation of their specfiles, this could leave some decidedly un-intuitive artifacts which hamper a human's ability to read the specfile without causing an rpmlint warning or error.
Jef, am I answering the question you were trying to ask?
Not really, the only thing that's going to answer all questions is to shove one of your packages through the review process and see if your scripts can deal with an ever-evolving Fedora Packaging Guideline policy and if reviewers can deal with any automation artifacts that are a result of your scripts. It would help however if you got re-acquainted with the fedora contributor policy state-of-the-art. http://fedoraproject.org/wiki/Extras/Contributors -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
