httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <...@squid-cache.org>
Subject Re: Add 2.2.4 to bugzilla
Date Sat, 13 Jan 2007 01:53:43 GMT
lör 2007-01-13 klockan 01:06 +0100 skrev Ruediger Pluem:

> This could be modified to:
> 
> 1. Fix on trunk => Change state in "Resolved, fixed" and add a comment with revision
>    of fix.
> 2. Proposed for backport => Leave state in "Resolved, fixed" and add a comment with
>    revision of backport proposal (STATUS file)
> 3. Backported => Change state to "Closed" and add a comment with revision of
>    backport.

Another alternative is ignoring Bugzilla for backport status, only using
the STATUS file with references to Bugzilla entries needing to get
backported to the release.

I.e. something like

1. Fix on trunk -> Resolved, Fixed. Reference to revision in bugzilla
(preferably automatic)

2. Audited by a release maintainer for the main release to judge if
backport needed, added to STATUS file if backport needed. -> Closed.

3. Backported -> cleared in STATUS file. Reference to revision in
Bugzilla (preferably automatic).


Another alternative which is more in line with normal release management
is using the target milestone feature builtin to Bugzilla.

1. Fix on trunk -> Resolved, Fixed. Reference to revision in bugzilla
(preferably automatic). No target milestone assigned yet.

2. Audited by release maintainer for the main release. If backport
needed added to STATUS and -> New with target milestone of the release.
Else closed.

3. Backported. -> Resolved, Fixed.

4. Audited by next older release maintainer if any, as in 2. Repeat
until all maintained releases has been covered.

the beauty of the above is that it's easy to query Bugzilla for the list
of bugs in various states, and that it pans out quite well when you keep
maintaining older releases. Same process all the way.


> >From my personal point of view I think it is important to add the revision number
> of the fix / backport to the comment because:
> 
> 1. People who are interested / have the know how can easily cross check what has been
>    changed.
> 2. People who only want a specific fix either because there is no newer stable version,
>    or because they cannot do an upgrade to a later stable version for whatever reason
>    can easily find the needed patch.

Note: If you properly reference bugzilla entries in the changelog
messages when committing changes then there is automated tools which can
both resolve bugzilla entries and add references.. Could save you some
headache but requires a bit of setup..

Regards
Henrik

Mime
View raw message