gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: FEATURE PLANS: pruning instead of configs


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: FEATURE PLANS: pruning instead of configs
Date: Wed, 26 May 2004 17:24:59 -0700 (PDT)

    > From: Stefan Monnier <address@hidden>

    > >         I do like the idea. Sending patches by email is a common task,
    > >         and it would even be superb if tla could pass proper message IDs
    > >         along so that *-patch-nnn would result in a proper thread:)

    > While I think that tla should be divided into a "core" and a "UI", I'm not
    > going to comment on that side of the question.

I think that what is likely to happen is that there will be some
ancillary projects (e.g., as bug goo matures) which stretch our 
notion of what "arch core" is.   It'll always be important to keep the
current core independently useful, but I think there will be some 
creeping in of features like --announce.

    > But regarding the `tla commit --announce' thingy, I think an important 
part
    > of sending a patch to a maintainer is not just the patch and its 
changelog,
    > but also a motivating explanation, so I'd like to see the

    >     The user should have the opportunity to edit the body
    >     of this email (perhaps via editting the log message)

    > expended a bit to provide more flexible ways to edit the text and to
    > recognize that a log message is different from a "motivating explanation".

Why can't that motivating explanation go in the patch log?

Looking at by-hand-maintained ChangeLogs of various projects (and even
at the arch patch log, often) I often find the log entries so anemic
as to be useless.   I'd appreciate an arch feature that encourages 
more expository messages.

This gets back, a bit, to the "empty commit" question.   It'll make
sense, for example, to hack on a branch for a while, get it ready, and
then do an empty commit just to commit with "--announce" and write a 
decent log message.   (The other side of the coin is that when you 
merge that branch, the "--announce" log message(s) should be mangled
to form the draft of the log message for the merge.)

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]