patchzilla idea

[Max Kanat-Alexander]

On 03/28/2011 10:39 AM, Joe Walker wrote:
> With all the talk about process in dev.planning I thought it might be
> worth jotting down a few ideas wrt patch management that I've been
> mulling on for a while.
> http://etherpad.mozilla.com:9000/patchzilla

	Cool. Let me say first that I'm glad that you posted this, it's
interesting that you're thinking about these problems, and I'm really
happy that you're proposing a creative solution to the community. I
totally agree that there are a lot of things that could be better here,
and anywhere that automation can make a developer's life easier, it should.

	With all that said, I have to admit that I'm pretty skeptical about
this, and here's why:

	Mostly, I think that the problems you're posing are actually people who
are mis-using their bug-tracker. "Work on 2 bugs in the same file" is
probably not a good development process or use of Bugzilla. Fixing
multiple bugs on one "bug" in Bugzilla is also not a good idea, just
from an organization and process-sanity perspective. Having multiple
separate patches that all combined "fix" one bug is also somewhat
questionable--that seems like a situation where there should be blockers
filed and each patch should go onto a separate blocker. In short, with
the "one bug == one problem == one patch" rule, most of this becomes
unnecessary.

	Also, I think that your solution mostly sounds like a duplicate of
Review Board with some enhancements. I have already attempted to get
support for integrating Review Board with Bugzilla, but the direction
that's being taken at Mozilla is to instead re-implement something very
similar to Review Board as a Bugzilla Extension, Splinter. I'm not
saying that that's a good idea, but I'm saying that having a separate
system that tracks patches has already been sort of shot down (although
not explicitly).

	The piece that I do think would be useful (to Mozilla, probably not to
others) is the "please suggest an application order and show me what now
needs rebasing". However, my suspicion there is that it's not something
that can be done reliably with an algorithm. "Find me a set of patches
that will result in the fewest conflicts" may be worthwhile, but may not
actually be always what is desired. Also, how many patches have to be
waiting to land before this is useful? Over 20, I'd say. If there are
that many patches waiting to land continuously that all conflict with
each other, perhaps the system that you're working on needs to be better
factored before you speed up your development process like that, so that
you're not getting so many conflicts. Also, I'd want to know more
specifics about exactly what's causing this problem and how the
development process works currently, so that I could see if improving
the tools is really what's necessary, or if it's actually improving the
process that's required.

	-Max
-- 
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services