[Gluster-devel] Changing a bug's status related to patches in Gerrit and/or git-tags?

[Niels de Vos]

On Thu, Apr 10, 2014 at 11:43:46AM -0400, Kaleb KEITHLEY wrote:
> On 04/10/2014 11:25 AM, Lalatendu Mohanty wrote:
> 
> >>
> >>QUESTION for #2:
> >>- Shall we change the "Bug report life cycle" and advise to file
> >>   separate bugs per release? This makes it easier to track changes in
> >>   master (should go to MODIFIED), and copy/clone bugs for releases that
> >>   users are interested in (well, or copy the other way around, that does
> >>   not really matter).
> >
> >IMO it is not right to ask the user to file separate bugs per release,
> >because most of the time users just use one version of glusterfs and
> >there is high probability that they don't know if the bug exists in
> >other releases. But when developer fix the bug, he/she can track if the
> >code (which is causing the issue) is present in other releases as well.
> >So developer should clone the bug for other releases and use the release
> >specific bugs for the patch.
> 
> +1

>From my point of view, this would be a very common workflow:

1. a user files a bug against the release he/she uses
2. someone verifies if that bug is still happening in the master branch
3. if the bug also affects the master branch:
  a. clone the bug to mainline
  b. fix the bug in the mainline
  c. wait until it has been merged
4. cherry-pick the fix from mainline to the version of the user
5. post the patch to the release-$VERSION branch in Gerrit
6. user waits for QA/beta packages and verifies
7. a release is made, bug gets closed

Depending on time-lines, it is possible that a release branched from 
master has the fix included before the version of the used gets and 
update. This should not be a problem, the user will get an update by 
email when the copied/cloned/blocked bug changes status (to CLOSED).

Is there anything I'm missing? Other improvements or further 
clarifications needed? Just let me know.

Thanks,
Niels