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 _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel