Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)
Stefan (metze) Metzmacher
metze at samba.org
Mon Jun 18 04:55:02 MDT 2012
Am 18.06.2012 12:49, schrieb Michael Adam:
> Hi Karo,
> Karolin Seeger wrote:
>> On Sun, Jun 10, 2012 at 10:39:00AM +0200, Michael Adam wrote:
>>> Karolin Seeger wrote:
>>>> So you guys want to ship bugfix releases with severe known issues?
>>>> That might work with more developers working on bugs on a regular basis.
>>>> Currently, it does not. There are severe bugs that need to be addressed
>>>> before the next bugfix release.
>>> I don't get it. The bugs we are talking about have been there
>>> since some time. We have shipped major and/or bugfix releases
>>> with them. So how can the bug be suddenly so severe that we
>>> should hold back existing fixes for other bugs from our users
>>> until the fix for this bug is available, i.e. for an uncertain
>>> amount of time?
>> Many people hit the issue, so it was kind of approved. Then Jeremy started
>> to investigate and it was pretty soon clear that it's really an issue.
>> But you could have lower the severity youself. Feel free to do that next
>> time. I think this was a bad one and I am glad that it is fixed now.
> I don't want to challenge the importance and severity of some
> bugs. Actually, every bug can be severe. And I don't think
> severity should or can be a lever to block releases: I don't see
> any reason why missing fix for a severe bug overrules an existing
> fix for another possibly severe bug (or several ones).
> Proof of the inconsistence of blockers for bugfix releases (again):
> * We have an open bug #X, that was already present in the
> previous release.
> * We have a fix for at least one different bug #Y.
> * The next release will be more useful than the previous
> release in that it contains the fix for bug #Y,
> so it will help some users.
> * The next release will be as bad as the previous one
> with respect to bug #X.
> * The next release will _not_ be worse with respect to the
> known open bugs than the previous one, since bug #X
> was already open in the previous release.
> => It will be useful/helpful for our users to release without the fix for bug #X.
> * It is not clear that the users will get the fix for bug #X
> if we block the relasese for bug #X.
> q.e.d. :-)
> (The axiom I use here is that the main purpose of a bugfix
> release is to be useful for our users.)
> Note that the above even applies to #X if #X is a security issue,
> if (and only if) the issue is not public yet or the issue has
> not been detected to be security relevant.
> Proposal (again): time-based releases:
> I propose that we agree on a time-based schedule for bugfix
> releases. E.g. a bugfix release every 4 or 6 weeks
> (whatever works for you, maybe even 8 weeks) for the current
> stable release branch. Then we have a list of bugs that we
> would like to fix for that release (basically any bug open
> against the major version). If at freezing time, at least
> one bug is fixed, the list ist closed and the release is done
> as scheduled no matter which other bugs are still open.
> In this mode, the users will get _each_ bugfix in a relase
> as soon as possible after it becomes available. And the users
> are not deprived of important bugfixes because other bugfixes
> are not available yet.
> Handling security issues:
> When a security issue is reported non-publically, and a
> bugfix release is imminent, (within a couple of days, say),
> we should do the bugfix release on schedule and release
> the security release afterwards as soon as we have a fix.
> If we have a fix for the security issue before the freezing
> period for the bugfix release starts, we should release the
> security fix before the scheduled release and see whether
> the original date for the bugfix release can be kept or
> needs to be deferred by some days.
> If there is a bug report that is public but there is a suspicion
> that it might be security relevant, I have not recipe yet. But I
> am inclined to treat it as any other bug until there is proof.
Sounds like a good plan!
We should add that we add the known bugs to the release notes,
that might be also very useful for admins.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical