On Sunday 24 December 2006 18:57, Eric S. Raymond wrote: > Can I write a procedure in shell or Python, to be invoked by > 'make ship' from my project's top-level makefile, that will automate > my release process so I *don't have to think about it*? > > I *don't* *fucking* *care* what happens on the back end. If one > of the possible consequences is email bounceback that says "your > point release failed QA because *BLAH*, that's OK. I'll fix the > problem and try again. One big thing you need to think about is that within the Fedora package infrastructure, spec files are managed outside of tarballs. One side effect to this is that the specfile can change between tarball releases, be it for an automated rebuild (many reasons), update for new package guidelines, change in a BuildRequires stack, etc... These changes can happen in the package SCM which is outside of the source SCM by nature. Therefor, you can't always blindly shove what comes from upstream into our package infrastructure without making sure that nothing has changed downstream first. Doing this has led to re-introduction of bugs in packaging, inconsistent package changelogs, etc... There really is a difference between downstream and upstream. Fedora is a downstream of many upstream projects. Many times the upstream maintainer/author is the same as the downstream, but there are different needs/procedures that need to be kept in mind. However, quite often the downstream maintainer is _not_ the upstream, for many reasons. Sometimes its a time issue, upstream doesn't want to deal with downstream issues (yes, there are more issues than just 'get my latest release into downstream, local rebuilds, SCM changes, guideline updates, release freezes, etc...), othertimes it is to prevent a conflict of interst. Downstream interests are at times different than upstreams. Release timelines, features, freezes, but priorities, all of these things could lead to conflicts if the same person runs upstream as downstream. So, while a tool to automatically do an upstream _and_ downstream release might be nice/interesting, it by nature cannot handle many of the things I've outlined above. Instead what can be done, if you're upstream process produces an srpm that is suitable for the Fedora infrastructure, you can make use of the cvs-import.sh script which can import an srpm onto a given "branch". This automates the update of the source tarball and spec file changes. If (this is a BIG IF) you _KNOW_ that no changes have been made that your upstream spec doesn't take into consideration, it can be used to import the new release. 'make tag build' still needs to be ran, and frankly that could be scriptable as part of the script that handles cvs-import.sh, but as I said there are many issues that a human has to take into consideration when doing a downstream release. Especially on released branches, where we're moving to doing specific updates with email notifications which will require even more human thought/consideration. You can't just bump a package that will break a ton of deps, that's irresponsible as a downstream maintainer. Not something that an upstream maintainer will really care about, but most certainly something a downstream should. I think the bottom line here (sorry for the long email) is that for YOU Eric, it may not be in your best interst to be both the upstream and the downstream maintainer of your software. It may be better for you to find an intersted party to be your downstream within Fedora who will keep all the above issues (and more!) in mind while doing releases of your software for us. This allows you to continue doing the upstream thing as you need, and we the downstream will consume it when it is appropriate and in a way that is appropriate. -- Jesse Keating Release Engineer: Fedora
Attachment:
pgpF00ut2Qb2C.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
