Which patches are NOT for 4.0?

Stefan (metze) Metzmacher metze at samba.org
Tue Sep 25 12:02:29 MDT 2012


Am 25.09.2012 19:54, schrieb 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?

I'll do that.

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/5e0761da/attachment.pgp>


More information about the samba-technical mailing list