UI Changes

[Myk Melez]

David Miller wrote:

> What I'm going to do is give Kiko a branch to play on, with a few 
> conditions on it.  We successfully used a branch for the group system 
> rewrite, and although it is in smaller pieces, this is a similar 
> magnitude change, so we ought to be able to make it work.

Branches are forks, so they're dangerous as well as promising.  I'm 
troubled by this branch, because the recent UI patches I've seen from 
the branchers (bugs 232659, 251656, 253014) have needed work to land and 
sometimes included changes I've rejected, some of which have 
subsequently landed on the branch.  The more such changes (whether 
needing work or rejected) land on the branch, the harder it will be to 
land pieces of the branch on the trunk, and the less likely it will be 
to happen.  That would be bad for all concerned and most of all for 
Bugzilla.

So bear in mind the following advice for the branch:

As with other Bugzilla hacking, keep your patches maximally atomic, 
making one discrete feature change in each patch.  Not only does this 
prevent controversial or ultimately rejected changes from holding up 
integration of the rest, it makes iterative integration possible, 
keeping the trunk and branch in sync as much as possible.

Also, keep to current Bugzilla coding standards, or hash out changes on 
the trunk and on the developers list.  It will make integration 
significantly more complicated if we have to consider changes to 
Bugzilla coding practice in addition to the functional changes being 
integrated from the branch.

Finally, if you propose changes, whether in discussion or patches, and 
the changes are rejected, don't land them on the branch.  Doing so just 
makes integrating related and proximate changes harder.

-myk