ESR "fedora-submit"

[Jesse Keating]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20061225/2ef6e9a7/attachment-0002.bin