Bug Triage: update to reflect the latest changes#421
Conversation
nixpanic
left a comment
nixpanic
left a comment
There was a problem hiding this comment.
Looks good overall. Maybe explain a little more, but that is up to you (and others to comment on).
We should not use 'released versions' when talking about backporting fixes. 'Maintained versions' is better, and maybe even link to https://www.gluster.org/community/release-schedule/ for those.
| 'mainline', as by default, as a policy, we need to submit the fix | ||
| for 'master' branch before backporting fix to specific branch. | ||
| Only when a bug needs to be fixed in multiple 'released' versions, | ||
| then there is a clone requried. |
There was a problem hiding this comment.
This is not particularly clear to me. We have users reporting minor bugs against an old, but still maintained version (say 3.12). Does this mean the bug needs to get fixed in 'mainline', and 3.12 only? The reporter may not care about a fix for 4.1. I guess it would need a clone for 4.1 too as we require fixes to be backported to all newer maintained releases too. However we now have the clone for 4.1 that depends on the original 3.12 bug that has the mainline fix. This looks confusing to me.
I don't think we can say 'send a patch for mainline against a bug reported against the most recent maintained version', as some patches linger around waiting for reviews while a new version gets branched.
In the end, I think it makes it easier to miss backports to maintained/branched releases. The release scripts that verified backports, parents, related BZs and their status is non-functional for a while already (not even sure where it is burried now). So, maybe our use of mixing Bugzilla+GitHub for tracking allows us to be less strict on the Bugzilla workflow too.
Also, replace 'released' versions with maintained versions.
| - A bug is raised for GlusterFS 3.12 and the same issue is present in | ||
| mainline (master branch) and GlusterFS 4.1. | ||
| - See if the bug is of severity 'Urgent'/'High', and only if yes, | ||
| clone it for 4.1 |
There was a problem hiding this comment.
These examples make a little more clear what was described above. Please add an explanation which bug should be in the 'blocks' and which bug should be in the 'depends on' fields.
|
@amarts Can you please revisit this PR ? |
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Oops, missed from my radar! On it now! |
|
All the points updated. Would like to get it merged 👍 |
|
@humblec is this something you'd merge? |
4 participants
Signed-off-by: Amar Tumballi amarts@redhat.com