4 month release cycles (was: Re: Technical Release Manager for Samba)
kseeger at samba.org
Mon Jun 1 13:43:26 MDT 2015
On Wed, May 13, 2015 at 07:09:24AM -0400, Ira Cooper wrote:
> On Wed, May 13, 2015 at 1:08 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Tue, 2015-05-12 at 11:56 +0200, Stefan Kania wrote:
> > > Hello,
> > >
> > > I followd your discussion all the way and now I think I should give you
> > > a different point of view. I install Samba for many years (starting with
> > > Samba 2) to many small custemers upt to 200 Clients. For me the packages
> > > from the distribution was never a good choice. These packages are often
> > > to old or not complet. So I started compiling samba onmy own. For many
> > > years I'm only using the Sernet-packages.
> > > The biggest pain for me is often the update to the next version. Why?
> > > Because the releases have so many changes, that somtimes it takes a long
> > > time to find the problems after a update to the next version.
> > > So I think a short cycle of 4 or max. 6 month would be very good.
> > >
> > > On more thing you should think about. Som of you said that many
> > > customers build ther one packages from source. I think you will find a
> > > lot more installations with distribution-packages and sernet-packages as
> > > you will find selfcompiled Samba4. Because the people who compiled there
> > > own samba will give feedback.
> > >
> > > So for me over the years of implementing Samba a short cycle would be
> > > much better then 9 or 12 month and then do an update with many changes.
> > > And if, after 4 month you have only bugfixes and no new functions, so
> > > what? A new version don't need a lot of new features, a new version must
> > > be more secure and more reliable.
> > Thanks. I got very similar feedback when I was with a customer on
> > Monday. They are big fans of short release cycles, and use them for
> > their own internal development, as short a 2 weeks. For them, seeing
> > features they needed, like bad password lockout, sit in a branch for 12
> > months before the release, and then for me to see users notice a bug
> > (double-counting) only 12 months later, was quite frustrating.
> > That is, they would also much prefer 4 month release cycles, with
> > smaller sets of changes.
> The argument that our release policies need change is undeniable. I
> disagree with the path you are proposing mainly because I see flaws in it
> from the point of view of the people contributing to it. Mainly in that if
> we miss a release, 4 months is a long time to wait. I know that in my case
> for instance, we'd just branch internally to deal with it. We'd have no
> choice. Missing one of our releases internally with a major feature, bug
> fix, or whatever is not an option. Given that I like my job... "Fork or
> die." :)
> I suspect we are not alone. I look at 4 months as almost a "perfectly
> wrong" number, unless planned carefully, but due to the need to a technical
> release manager, I tend to doubt that we'll do that.
> I've submitted a talk to SambaXP on this topic, and it has been accepted.
> I feel that teaching others how to think about release planning, is going
> to be VERY key to affecting the type of change we all want. I don't think
> any of us like where we are today.
> 2 week iteration cycles are very common for "Scrum" teams, typically in
> more commercial development, and also where developers are more dedicated
> to a single given task. Scrum is very popular because it encourages small
> iterative changes. Which can work QUITE well, especially in web projects.
> It is said that Facebook and Amazon both publish code changes to their
> websites every about 30s. So 2 weeks is even a slow cadence along such
> schedules. :) It is all a shade of grey. (In fact, that's the name of my
> talk - 365 Shades of Grey.) There are teams that run with different
> cadences, and even some that use no cadence at all. It depends on the
> leadership, the tasks, and the people on the team how well such things
> work, and a good leader is always looking at such things and evaluating how
> to do better. (In fact, I actually used to run a scrum team. I pulled it
> out of scrum realizing it was an awful fit for our workflow.)
> I'd love to tighten up our iterations within the Samba team, and stop the
> drop of 30+ element patchsets. But I doubt that will happen for many
> reasons, not the least of which is many pieces of Samba development are
> done for competitive advantage, and released only once complete, and their
> sponsor has gotten their advantage from them. Another reason is that we
> don't allow the drop of incomplete features. Because of this we have to
> spool up larger patchsets, where in Scrum, we'd have smaller more bite
> sized deliverables. I'll admit we are doing better here, allowing internal
> refactorings that lead up to major features. Volker Lendeke does a great
> job with this approach.
> (Note, the large patchsets have also blocked the integration of Gerrit, as
> you know. There is just no good way to review a 20+ element patch set in
> most tools. I've found ones that work for me personally.. but that's
> another topic.)
> On the subject of actual change, it needs a major thing: buy-in.
> I don't think you'll get buy-in over the mailing list. Certainly not with
> the approach being taken, which I don't feel has been very open and
> Before you ask: Why not on the list? Because there are things best dealt
> with over high bandwidth communications. Dealing with this properly on the
> list will take months, if the deal can even be sealed. Also there are
> groups that may not be able to say their plans publicly, and we STILL have
> to account for them if they make up a large fraction of our contributors.
> Deals are sealed with a handshake for a reason, sometimes, people need the
> "soft" things to make large changes like this happen.
> I look forward to brainstorming with the whole team at XP, and coming up
> with a solution to our joint problems, using a joint language. (Which
> until my talk, may be hard to have for some of the topics...)
During the Samba Team meeting at SambaXP, we decided to go back to the 6 month
release cycle and stick to the current process. The next major release is
scheduled for October 1st. for more details on the Samba release
management, please see
So there will be major releases in April and October every year.
More information about the samba-technical