Re: [Gnu-arch-users] Imminent 1.2.2 Release

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Tom" == Tom Lord <address@hidden> writes:

    >     Tom> It is not your job to bundle up the release.
    >     Tom> It is not your job to declare that the release is ready.

    > What's the problem with jblack bundling up the release and you
    > declaring that it's ready (when it _is_ ready)?

There are several of which I will name a few off the top of my head.

The overarching matter is that I sign off on these releases.  Yes,
they are GPL and that includes a disclaimer of warranty.
Nevertheless, that would be no excuse for gross negligence on my part
and, regardless of legal considerations, there are the matters of
professionalism, professional pride, and simply my "value add" as the
project maintainer.   

On a more positive note, the exercise of acquiring and then
reconstructing within the "official" arch-recorded development line
the release is a good, multi-faceted checksum on the effort.  (The
cheap pat answer here would have been merely to point out that
releasing jblack's tar bundle would deprive the release history of a
consistent arch-recorded history.  I'm giving you the more nuanced
answer, though.)

I am not a rubber stamp.  I am the project maintainer.  I have been
making extensive efforts to expand: the "credit" for work on GNU arch;
the number of people who can work on GNU arch releases without needing
handholding from me, etc.  But no matter how much I can extend that: I
am not a rubber stamp and will never agree to become one.



    > Isn't it a good idea for the same person who does the rc's to just
    > keep putting them out until you say "This is the one!" and then he
    > shaves off the "rcN" from the version number in version.c, packs it
    > up, you countersign it, and it ships?

No.  If our source management practices were so fragile that that were
a good idea, then that would, in and of itself, be a problem.


    > Isn't it a bad idea for you to be making changes from the last rc of
    > any other kind, and shipping without (beta) testing?  As you've
    > pointed out, you're not some cub reporter with a 2am deadline to make
    > the morning edition!

I've also stated that I intend to make no source-level changes outside
of "the process" (such as it is) for this release.  Last release we
informally agreed on IRC that I should and, sure enough, got a good
example of why not to do that.

However, shuffling things around between archives and recreating a
distro, perhaps with cosmetic changes?  If we can't do those things
routinely then we are in the wrong business.  (Alas, it seems now that
we will not have the chance to in this particular case.  Although I am
sympathetic to those who have encouraged James not to make this an
"all or nothing" event -- my patience for this soap opera is exhausted
and I'd rather hit the process reset switch than dick around with this
nonsense anymore.  My perception is also that this has been unfairly
wearing on James and, assuming that is so, I think cutting this off
cleanly, quickly, and with finality is best for everyone.)


    > BTW, this is basically the way we do it (as you've probably guessed),
    > so these are honest questions, not criticisms.  If you say, "yes, but
    > what about ..."  it will undoubtedly improve our process.  :-)

I believe in the importance of being able to sling around source with
confidence and accuracy and, so far, arch has lived up handsomely to
that in self-applied practice.   If your process is so fragile that a
particular tar bundle is precious (in the sense you can't recreate it,
perhaps changing such things as its revctl coordinates) --- then your
process is pretty damn weak.   If you can't redundantly create
equivalent releases N different ways, then how do you have any
confidence at all in the 1 way you *did* make the release?

Tar bundles are cheap.  Life isn't.
-t