To release Samba 4.0 'as is'

[Andrew Bartlett]

On Wed, 2011-12-07 at 10:25 +0100, Stefan (metze) Metzmacher wrote:
> 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 fully agree about branching late.  I think that 3.6 clearly showed
that branching before we absolutely must simply creates a branch with
missing patches, less testing and less stability than the so-called
development branch it diverged from.  By concentrating all of our
efforts on one branch, we improve software quality overall. 

However, the other lesson I think we should learn from 3.6 is to be
willing to deliver less than we have promised, get the other good work
we have done to our users, and and release what we wanted to promise
later. 

We learnt from painful experience that our software was not improved by
continuing to make large changes to our released branches, so we became
more conservative.  However, that conservatism has also meant we fail to
release software in a timely manner, which creates even more pressure on
those few releases we make.  

On the example of Samba 3.0: this was an incredibly long release cycle,
and the feeling at the time was that it showed that it was too long -
our alpha17 release was production deployed on the SnapAppliance NAS for
5 years after that release, and my view is that we should really have
released 3.0 much earlier.  

> > 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 agree that samba4wins shows us that we can make a feature-only release
without causing major confusion.  I would really like to see a Samba
4.0.0 with everything, but our users deserve a production release of the
DC, and we should not hold them up while waiting for full integration. 

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

I would certainly still hope we could make a release in the first half
of 2012, but it will require commitment from the whole team that we want
the release to be made.  3.6 took so long in my view because while we
said 'we have branched for the release', in practice the team voted by
commits to continued development.   

For these reasons, I think that a samba4 AD release is the most
practical in the short term, while we aim for the 4.0.0.  Our users
deserve a release, and our software deserves to be used.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org