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

[Lalatendu Mohanty]

On 04/10/2014 09:46 PM, Niels de Vos wrote:
> 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
The above workflow if fine for bugs which are easy to reproduce. But for 
bugs  which are difficult to reproduce on master branch, it wont be 
effective. Gradually as the projects matures bugs will also become 
complex and bugs from a particular production set-up wont be easily 
reproducible in test environment.  Also intermittent bugs, corner cases 
will be difficult to reproduce. For these kind of bugs we can use below 
work flow.

 1. a user files a bug against the release he/she uses.
 2. Developer find the root cause and fix it.
 3. Check if the code (i.e. code responsible for the bug) present in
    master branch.
     1.

        clone the bug to mainline

     2.

        fix the bug in the mainline

     3.

        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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140410/a6e2df14/attachment-0001.html>