Technical Release Manager for Samba

Michael Adam obnox at
Thu May 7 00:33:05 MDT 2015

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. :)

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.

> [...]
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <>

More information about the samba-technical mailing list