4 month release cycles (was: Re: Technical Release Manager for Samba)

Karolin Seeger 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
> accepting.
> 
> 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

  https://wiki.samba.org/index.php/Samba_Release_Planning.

So there will be major releases in April and October every year.

Cheers,
Karolin

-- 
Samba			http://www.samba.org
SerNet			http://www.sernet.de
sambaXP			http://www.sambaxp.org



More information about the samba-technical mailing list