Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Wed, 2012-12-12 at 19:03 +0100, Andre Klapper wrote: I'm proposing adding a new status like PATCH_TO_REVIEW or or something like this (bikeshed, yay!). Probably the first. The status would replace the patch-in-gerrit keyword Thanks for the opinions and comments so far. I don't plan to follow up on this right now as I happily realized that the Wikidata project is working on automatic patch notifications from Gerrit into Bugzilla. I'll likely pick up this thread again for re-evaluation once we have these notifications in place. andre -- 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
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 13/12/12 01:15, Sébastien Santoro a écrit : ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. Gerrit gives the detail. I must agree there. There is still one use case for which we do not really have a solution: find out bugs that do not have a patch in Gerrit. We have some keywords such as patch, patch-in-gerrit, patch-need-review, patch-reviewed thus I think the proposal is for us to switch from keywords to bug status. I never use the patch* keywords and would largely prefer using the bug status, that will assist me when triaging my bug lists. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 13/12/12 02:27, Matthew Flaschen a écrit : People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. We can find patches to review in Gerrit. I think the proposal is more about finding out bugs in bugzilla that do or dont have a patch in Gerrit. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Thu, 2012-12-13 at 02:09 +0100, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? See below. Plus as Bugzilla already has a patch-in-gerrit keyword (and other patch* ones) so somebody in the past had interest to identify bug reports that have a patch in Gerrit, for whatever reason. I'd like to know the reasons. Then we'd have to keep that in sync (back from this PENDING to ASSIGNED after the change is rejected?). Same currently with the patch-in-gerrit keyword, so neither better nor worse than before. Only more maintenance and bureaucracy for imho no obvious gain or purpose. A bug report that has a publically available initial patch, even if the patch still needs lots of rework, is closer to getting fixed than with no code at all. Plus old rotting patches might be another entry point for some people to pick up and contribute. The queryable state is ASSIGNED (and maybe, though I personally don't find it useful, the keyword patch-in-gerrit). And for any further details just open the bug and read it. ASSIGNED status is meant to express that somebody works on fixing a bug. Some assignees give up and forget to reset ASSIGNED. Nobody else can start working on it [2] and only the assignee her/himself could answer if s/he's still working on a bugfix. For patches at least *anybody* can easily query the status of a patch in Gerrit and see that it's rotting. The real status and progress is not only in somebody's head or on somebody's harddisk. andre -- 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
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Wed, 2012-12-12 at 12:23 -0800, Rob Lanphier wrote: My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. In the long run I see that rather done by integration between Gerrit and Bugzilla, e.g. adding an automatic Patch has been merged into codebase into branch $FOO which will end up as MediaWiki tarball 1.x.y. Availability of the fix on Wikimedia servers can take up to two weeks, see https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap; comment in Bugzilla once a patch has been merged in Gerrit that refers to a bug ID. Something like https://bugzilla.wikimedia.org/show_bug.cgi?id=42150#c5 The more statuses (statii?) we add, the less likely they'll actually be a source of actual information. I'd like to have clarity and transparency which state a bug report is in. It's true that this requires acceptance. Currently not everybody uses the patch-in-gerrit keyword (for different reasons) and it's one step on the way to getting a bug fixed, so it should have never been a keyword anyway IMO. I sometimes run into bug reports that never got closed though the related Gerrit patch got merged a while ago. Personally I see some potential to make it easier for triagers to identify such forgotten tickets (and future might prove me wrong). That said, I know that many developers get confused about when they should mark things fixed, and hold off on doing so because things just get reopened with hey, it's still broken for me. We fail to explain deployments to users. I'd like to fix this too, but not in this step. To me: RESOLVED FIXED = patch got *merged* in Gerrit. I'd like the developers to be able to mark things off of their list when they're done with them That's exactly one reason why I bring this up. As quoted in my initial posting, see https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 - some developers want to exclude bug reports from queries when this reports have a patch for review in Gerrit. andre -- 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
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
In my opinion Patch-in-gerrit is a distinct stage in the life cycle of a bug, and deserves its own status. A patch-in-gerrit does not mean the same thing as assigned. Assigned bugs are being worked on by someone. There work may or may not be publically visible yet. They are probably not at the stage where they want review of their work so far on the bug (obviously there are exceptions to that for complex bugs), etc. A patch-in-gerrit does mean that there is a fix for the bug available. It has not been reviewed yet. It needs people to test the patch/review/comment. It does not mean the bug is fixed (and definitely not deployed, but I agree that is a different discussion). If I downloaded a nightly version of MediaWiki the patch is not there. Some people may want to look for bugs with pending patches. At the very least, many people would want to know that there's a pending patch when bugzilla is displaying the list of bugs in the search window. In different life stages of a bug, different types of love need to be given to a bug. Thus the different stages should get different statuses. tl;dr /me really likes Andre's plan. p.s. This is not the first time this has come up - https://www.mediawiki.org/wiki/Thread:Talk:Git/Workflow/Bugzilla -- -Bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Two quotes from the last weeks:
Krenair in #mediawiki on Nov 30 22:46:47:
andre__, what is stopping us from making a 'patch in
gerrit' bug status with a link to the change?
Ryan Kaldari in
https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 :
I use Bugzilla as a to-do list. [...] If Bugzilla had a 'Waiting
for Merge' status, this wouldn't be as much of an issue.
Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug
report ends up as RESOLVED FIXED there usually had been a codefix in
Gerrit that got merged. Hence patch in gerrit could be considered
another state on the journey of a bug from reporting to fixing.
And Bugzilla allows adding stati (stuff like NEW or RESOLVED).
I'm proposing adding a new status like
PATCH_TO_REVIEW or
WAITING_FOR_MERGE or
FIX_AWAITING_MERGE or
REVIEW_IN_PROGRESS
or something like this (bikeshed, yay!). Probably the first.
The status would replace the patch-in-gerrit keyword and you would set
it in Bugzilla when you have pushed a patch into Gerrit for review that
is expected to fix the reported bug. (Not sure what to do about partial
fixes, but that's a cornercase.)
Obviously, once the patch got merged you'd close the corresponding bug
report as RESOLVED FIXED. No changes here.
Bug report life cycle: The new status could be set from {UNCONFIRMED,
NEW, ASSIGNED, REOPENED} and could be transfered into {UNCONFIRMED, NEW,
ASSIGNED, REOPENED, RESOLVED}.
Comments / arguments?
andre
PS: Underscores in the status name are needed as far as I know.
Please keep opinions for other email threads that are about renaming
some other Bugzilla stati, or better linking between Bugzilla and
Gerrit, or automatic status setting in Bugzilla when a patch is in
Gerrit, or somehow distinguishing in Bugzilla between the situations
fix merged into code repository, fix released in MW tarball and fix
deployed on an MW server. I hereby thank you kindly! :)
--
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
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 12/12/12 19:03, Andre Klapper a écrit : snip I'm proposing adding a new status like PATCH_TO_REVIEW or WAITING_FOR_MERGE or FIX_AWAITING_MERGE or REVIEW_IN_PROGRESS or something like this (bikeshed, yay!). Probably the first. snip I use Bugzilla as a todo list and would love to filter changes that have or dont have a patch in Gerrit. Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). That let them create release notes out of the bug tracker. In our case I would simply create a single status before RESOLVED that would state there is a patch in Gerrit. We could even imagine changing that state to RESOLVED whenever the patch has been merged. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
There's also the question of released in tarball vs deployed on Wikipedia. A lot of people just care about the latter. And about the original question - I support the idea and don't care how is it called. בתאריך 12 בדצמ 2012 20:14, מאת Antoine Musso hashar+...@free.fr: Le 12/12/12 19:03, Andre Klapper a écrit : snip I'm proposing adding a new status like PATCH_TO_REVIEW or WAITING_FOR_MERGE or FIX_AWAITING_MERGE or REVIEW_IN_PROGRESS or something like this (bikeshed, yay!). Probably the first. snip I use Bugzilla as a todo list and would love to filter changes that have or dont have a patch in Gerrit. Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). That let them create release notes out of the bug tracker. In our case I would simply create a single status before RESOLVED that would state there is a patch in Gerrit. We could even imagine changing that state to RESOLVED whenever the patch has been merged. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. The more statuses (statii?) we add, the less likely they'll actually be a source of actual information. That said, I know that many developers get confused about when they should mark things fixed, and hold off on doing so because things just get reopened with hey, it's still broken for me. I'd like the developers to be able to mark things off of their list when they're done with them, and the rest of us to worry about communicating when the fix is actually released/deployed or is otherwise relevant to them. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
2012/12/12 Rob Lanphier ro...@wikimedia.org: The more statuses (statii?) we add, statūs, if I recall correctly. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING On Wed, Dec 12, 2012 at 12:34 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2012/12/12 Rob Lanphier ro...@wikimedia.org: The more statuses (statii?) we add, statūs, if I recall correctly. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 12:44 PM, Jon Robson wrote: I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING I'd prefer something more specific. I actually think PATCH_IN_GERRIT (the keyword) would work well as a status. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
I think we could have different types of pending - pending design pending review pending legal etc etc. Maybe this is out of scope though..? On Dec 12, 2012 12:55 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 12:44 PM, Jon Robson wrote: I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING I'd prefer something more specific. I actually think PATCH_IN_GERRIT (the keyword) would work well as a status. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Wed, Dec 12, 2012 at 7:03 PM, Andre Klapper aklap...@wikimedia.org wrote: Two quotes from the last weeks: Krenair in #mediawiki on Nov 30 22:46:47: andre__, what is stopping us from making a 'patch in gerrit' bug status with a link to the change? Ryan Kaldari in https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 : I use Bugzilla as a to-do list. [...] If Bugzilla had a 'Waiting for Merge' status, this wouldn't be as much of an issue. Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. Gerrit gives the detail. We already have problems to get all the developers to used ASSIGNED field, let's avoid to complicate with other fields, with a rather limited purpose scope. I would also like to stress the assumption 1 issue = 1 bug on Bugzilla = 1 patch on Gerrit isn't verified in real world. This idea completely blocks any situation where two patches or a patch and then a configuration on the wiki has to occur to solve the bug. For what goal? - Compute statistics -- we could get them from Gerrit - Identify patches waiting to be merged - that's exactly the goal of the Gerrit dashboard For what drawbacks? - Less flexibility - Greater bug handling learning curve I would really like to get our bugs system simple (KISS) and not to clutter with not needed features. -- Best Regards Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 04:15 PM, Sébastien Santoro wrote: Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. That doesn't make sense to me, since I can be assigned something, and actively working on it, but not have submitted a Gerrit at all yet (let alone one almost ready to be merged). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Dec 13, 2012, at 1:25 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 04:15 PM, Sébastien Santoro wrote: Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. That doesn't make sense to me, since I can be assigned something, and actively working on it, but not have submitted a Gerrit at all yet (let alone one almost ready to be merged). Matt Flaschen I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). Then we'd have to keep that in sync (back from this PENDING to ASSIGNED after the change is rejected?). Only more maintenance and bureaucracy for imho no obvious gain or purpose. The queryable state is ASSIGNED (and maybe, though I personally don't find it useful, the keyword patch-in-gerrit). And for any further details just open the bug and read it. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 05:09 PM, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/12 21:23, Rob Lanphier wrote: My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. On which wiki? We could have it deployed on part of the cluster only. The difference is between Waiting for merge and Fixed. Once it is fixed, the landing is automatic, from the commit hash, there could be a tool which showed you if it's on wmfxy, on which tarball release it will appear, if you can see the fix in test2, to which wikis it's deployed and approximate time for deployment to your home wiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Thu, Dec 13, 2012 at 2:27 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 05:09 PM, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. The Gerrit dashboard prints the first line of the change, which should begin by (bug 12345). So your view Bugs to review already exists in Gerrit dashboard. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
