[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc. |
Date: |
Thu, 22 Jul 2004 08:45:58 -0700 (PDT) |
> 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
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., (continued)
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Bruce Stephens, 2004/07/22
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Jan Hudec, 2004/07/22
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Stefan Monnier, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Aaron Bentley, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Aaron Bentley, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.,
Tom Lord <=