[Gluster-devel] Changing a bug's status related to patches in Gerrit and/or git-tags?
Niels de Vos
ndevos at redhat.com
Thu Apr 10 16:16:05 UTC 2014
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.
>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.
More information about the Gluster-devel