Bugzilla workflow with review

Ira Cooper ira at samba.org
Thu Nov 29 05:45:40 MST 2012

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.


On Thu, Nov 29, 2012 at 7:04 AM, David Disseldorp <ddiss at suse.de> wrote:

> On Thu, 29 Nov 2012 11:51:27 +0100
> Andreas Schneider <asn at samba.org> wrote:
> > I don't see why we need to add a patch for each branch we can't cherry
> pick.
> > It is more work for us and also for Karolin. I'm sure she finds it
> easier to
> > just call 'git cherry-pick <sha1>' instead of downloading each patch.
> >
> > So in most cases there should be only one patch in the bug. The one the
> > reviewer needs to push to master after a successful review.
> I wasn't aware this was the current policy. Anyhow, I agree, it doesn't
> make sense to attach multiple patches if the same can be cleanly applied
> across multiple branches or cherry-picked.
> As long as it is made completely clear in the bug which branches are the
> intended target for a commit/patch, and Karolin is satisfied.
> Cheers, David

More information about the samba-technical mailing list