Which patches are NOT for 4.0?

[Stefan (metze) Metzmacher]

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.

metze



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120925/9a292048/attachment.pgp>