Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
From the Amsterdam Hackathon I know that some developers would like to
filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch && lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it).
Hence I propose * to remove the manually set and error-prone Bugzilla keyword "patch-in-gerrit": Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time.
I've been using ASSIGNED and assignee name to mean this... to me if someone is assigned to something it is a promise to attempt to fix it. I'm not sure how patch to review would be useful... Gerrit should be the place to look for things to review - not bugzilla.
A RELEASED would however would be useful.
On Wed, Jun 5, 2013 at 3:15 PM, Andre Klapper aklapper@wikimedia.org wrote:
Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
From the Amsterdam Hackathon I know that some developers would like to filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch && lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it).
Hence I propose * to remove the manually set and error-prone Bugzilla keyword "patch-in-gerrit": Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, 2013-06-05 at 15:29 -0700, Jon Robson wrote:
I've been using ASSIGNED and assignee name to mean this... to me if someone is assigned to something it is a promise to attempt to fix it.
Ideally I'd use ASSIGNED when seriously(TM) planning to work on a patch. I mean, seriously. But I know that there are small differences in interpretation out there, and whatever works for a developer or a development team also works for me.
I'm not sure how patch to review would be useful... Gerrit should be the place to look for things to review - not bugzilla.
I agree. This is more to minimize the small status mismatch we have to due to manual activity in Bugzilla (bug reports still open though patches have been merged which are supposed to fix the reports).
A RELEASED would however would be useful.
That's one of the next topics, see my PS at the bottom. :)
andre
On Wed, Jun 5, 2013 at 3:15 PM, Andre Klapper aklapper@wikimedia.org wrote:
Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
From the Amsterdam Hackathon I know that some developers would like to filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch && lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it).
Hence I propose * to remove the manually set and error-prone Bugzilla keyword "patch-in-gerrit": Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yesplz. The sooner we do this, the better.
I've sometimes ASSIGNED bugs to myself to indicate that there's a patch, too, but assigning means different things for different people (e.g. the VE team assigns pretty much all bugs to someone and this means something to them internally I couldn't quite grasp ;) ).
On Wed, 05 Jun 2013 15:15:47 -0700, Andre Klapper aklapper@wikimedia.org wrote:
Hi everybody,
* to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.Comments?
What is the workflow when: # Someone mentions the bug in a commit. # "Gerrit Notification Bot" changes the report status to PATHCH_TO_REVIEW # The patch is only related or only a partial fix and hence doesn't actually fix the bug.
Do we have to set the bug to REOPENED instead of the NEW or UNCONFIRMED that it was previously set to.
andre
How does a Status change work better than a Keyword change in this case?
On Thu, 2013-06-06 at 10:47 +1000, K. Peachey wrote:
How does a Status change work better than a Keyword change in this case?
It does not (assuming that the hooks-bugzilla plugin can do both status and keyword changes), I'm just combining two aspects in one go. :)
A keyword (that I consider ideally a static attribute that should apply for the entire lifetime of a bug) just feels wrong for the usecase "this bug has a patch committed".
andre
Hi,
On Thu, Jun 06, 2013 at 04:39:41PM +0200, Andre Klapper wrote:
assuming that the hooks-bugzilla plugin can do both status and keyword changes
That assumption does not hold true: hooks-bugzilla can set the status, but it currently cannot set keywords, as j2bugzilla (underlying java<->bugzilla connector) does not support it.
However, adding that functionality is totally doable, if we settle for staying with keywords. (Which I hope we do not)
Best regards, Christian
-- ---- quelltextlich e.U. ---- \ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------
On 6 June 2013 16:58, Christian Aistleitner christian@quelltextlich.atwrote:
However, adding that functionality is totally doable, if we settle for staying with keywords. (Which I hope we do not)
I agree; keywords are meant to be time-invariant, not statuses; they're the wrong conceptual item to apply for temporary things like "patch in gerrit".
J.
On 06/05/2013 08:18 PM, Daniel Friesen wrote:
On Wed, 05 Jun 2013 15:15:47 -0700, Andre Klapper aklapper@wikimedia.org wrote:
Hi everybody,
* to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.Comments?
What is the workflow when: # Someone mentions the bug in a commit. # "Gerrit Notification Bot" changes the report status to PATHCH_TO_REVIEW # The patch is only related or only a partial fix and hence doesn't actually fix the bug.
Yes, we need a separate "Fixes-Bug: 123" annotation. When you use Fixes-Bug, you're saying "When this is merged, it's fixed", rather than "This is one step, or just somewhat related".
Matt Flaschen
On Wed, 2013-06-05 at 21:54 -0400, Matthew Flaschen wrote:
On 06/05/2013 08:18 PM, Daniel Friesen wrote:
What is the workflow when: # Someone mentions the bug in a commit. # "Gerrit Notification Bot" changes the report status to PATHCH_TO_REVIEW # The patch is only related or only a partial fix and hence doesn't actually fix the bug.
Yes, we need a separate "Fixes-Bug: 123" annotation. When you use Fixes-Bug, you're saying "When this is merged, it's fixed", rather than "This is one step, or just somewhat related".
Thanks a lot for pointing this out (this was also brought up when I discussed the idea with some folks at Amsterdam Hackathon, but I forgot to include it in my initial email).
andre
On 6/5/13, Andre Klapper aklapper@wikimedia.org wrote:
Hi everybody,
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
From the Amsterdam Hackathon I know that some developers would like to filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch && lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it).
Hence I propose * to remove the manually set and error-prone Bugzilla keyword "patch-in-gerrit": Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the "Gerrit Notification Bot" automatically change the bug report status to "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit.
Comments?
andre
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322
PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between "RESOLVED FIXED" (fix merged) and "RELEASED" (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Please Please Please :)
I've always wanted that to be a status, since it is a distinct stage in a bugs life cycle (distinct from assigned imo, although others disagree. In my opinion assigned means currently working on, and patch in gerrit means already worked on and awaiting review by somebody else)
--bawolff
Le 06/06/13 00:15, Andre Klapper a écrit :
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
<snip>
Hello,
Lamely copy pasting my reply to the December thread http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065047.html :
-------8<-------8<-------8<-------8<-------8<-------8<------- Launchpad.net has instead of RESOLVED and VERIFIED:
Fix Committed (fixed but not available until next release) Fix Released (fix released). -------8<-------8<-------8<-------8<-------8<-------8<-------
Which is essentially the same as PATCH_AVAILABLE and RELEASED.
I never use the keywoard myself (I suck I crafting my own bugzilla searches). So I will more than welcome the status change. Make sure we can move straight from NEW to RELEASED.
cheers,
Antoine Musso hashar+wmf@free.fr wrote:
in December I mentioned the idea of having a "PATCH_AVAILABLE" or "PATCH_TO_REVIEW" status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3].
<snip>
Lamely copy pasting my reply to the December thread http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065047.html :
-------8<-------8<-------8<-------8<-------8<-------8<------- Launchpad.net has instead of RESOLVED and VERIFIED:
Fix Committed (fixed but not available until next release) Fix Released (fix released). -------8<-------8<-------8<-------8<-------8<-------8<-------
Which is essentially the same as PATCH_AVAILABLE and RELEASED.
[...]
Not quite: "Fix Committed" means the patch has been merged.
Tim
Salut,
On Thu, 2013-06-06 at 11:25 +0200, Antoine Musso wrote:
Launchpad.net has instead of RESOLVED and VERIFIED:
Fix Committed (fixed but not available until next release) Fix Released (fix released). -------8<-------8<-------8<-------8<-------8<-------8<------- Which is essentially the same as PATCH_AVAILABLE and RELEASED.
Yepp, and I like that. :) However, Bugzilla does not allow renaming "RESOLVED FIXED" (fix merged but not deployed), and I'm a bit concerned that changing the name would break a lot of Bugzilla query URLs out there.
andre
On 6 June 2013 15:40, Andre Klapper aklapper@wikimedia.org wrote:
Salut,
On Thu, 2013-06-06 at 11:25 +0200, Antoine Musso wrote:
Launchpad.net has instead of RESOLVED and VERIFIED:
Fix Committed (fixed but not available until next release) Fix Released (fix released). -------8<-------8<-------8<-------8<-------8<-------8<------- Which is essentially the same as PATCH_AVAILABLE and RELEASED.
Yepp, and I like that. :) However, Bugzilla does not allow renaming "RESOLVED FIXED" (fix merged but not deployed), and I'm a bit concerned that changing the name would break a lot of Bugzilla query URLs out there.
As I understand it, the bug states we might want to capture are:
[Existing UNCO/NEW/ASSI/REOP]
* In gerrit but not merged - "PATCH IN REVIEW" (eww) or "COMMITTED" or whatever. * In gerrit and merged but not yet in production - "RESOLVED/FIXED" (confusing) or "MERGED" or whatever. Breaking queries' URLs would suck, though. * ? In production in /some/ places - not sure if we'd want to capture this, especially as we're hoping to move to continuous deployment anyway. * In production in all of the WMF cluster - "RELEASED", replacing the unused "VERIFIED" state? * ? In a tarball release - maybe "CLOSED" could be used for this, but renamed? - WMF isn't the only user of MediaWiki, after all.
Note that this ignores the state of merged-but-not-yet-fully-automatically-tested (:-() which I'd like to hope we don't have to deal with for much longer when we can finally merge in the cross-browser testing into gerrit's +2 gating.
Also, +1 to a "Fixes-Bug: 123" annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic "Bug 123" vs. "Bug: 123". :-)
J.
On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforrester@wikimedia.orgwrote:
- In gerrit but not merged - "PATCH IN REVIEW" (eww) or "COMMITTED" or
whatever.
Committed would've been appropriate in Subversion, but 'committed' in Git does not guarantee it is available in Gerrit.
On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforrester@wikimedia.org wrote: * In gerrit and merged but not yet in production - "RESOLVED/FIXED"
(confusing) or "MERGED" or whatever. Breaking queries' URLs would suck, though.
I agree, we shouldn't break existing URLs. Let's not rename existing ones.
On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforrester@wikimedia.org wrote:
- ? In production in /some/ places - not sure if we'd want to capture
this, especially as we're hoping to move to continuous deployment anyway.
- In production in all of the WMF cluster - "RELEASED", replacing the
unused "VERIFIED" state?
This should definitely not be used for WMF cluster deployment, only for tarball releases to third parties (if at all). Also I'm not sure 'Verified' is completely unused...
On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforrester@wikimedia.org wrote:
Also, +1 to a "Fixes-Bug: 123" annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic "Bug 123" vs. "Bug: 123".
+1 from me as well.
Alex Monk
On 06/06/2013 11:16 AM, Alex Monk wrote:
This should definitely not be used for WMF cluster deployment, only for tarball releases to third parties (if at all). Also I'm not sure 'Verified' is completely unused...
I don't generally use it, but I've seen the QA/browser testing team do so.
Matt Flaschen
On Fri, Jun 7, 2013 at 6:24 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
Also I'm not sure 'Verified' is completely unused...
I don't generally use it, but I've seen the QA/browser testing team do so.
That would probably be only me. :) I can live without "verified".
Željko
On 06/06/2013 11:16 AM, Alex Monk wrote:
Also, +1 to a "Fixes-Bug: 123" annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic "Bug 123" vs. "Bug: 123".
+1 from me as well.
Filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=53387
Matt Flaschen
On Thu, 2013-06-06 at 16:05 +0100, James Forrester wrote:
As I understand it, the bug states we might want to capture are:
Yes, I couldn't have come up with a better summary. Thanks!
- In production in all of the WMF cluster - "RELEASED", replacing the
unused "VERIFIED" state?
I wouldn't replace VERIFIED - it got set ~470 times in the last 180 days [1] and is used by Wikidata, QA, and sometimes other teams.
andre
[1] https://bugzilla.wikimedia.org/buglist.cgi?chfieldto=Now&query_format=ad...
Hi,
On Thu, Jun 06, 2013 at 12:15:47AM +0200, Andre Klapper wrote:
Hence I propose * [ drop "patch-in-gerrit" keyword ] * [ Add "PATCH_AVAILABLE"/"PATCH_TO_REVIEW" status ]
I'd love to see that happening. :-)
Best regards, Christian
wikitech-l@lists.wikimedia.org