To release Samba 4.0 'as is'

[Michael Adam]

Yo,

Jeremy Allison wrote:
> On Thu, Dec 01, 2011 at 12:12:44PM +0100, Kai Blin wrote:
> > On 2011-12-01 11:46, Andrew Bartlett wrote:
> > 
> > > However, it seems clear (but not stated clearly) that those who
> > > would be called on to support that code are not
> > > willing/able/confident to support the release of the fileserver
> > > components at this time.
> > 
> > Because you're proposing to release something in the middle of their
> > release cycle. You're happy to rely on autobuild for sanity checking,
> > but at least the last couple of Samba 3.x series releases had more
> > vetting before a release. This is significant extra effort, which as
> > far as I understand doesn't really make sense at this point of the
> > file server release cycle, because that's currently in the "add new
> > features" stage.
> > 
> > > Given that, I'm puzzled, but happy with a AD only release.
> > 
> > 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.
> 
> 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.

Yes, this is how a 4.0 release should be brought about.

I want to make one thing clear, in addition to Kai's thoughts:

It is to my understanding not the case that a release would
somehow disturb the s3 feature development efforts in master.
We usually fork a release branch, finish the features that
need some finishing in master and the release branch in parallel
and do new features in master only. From this point on, the
release branch can stabilize. It makes no sense of course to
branch at a time at which there are too many started but
(too) incomplete features in master. But this should not really
be the case.


So the general strategy we (I thought) agreed upon in the past was this:

1. 4.0 Releases should done with the same release mechanisms as
   currently the 3.X series.

2. If after the 3.6 release, we next have s3-only features ready
   that are worth releasing, the next release might be a 3.7.

3. If instead the next features ready (enough) is the AD part
   then the next release can be 4.0. And the next s3 file server
   features can go into 4.1 (or 4.2, ...)


It simply depends on what happens first. Next s3 features might
e.g. be some of the smb2 items we are working on. And to my
understanding, the main missing feature for 4.0 is the releasable
integration of the smbd file server into the s4 ad setup. And for
this, we have to agree first on how we want do to it for 4.0.
(Sorry, if I keep saying this over and over again. But this
discussion has been started and given up again too often. We need
to decide on this...)

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/20111201/a7ea8586/attachment.pgp>