Personally I don't like these keywords in bugzilla __at all__ and don't use them. This is mostly because I think they are extremely hidden in the interface.
From my point of view bugzilla should provide a status: 'in review'
alongside 'new', 'unconfirmed', 'resolved' and 'assigned'
This would be useful for cases where a pull request has been sent or a patch attached - so effectively the ticket has almost been resolved pending this last review step.
I find the status filter much more useful and would allow me to easily see what bugs needs review. It also helps me filter the bug list to attempt to solve things that haven't been tackled.
If I review a patch or a pull request and don't think it's suitable then I would propose that we mark it as REOPENED. This at least signals to the provider of the patch that more work needs to be done.
Thoughts?
On Mon, Aug 27, 2012 at 10:59 AM, Marcin Cieslak saper@saper.info wrote:
Hello,
Recently I noticed that keywords in bugzilla get updated more and more often, mostly with keywords like "patch", "patch-need-review", etc.
I am wondering what to do in the following situations (like https://bugzilla.wikimedia.org/show_bug.cgi?id=39635 for example):
- user A posts a patch
- the bug gets "patch", "patch-need-review"
- user B posts a patch that is different and says he does not like patch of A
- user B submits change to gerrit
When "need-review" should be removed? What are replacements if any? What if I believe that core ideas behind the patch are wrong? What if I just think the implementation should be improved? What it it's more or less okay? I see only "patch-reviewed" in the keywords - which can be both negative and positive.
Before I open a whole can of worms by asking a question how do I relate those keywords to the Gerrit workflow we have, maybe the current bugmeisters could explain how they use those keywords and how we can help?
//Saper
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l