On Wed, Dec 12, 2012 at 7:03 PM, Andre Klapper <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
