Which patches are NOT for 4.0?

Andreas Schneider asn at samba.org
Wed Sep 26 09:43:40 MDT 2012


On Tuesday 25 September 2012 19:36:04 Karolin Seeger wrote:
> On Tue, Sep 25, 2012 at 09:42:16AM -0700, Jeremy Allison wrote:
> > On Tue, Sep 25, 2012 at 09:25:38AM +0200, Stefan (metze) Metzmacher wrote:
> > > Hi Andrew,
> > > 
> > > > I just wanted to raise an interesting observation from watching the
> > > > GIT
> > > > tree since rc1.  That is, when selecting the patches we want to get in
> > > > the rc2 release, we might want to work not just off the bugs in
> > > > bugzilla, but instead look over *all* the patches in master.
> > > 
> > > We should look over all patches and create bugreports for all logic
> > > subunits.
> > > E.g. one bug report for all sorts of quota related fixes.
> > > Or one bug report for smb2.durable-v2-open.app-instance related tests
> > > and the implementation.
> > > 
> > > > I don't see this as us 'releasing from master', but instead just
> > > > noting
> > > > that there isn't any feature work going on yet, and that everyone is
> > > > and
> > > > has been working exclusively on release-critical bugs.
> > > > 
> > > > Naturally, this gets harder as soon as someone starts on features for
> > > > 
> > > > 4.1, but for now, I just wanted to raise the idea as either:
> > > >  - a benchmark to compare with (so we don't miss something)
> > > >  - or a way perhaps two of us could work over the patch list and
> > > >  prepare
> > > > 
> > > > a single, larger bug with most/all of rc1..master changes in it.
> > > > 
> > > > To be totally clear: I'm not wanting to change our policy on what can
> > > > be
> > > > put into RC at this point, just trying to make the mechanics simpler
> > > > for
> > > > all involved.
> > > 
> > > I'm maintaining a branch locally where I'll rebase origin/master on
> > > origin/v4-0-test
> > > in order to see which things are missing, I think that's enough.
> > > 
> > > I think for documentation changes we could use a bulk
> > > bugreport/patchset,
> > > but the rest should be based on isolated bug reports.
> > > 
> > > And there're already things in master which we don't need in 4.0.
> > > E.g. the "libtorture: factor out simple ui backend" change and some
> > > pysmb changes
> > > doesn't need to be in 4.0
> > > If it turns out just before some release, that we only have a few
> > > patches between
> > > between master and v4-0-test, we can think about picking them for
> > > consistency,
> > > but I wouldn't decide that now.
> > 
> > I'm really happy with the current system of creating bug
> > reports for *every* change that goes into 4.0.0 now we've
> > reached rc.
> > 
> > No blanket backports or cherry-picks allowed, we must
> > think about *every* change we want to make, and it must
> > be reviewed appropriately.
> > 
> > We need to have this kind of discipline if we're going to
> > create a quality 4.0.0 release.
> 
> +1

+1

I wonder what's so hard to create a bug at the same time you push a patch to 
master?


	-- andreas

-- 
Andreas Schneider                   GPG-ID: F33E3FC6
Samba Team                             asn at samba.org
www.samba.org



More information about the samba-technical mailing list