On Thu, Oct 12, 2017 at 6:09 PM, Shyam Ranganathan <srangana@xxxxxxxxxx> wrote:
> On 10/12/2017 12:58 AM, Nithya Balachandran wrote:
>>
>> > - When to mark the blocker bug as dependent on another bug:
>> >
>> > Blockers are meant to track *just* blockers for a major or minor
>> release,
>> > not all bugs that are a part of the release. Hence when a bug is
>> actually a
>> > blocker for the release, only then should the tracker be made
>> dependent on
>> > that.
>>
>> I have used it a little differently. On the day of release, I add all
>> the bugs that are fixed in a release in "depends on" list of the
>> blocker bug. Essentially, I used it as a tracker bug than a blocker
>> bug.
>>
>> Wouldn't it be easier that every bug that one wants to get fixed in
>> next minor release is added to the tracker bug and is removed and
>> moved to next release if it did not make it? It would be less work for
>> maintainer.
>>
>> +1 . We could use the blocker flag to tag actual blockers.
>>
>
> So here are 2 things a contributor needs to do if all bugs are marked
> against the blocker.
>
> a) Backport it, no way to avoid this and the additional work of
> filing/cloning a bug against the release for which the backport is aimed at.
>
> b) Add it to the tracker
>
> (b) is not essential, it is additional work for the contributor. Further the
> bug may or may not make it to the release (as reflected above), and adds
> work for the release maintainer to cleanup the tracker and add those that
> are missed to the next release tracker.
>
> For a release maintainer (or anyone with a cloned repository), the ability
> to find bugs that are fixed in a release is relatively simple. It is as easy
> as executing this (for example),
> git log --format=email v3.12.1..v3.12.2 | grep -i ^bug: | awk ‘{print $2}’ |
> sort -u
>
> For users this list is presented in the release notes, which is part of the
> documentation, release announcement, and in github as well. Further, post a
> release bugs that were fixed as a part of the release are closed with a
> comment in bugzilla stating which release it made it to, and also the
> release announcement mail.
>
> The above user perspective is added, as there maybe a justification that a
> user could look at the tracker and figure out is a bug is fixed in the said
> release, but this again is not required, if the bug of interest is known
> then looking at that bug in bugzilla provides the information, if the query
> is more along what all are fixed, the release notes inform regarding the
> same.
>
> As a result, marking all bugs against the tracker, is more work for a
> contributor as well as the release maintainer. So why would we want to do
> this?
Yes, this is mainly a matter of preference. I don't have any objection
to using it as a blocker bug and adding only blockers to it.
Thanks,
Raghavendra Talur
>
> Shyam
>
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
