Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > I have created address@hidden/tla--devo--1.3, and
    > into that branch I have started merging changesets from a
    > variety of sources. Then, on or about 31 July, I intend to
    > release arch-1.2.1rc1.tar.gz and, as needed, release successive
    > release candidates (though not many). If, after a week it looks
    > like the rc is right, then I'll inform Tom that there is an
    > imminent release of arch. I'll then sit back for about a week to
    > give Tom the ability to review the rc at his leisure. If he
    > wishes, he can bless the release candidate in its entirety, and
    > its given to the world. However, if there's something in the rc
    > he doesn't like, he has the priviledge of vetoing any changeset
    > that I've approved. If this he chooses to veto a changeset, I
    > might either agree or disagree. If I agree, the changeset is
    > gone. If I disagree, we (as in the community) will discuss the
    > merits of the changeset, with a strong propensity towards
    > dropping the it.


This is kind of a simulation of the voting rules the pqm will have 
but for the degenerate case of only two co-maintainers, one of whom
is chief architect.

If some usual suspects want to help you with the rc series, you might
try doing a more complete simulation.   You could skip the hassle of
voting _before_ merges and do it ex post facto (on the assumption that
you won't get many or any wrong (i.e., need to be reverted)).  You
could do this on the list with messages like:


     * rc patch list

        patch:                  approvals:        notes:

        patch-1                 jblack lord
          fix doc typo
        patch-2                 jblack rbcollins
          fix revlib permissions check
        patch-3                 jblack            TODO
          ...
        patch-4                 jblack lord
          ...
        patch-5                 jblack            FLAG
          Change CLI to get/update/etc.
        patch-6                 jblack            TODO
          ...


which will be a kind of "rc scorecode" so people can see _what's_
going in and also get a sense of how the review process is doing.

In fact, if you store that scorecard as a file in the tree, people can
just send you patches to add approvals, changes notes, etc.

I don't know if it'd be worth it at this stage but you could simulate
some automated testing, too, by (every now and again) creating
a revision just to note test results (no approvals needed):


        patch-K                  *reg-tests*       PASS
          regression tests pass
        patch-L                  *reg-tests*       PASS
          regression tests pass
        patch-M                  *up-tests*        PASS
          upward-compatability tests pass
        patch-N                  *up-tests*        FAIL
          downward-compatability tests fail


At any rate the idea here is to implement:

   a) maintainer-pair programming, not everything-filtered-through-tom

   b) easy for any co-maintainer to say "FLAG" -- i.e., Tom should
      probably take a look at this


The voting system in the pqm, unlike the simulation described above, 
also will let me "cheat" and bypass voting but hopefully that won't 
be needed often and there's obviously no sense to it for your rc 
series.

As for discussing controversial patches: I doubt there will be
anything we deadlock on but, if so, discussion is fine.  It is a
_slightly_ asymmetric situation just because I have the keys to the
GNU ftp distribution sites: I have to "sign off" on what the GNU
project puts out.  I don't know that that has any necessary practical
implications but did think I should point out the perspective I have
to keep in mind in any such discussion.

One thing we _might_ deadlock over, depending on your intentions wrt
it, are archive-format munging changes like the sha checksumming
stuff.  I hinted at two tests up there:

        patch-M                  *up-tests*        PASS
          upward-compatability tests pass
        patch-N                  *up-tests*        FAIL
          downward-compatability tests fail

You have the super-mirror on hand.  It should be easy to verify that
the rcs can read a subset of historic archives.  It would be nice to
have monitoring, too, of how older releases do reading newer archives
(which sometimes is broken deliberately but shouldn't casually be
broken accidentally or in misunderstood ways).

Keep in mind when considering such changes that, what with short-path
stuff coming up, perhaps all those format changes should be lumped
together.

-t