Technical Release Manager for Samba

Stefan Kania stefan at
Tue May 12 03:56:09 MDT 2015

Hash: SHA1


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.

Am 07.05.15 um 08:33 schrieb Michael Adam:
> On 2015-05-06 at 12:29 +0200, Björn JACKE wrote:
>> On 2015-05-05 at 16:41 +0200 Stefan (metze) Metzmacher sent off:
>>> As written before I think 4 month cycles are too short for us. 
>>> 6 would be ok for me.
>> I think 6 is too short. As mentioned by others, we're not able to
>> support so many releases and we cannot stop support for a release
>> after a year or so.
> Hey, you are actually the first to give an argument for saying that
> 6 (or 4) is too short... :)
> I have already layed out the options for this in another thread but
> noone has commented.
> With our current approach of 3 supported releases, (current,
> maintenance, security), we have this:
> 9 months cycle => 27 months lifetime 6 months cycle => 18 months
> lifetime 4 months cycle => 12 months lifetime
> Of course on could consider adding two cycles of security releases
> for a release (which arguably poses the least efforts), then we'd
> have:
> 6 months cycle => 24 months lifetime 4 months cycle => 16 months
> lifetime
> Not sure whethe that would be worth it but it might be the easiest
> way to extend the lifetime.
>> This will put the work of backports to the distributors. This is
>> not what we want for sure.
> I think that the distributors do already have to do the work of
> maintaining backports to unsupported versions. This is nothing new.
> And I think it would not change much to move to shorter cycles. But
> maybe I am off here. Maybe the maintainers of the distributors
> should comment themselves. :)
If you talk about distrubions and their lifecycle then even 24 month are
to short, so for example ubuntu must change version during LTS-liftime
or remove samba from long term support.

> And with each single release being not such a bing change, we might
> lower the bar for adopting newer versions, possibliy in alternate
> software channel.
That's absolutly right! That's what I allways here wenn I want to do an
update. "Will it work after the odl version is running for such a long
>> [...] Currently we don't even manage to get the releases out in
>> time with our current time plan. The reason for that is that
>> there are "release blocker bugs" which stop Karolin from
>> finishing the release. Most of those bugs in the "release blocker
>> bugs are actually no regressions. There are a lot of feature 
>> enhancements, which some developers would like to finish before a
>> new release. This is the main problem I see. Karolin doesn't want
>> to decide on her own which of the bugs listed in the release meta
>> bugs need to be fixed and which not.
>> I also worked on clearing up the list of bug IDs in those release
>> blocker bugs and I know what pain that is. It is a real pain,
>> becuase there are just numbers listed. No list of bug
>> descriptions or anything. This is the reason why also few people
>> actually actively help to recude the number of blocker bugs, even
>> if Karolin begs for help to bring down that number.
>> And it is frustrating to see that even when the release date is
>> over since several months, that there still come new "blocking
>> bugs" which are feature enhancements, this is very frustrating
>> for everyone working and helping on getting the new release out.
> Right. This was the main point in bringing up the topic of release
> cycles. (Which is actually a different thread.) I have long
> advertiesed that we should not have any blocker bugs at all,
> essentially.
> The proposal is to stick with strict release schedule. No excuses
> (technically).
And the argument is that this
> will be much much easier with shorter release cycles, since
> slipping a release with a pretended blocker bug just means a delay
> of 4 (or maybe 6) months instead of 12+ months which hurts much
> more.
> And each single release should require less work and, more
> importantly, less frustration.
> Cheers - Michael


Version: GnuPG/MacGPG2 v2.0.16 (Darwin)


More information about the samba-technical mailing list