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

[James Blackwell]

>     > 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
>

-t wrote:
> 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.
>
[set up a matrix of developers and features/changesets that developers
can use to mark their (dis)approval, notes, so forth and so on]

At this particular moment I'm doing ex post facto, because I'm clearing
out small stuff with easily understood ramifications. But that's
temporary. Over the longer term (I'll hip-shot at 3-4 weeks from now),
setting up a matrix is a really good idea.

To see how helpful the idea is, I could start with a weekly post to the
list of the form: 

=======================================================================
Feature: Randomly delete revisions from an archive
AddedDate: August 12, 2005
Contact: Dr. George Alzheimer <address@hidden>
Status: On hold
Changesets:
 address@hidden/iforgot--abranch--0--patch-23
 [avoided, but for large feature ideas possibly more changesets]
Approvals:
 George Alzheimer
Disapprovals:
 Robert Collins <address@hidden>
 Aaron Bentley <address@hidden>
DontCare:
 James Blackwell <address@hidden>
 Andrew Suffield <address@hidden>
 
-----------------------------------------------------------------------
Notes:

These changesets randomly delete revisions from an archive in order 
to simulate old age. The changeset goes all over the place, and 
doesn't know how to delete revisions from mirrors yet. 

Individual notes:

James Blackwell: Normally, I'd think this was a really insane idea, but
I'm currently suffering from a conflict of interest (Dr. George is
currently prescribing me unnecessary addictive pain medications).

Andrew Suffield: Andrew actually thinks this sucks, but he told me that
it was ok if I mark him as a don't care for the purposes of this
example. Well, not really, but I'm pretending he did. :)

Robert Collins: He basically asked me if I was on drugs, to which I
answered in the affirmative. He then basically told me that this 
was one of the stupidest ideas that he's ever heard of. (to quote: "if
you take this one, you should get yourself sterilized forthwith")

Tom Lord: He hasn't looked at it as of yet, but he did tell me "Hey! I
want first post on notes!", two which I responded "Well, I would, but
I've already entered a bunch of notes and my up key is broken".


=======================================================================
Feature: ...
...
=======================================================================


> 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 think doing this over the mailing list for the first few weeks would
be a great way to get people involved. Once it became a pain in the butt
to manage by hand (too many opinions or some such), then can try to it 
into tla--devo. 

If that works great, then we stick with that until pqm rolls around. If
it ends up sucking (constant conflicts, etc) in arch, then I'll spend a
few days writing up a simple php where this can be done.

> 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):

I have absolutely no intention of allowing revisions that either fail a 
test or don't compile cleanly with -Wall, are grossly ignoring code
style, etc. Conflicts, I'm willing to handle if they're both occasional
and light.

> 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.

Sure, for normal stuff, but if its something that a lot of people are
going to care about, I think that probably using public discourse is the
right thing to do.

> As for discussing controversial patches: I doubt there will be
> anything we deadlock on but, if so, discussion is fine.  It is a

I think we're probably good too. If there's something that you say
doesn't belong in arch, I'm going to listen to why you think that.

> _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.

If you took tarballs released on releases.gnuarch.org, reviewed them, 
and then decided them fit for signing and placing on ftp.gnu.org, I
would be honored.

> 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
>

I *like* this suggestion. Sure, I love every test case, but I love this
one especially much.

Last night I pulled Robert's integration branch, which includes sha-1
and a bunch of bug fixes, typos, etc. This merge resulted in a huge
changeset that I knew I couldn't commit to devo. So what I've been doing
instead is taking on the changesets one by one (typically a conflated
merge of 5 or 6 of Aaron Bentley's revisions), reviewing them, and
committing. Once that's done, and Robert has time, he's going to walk me
through the sha-1 stuff. Depending upon the results for that, I'll 
seek your expert assessment in one of three ways: explicitly/directly,
explicitly/through the list, or implicitly through a release candidate.

Robert has told me two things that have made me a bit more comfortable:
1. he tells me that sha1 is both forward and backward compatible and 2.
he tells me that there's already 20 people using it.


> 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).

Excellent idea. 


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

We're on the same page, but I'm worried that you may think we're not.
I value forward and backward compatibility very highly as well. Don't
forget; I've got over 150 archives that I'd have to fix!

So yeah, compatibility changes should come at an absolute minimum. Slow
enough that we can ease the user migration naturally, fast enough that
development isn't stalled. 

One of the things that I've been considering is building a consensus that 
new versions of arch must be capable of handling old read-only archives 
indefinitely if at all possible. Read/write capability for old archives
should be kept for at least two years whenever possible.

Going in the other direction isn't quite so bad. How about that once
every couple years or so there's an announcement 6-12 months ahead of
time that archive format changes will be considered for an upcoming
release of arch.

Now, regarding specific features (shorter-path, sha1, furth)

Shorter path is by definition an archive format change. rdparker tells
me his patch supports both long path and shorter-path archives, with
long path archives being the default. He seems to like the idea of
having both directory styles co-exist, I'm partial to migrating 
everyone. I don't doubt for a second that there's unseen ramifications
to both ways of thinking, so this one's headed to an on-list discussion.

Robert Collins tells me that the sha1 work is both forwards and
backwards compatible. Though I haven't looked seriously at the code yet
(I'm still peeling away other revisions from his integration branch),
he's starting to give me the impression that I can evaluate it properly
as it comes to tla. Unfortunately there is one catch; the sha1 stuff is
highly dependent upon a bunch of changes to hackerlab.

Furth probably wont (but may) need archive format changes, so other
archive-format changes may have to wait a bit -- at least until
questions like "does furth need an archive format change" and "how long
until furth" are answered.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400