Which patches are NOT for 4.0?

[Michael Adam]

On 2012-09-25 at 09:42 -0700, Jeremy Allison wrote:
> On Tue, Sep 25, 2012 at 09:25:38AM +0200, Stefan (metze) Metzmacher wrote:
> > [Andrew Bartlett wrote:]
> > 
> > > 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.

Yes, at least for the ones that should be in 4.0.

> > > 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. 

-1 for reasons written below.

> > > 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.

But it really sounds like a backdoor for circumventing the
bugzilla/review requirement and basiaclly merging again.
I don't suggest that this is your intention at all, but think about,
what the consequences really are!

> 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

We should not try to shortcut by fake bug reports
that are the equivalent of a merge.

> > I think for documentation changes we could use a bulk bugreport/patchset,
> > but the rest should be based on isolated bug reports.

+1 for the compromize for documentation changes.

While Metze is maintaining his branch and will certainly catch
many if not all patchsets that should be put to 4.0, I think
every developer should currently consider each of her patches
pushed to master, and create corresponding bug reports directly
if appropriate.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120925/23fded55/attachment.pgp>