Which patches are NOT for 4.0?

[Jelmer Vernooij]

Am Tuesday, den 25.09.2012, 09:42 -0700 schrieb Jeremy Allison:
> 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.
I agree that we should consider carefully what changes make it into the
4.0 branch. I'm not convinced that we need the (fairly heavyweight)
bugzilla-based system for that though?

Metze suggested going over the changes in master and filing bugs for the
changes that are relevant for the 4.0 branch. That seems fine to me, but
who would take care of that?

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120925/fe96f199/attachment.pgp>