Re: [Gnu-arch-users] address@hidden: Re: bitkeeper comments]

[Tom Lord]

    > From: Zack Brown <address@hidden>

    > Looked interesting. What's the tla take on retroactively
    > modifying the changelog?

(I assume you mean "patch log".)

It's an ill-conceived idea as stated -- as Linus himself notes, it
doesn't interact will with distribution.

Linus mentioned two problems he wanted to solve:

(a) editting log messages for incoming patches as they are applied

(b) back-annotating old log messages, for example to declare that
    a patch did not, in fact, fix a bug that the log message claims
    it does


I think that (a) is less of an issue in arch.  When merging in
incoming patches, you write a log message for the merge itself.
Corrections can be made in that merge log.

(b) is interesting, but there isn't enough context here to decide what
the right approach is in arch.   Certainly, such back-annotations are 
potentially useful.   They would not be done in arch by changing old
log messages, but by adding new data.

The question is where and how that new data is added and stored.   And
that question can't be answered without a clearer answer about how it
will be used.

There's lots of ways that a hypothetical Linus might want to organize
the infrastructure if we were going to use arch.   We'd want to have
the whole conversation about that infrastructure to understand how
back-annotations fit it -- I just can't answer in isolation.

One reads announcements these days about work on browsers and GUI
interfaces and hear's dark and troubling rumours ( :-) about design
thinking towards a really nice patch queue manager.  One reads
announcements about this or that project either adopting arch or being
supplemented by an arch mirror of its CVS repository.  Absent a sudden
and suddenly funded rush by Linus to flee from bitkeeper to arch, I
think that the question of back-annotation will be best answered when
it comes up more organically in one of those areas of arch activity --
in which context the best answer(s) will probably be pretty obvious.

-t


p.s.: my first thought in replying was just to sketch the idea that a
patch log might contain, in addition to the log for some patch-N,
additional files such as annotation/patch-N.linus-20030910.1.   That's
operationally a very easy and clear approach.

But really, then how is that added data used?   Should it be factored
out for rapid access in an archive?   What if I want to annotate a log
entry for a patch from an archive I don't write to?   If annotations
do wind up back in archives -- how does that interact with mirroring?
Should it appear in `log-ls' output?  `changelog' output?  `revisions'
output?   What are its implications for server smarts and for server
round-trips to remote archives?

There's just not enough context to the question to give a definitive
answer.