To release Samba 4.0 'as is'

[Stefan (metze) Metzmacher]

Hi,

>>> I think this is a clash of development cultures here, hence your
>>> puzzlement. s4 alphas so far were snapshots right out of master,
>>> whenever people felt there was a reasonable set of new features or bug
>>> fixes, while relying on autobuild/selftest to make sure whatever we
>>> ship actually works. S3 releases come with release candidates, a
>>> release branch that is forked off prior to the release, and a lot of
>>> people testing the release branch in additional scenarios. That's why
>>> the S3 folks have the knee-jerk reaction that you're just dumping a
>>> grab-bag of features out there. It's not what their releases look
>>> like, so they're puzzled as well.
>>
>> +1 on this excellent summation of the issues.
> 
> indeed, thanks Kai! :-) 
>  
>> The thing is - to release a real 4.0.0 we need (IMHO) to
>> move to the 3.x method of release management. The current
>> "release a snapshot out of master" method can't be the
>> way a full 4.0.0 release is done.
>>
>> Once all the new features for 4.0.0 are done we need
>> to branch off a v4-0-test and v4-0-release branch,
>> lock down so Karolin is the only person who can
>> commit, and move to the standard release management
>> for the final 4.0.0 (no changes without attached
>> bug report, 2 team member review etc. etc.).
>>
>> That's the only way to get a quality 4.0.0 release
>> done.
> 
> I agree on this. Please note that it takes ~6 month between
> branching and the final release (known from experience). Shipping
> Samba 4.0.0pre1 in 2 weeks is impossible from my point of view.
> I would like to vote for starting the new branches after
> the plumbing design and the Winbind solution are done (and other possibly
> blocking issues have been addressed).

I think as a step in the release direction, we should change from alpha to
beta releases, once we have the basic logic for the s3fs integration done.
I think
https://gitweb.samba.org/?p=tridge/samba.git;a=shortlog;h=refs/heads/s3fs-wip
looks promising.

For 3.0.0 we had the following release sequence:

...
samba-3.0.0alpha21
samba-3.0.0alpha22
samba-3.0.0alpha23
samba-3.0.0alpha24
samba-3.0.0beta1
samba-3.0.0beta2
samba-3.0.0beta3
samba-3.0.0rc1
samba-3.0.0rc2
samba-3.0.0rc3
samba-3.0.0rc4
samba-3.0.0

I think we should branch at rc1 time, from the 3.6.0 release cycle we
learned
that we would re-sync from master anyway from time to time.
(Or we just re-sync from time to time during the beta releases.)

> I do also strongly argue against shipping the AD server only, except the
> name will be different from s4. IMHO, all s3 features need to be supported in
> the final s4 release (I think Lars wrote that also). Everything else would
> be misleading.

I also agree. For an AD only thing we could do something like samba4wins,
but I think we should aim for a real samba-4.0.0 release.

> I would really love to see s4 final, but to me it seems to be impossible to
> see it in 2012.

I wouldn't be so pessimistic, I think 2012 sounds doable.

metze

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