[Top][All Lists]

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

Re: [Gnu-arch-users] Re: gnuarch 1.2.1 released! (reannouncement)

From: Andrew Suffield
Subject: Re: [Gnu-arch-users] Re: gnuarch 1.2.1 released! (reannouncement)
Date: Wed, 18 Aug 2004 01:16:38 +0100
User-agent: Mutt/1.5.6+20040803i

On Tue, Aug 17, 2004 at 12:34:13PM -0400, James Blackwell wrote:
> >     > If you are doing changes to furth, xl-whatever, etc, then tag off of 
> > -t
> >     > and send patches that way.
> >
> > There should not be any sending of patches in particular directions!
> >
> > *ALL* patches should go through BugGoo.  You, jblack, should be
> > working off of buggoo.
> I'm not using it directly, though I did hit some of the merge requests
> for the last cycle.
> Regarding closing bugs, I'm utterly clueless. ;) 

'closed' is approximately 'fixed on trunk', and is a sort of vague
overview of the current status of the bug ("We're done working on that
one"). Far more importantly, make sure that Fixed-by tags are added to
all bugs you fix with a suitable revision - that's the really
important part. unassigned/assigned/closed describes the *process*,
while Fixed-by describes the bug. You can catch up on bugs that have
been missed in the past by sending mail to address@hidden
with lines of the form
"fixed 123 address@hidden/tla--devo--1.3--patch-27".

The preferred interface, however, does not involve you understanding

When you write a patch log, include headers like 'Bug: 123' and
'Merge: 456' to describe bugs which are fixed and merges that have
been applied.

After committing, mail the whole damn patch log to the list with a
subject line like:

[COMMIT: address@hidden/tla--devo--1.3--patch-27] pika-escaping interface 
change catch-up

(That's "[COMMIT: $revision] $summary")

It'll sort the rest out based on who you are and what the current
state of the bug is, following project policy. The above is
appropriate for *everybody*, without restriction, including people who
have no association with the project but happen to have fixed a bug on
their own private branch.

[A few examples of current project policy: for you, personally, it'll
assign the bug to you, as you're now responsible for getting it into
the trunk. For Tom, it just kicks the bug into closed/. For unrelated
users, it doesn't change the bug status - but in all cases, it adds a
Fixed-by field].

  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' : |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature

reply via email to

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