On Wed, Dec 12, 2012 at 7:03 PM, Andre Klapper <aklapper(a)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/