The New Bugzilla::DB::Schema

[Shane H. W. Travis]

On Thu, 10 Mar 2005, Gervase Markham wrote:

> Shane H. W. Travis wrote:
> > *Someone* has to do the work of making the code in patch A play nice with
> > the code in patch B wherever they conflict.
>
> Hmm... This is why Mozilla used to have a branch landing tool, so people
> could queue up and know whose code they had to merge and what order they
> were in. Perhaps something like that would be good?

Could be... but I don't understand how it would help in your situation.

If Patch A was in the queue first, but Patch B -- which was behind it in the
queue, and touched the same code -- was ready to land, would Patch B be held
up until Developer A got his all polished up?

Also, at what point does one get to put one's patch 'into the queue' so that
nobody else is allowed to break something that this patch touches?
- Once you've ASSIGNED the bug to yourself
- Once you've got a patch ready
- Once you've got an r+
- Once you've got an a+

#1 is ridiculous; people take bugs all the time, and sometimes don't work on
them for years.

#2 isn't quite as ridiculous, but sometimes there's a loooong time between
when that first patch comes down, and then the last one is ready to land.
(What did you say, 1.5 years already in your case?) Also, the last patch
sometimes bears little resemblance to the first.

#3 and #4 seem reasonable, but are already pretty much in line with current
practices, which I infer you don't like. ("Currently, it's a case of
'whoever has most time to get on IRC and find a reviewer get there
first'...")

Furthermore, having a queue doesn't stop conflicts; someone still has to
merge Patch A into Patch B -- or the other way around -- only now it depends
on who gets into the queue first rather than who lands first. I don't see
how this presents any benefit; it just seems to add another layer of
complexity (and perhaps frustration) to the process.


For those who don't hang on IRC and therefore haven't heard my statistics,
this has been the most fertile period in Bugzilla's development history
*ever*. Developers have landed fixes on almost three *hundred* bugs in the
first 70 days of this calendar year; that's more than half as many as were
fixed in all of 2004 (575), and almost as many as were fixed in 2003 (371).
We'll probably surpass the latter total before March is out.

So... yes; patches sure can bitrot fast these days. That's damnably
frustrating when it's one's own patch that one is re-writing, no doubt about
it. In the grand scheme of things, though, it's an impressive tribute to
just how strong and healthy the development team is right now.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith