<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/10/2014 09:46 PM, Niels de Vos
wrote:<br>
</div>
<blockquote
cite="mid:20140410161605.GI5385@ndevos-laptop.usersys.redhat.com"
type="cite">
<pre wrap="">On Thu, Apr 10, 2014 at 11:43:46AM -0400, Kaleb KEITHLEY wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 04/10/2014 11:25 AM, Lalatendu Mohanty wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
+1
</pre>
</blockquote>
<pre wrap="">
>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</pre>
</blockquote>
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.<br>
<ol>
<li>a user files a bug against the release he/she uses.</li>
<li>Developer find the root cause and fix it.</li>
<li>Check if the code (i.e. code responsible for the bug) present
in master branch. <br>
</li>
<ol>
<li>
<pre wrap="">clone the bug to mainline</pre>
</li>
<li>
<pre wrap="">fix the bug in the mainline</pre>
</li>
<li>
<pre wrap="">wait until it has been merged</pre>
</li>
</ol>
</ol>
<blockquote
cite="mid:20140410161605.GI5385@ndevos-laptop.usersys.redhat.com"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<br>
</body>
</html>