Bugzilla workflow with review

[Karolin Seeger]

On Thu, Nov 29, 2012 at 10:25:46AM -0800, Jeremy Allison wrote:
> On Thu, Nov 29, 2012 at 07:45:40AM -0500, Ira Cooper wrote:
> > IMHO:  Separate patches == Less confusion.
> > 
> > The chance that we'll get it wrong is lower, and as the branches diverge,
> > which they always do, we'll be posting 2-3 patches anyways.  (One for
> > master, one for 4.0 and one for 3.6 potentially.)
> > 
> > And what applies on master won't always apply on 4.0 which won't always
> > apply on 3.6.
> > 
> > It also makes it all "complete" when you go back into a bug and go "what
> > happened to close this bug."  You can read the actual code reviewed and all
> > the stages of review it went through, you don't have to go digging through
> > git, and have lost review history etc.
> 
> +1 on this. The reason I attach separate patches
> for branches even though they may be identical to
> a cherry-pick is so that the bugzilla record is
> complete for what went into each branch, without
> having to refer to git history.


+1 on this.

I would prefer attaching all patches to the bug report, too. Indeed it's
good for tracking and additionally, users can try the patches easily and
do not need to checkout out the git branch. From my point of view that is
very important.

Additionally, I think it encourages the developers not to just say
"cherry-pick to v4-0-test", but to apply the patch and double check if the
patch makes sense and is correct for 4.0. That also reduces the "patch
does not apply to" situations.

From my point of view, it's less work to download and apply a patch from
bugzilla which includes all information (cherry-pick, bug number) than
cherry-picking myself and adding the additional information manually.
But that's not an argument, I know ;-).

Karolin

-- 
Samba			http://www.samba.org
SerNet			http://www.sernet.de
sambaXP			http://www.sambaxp.org