Re: [Gnu-arch-users] Some issues

[Andrew Suffield]

On Tue, Jun 15, 2004 at 12:58:47PM -0700, Tom Lord wrote:
> That still leaves the mainline log messages coming in at 1200/month.
> We can't say what to do with or about those without having a clear
> idea of what they are for and your problem statement is underspecified
> in that way.
> 
> We know we want them for integration testing.    For example, those
> 1200 log messages document the atomic changes that define for us
> the granularity of things like binary-hunt regression finding.

Actually, I'm not sure that you do. Consider: you need the original
atomic changesets anyway, because you're going to want to build trees
with only some of them applied. These changesets contain the patch
logs, as to the archives which they are stored in.

I don't think you actually need the copy in the mainline tree at
all. In fact, you don't *need* the mainline tree itself, although you
can use it as a convinient summary delta system to aid performance
(from the perspective where you already have an immutable merge
sequence decided, because the merges have already happened, it has no
other function). All you need to know is the names of the revisions
that were applied in each batch-merge, and the sequence in which they
were merged to mainline. You can compute that fairly easily without
having all the patch logs stored in any mainline revisions.

(And you can automate the whole process, so the automatic regression
test suite emits comments like "Test case N has regressed on mainline,
as of changeset foo. This regression first appeared in changeset bar;
here is the diff that caused it."; that should allow a lot of bugs to
be fixed by sheer offhand inspection, with minimal developer effort).

I think that having all those log messages stashed in a revision would
do nothing but slow the whole process down, simply because you'd spend
longer patching up the test trees (even an N-ary search running on a
tinderbox arrangement is going to take a little while to build and run
the lot).

> We can presume that we want these 1200 log messages as a kind of
> "newspaper".  Nobody is likely to read all of them in depth but many
> people are likely to skim the list, pick out a few of personal
> interest, and study those.

I'm not sure you really want a revision for that either. You probably
want a mailing list and a cgi script.


My suspicion is that even if it gets implemented, the "branch with all
the patch logs" will ultimately not be used (although it might
initially, before tools catch up). So I'd be inclined to leave it
until there's a concrete need that can't be solved in some other way.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature