4 month release cycles (was: Re: Technical Release Manager for Samba)
ira at samba.org
Wed May 13 05:09:24 MDT 2015
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
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
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...)
-Ira / ira@(samba.org|redhat.com)
Member - Samba Team
Team Lead - Red Hat Storage / SMB Team
More information about the samba-technical