[TYPO3-core] Combining security and bugfix releases

[Ernesto Baschny [cron IT]]

Am 20.12.2011 00:17, schrieb Olivier Dobberkau:
> Am 19.12.11 03:37, schrieb Christian Lerrahn:
>
>> Well, this is just my five cents worth and I'm happy for people to
>> comment and tell me why I'm totally and utterly wrong to hold such an
>> opinion.
>
> as this is not the first regression introduced by this combined handling
> i would suggest to publish security releases as they are.
>
> adding untested bugfixes to a security release seems to me quite bad.

A TYPO3 security release currently is also just a snapshot of the 
current state on GIT plus the security fixes, which were reviewed and 
tested on a separate branch and cherry picked into the stable branch on 
"last minute" before the release.

In theory all bug fixes on stable branch are "tested and reviewed".

We have worked with e workflow that is in line with your proposal in the 
past, which means:

1) first make a regular bugfix to "flush" the branch from unreleased fixes.

2) mark a "merge freeze" on the stable branch, so that no further bug 
fixes is included until we are *sure* that no regressions from the 
bugfix release were introduced. How long should that be? One week? A 
couple of days?

3) during this merge freeze, make sure we have all security fixes ready 
to be released.

4) do the security release after "x days".

Consider that the amount of development *and* coordination work on a 
security release is *much* higher than on a regular bugfix:

- the bugfix needs to be backported to *all* supported stable releases 
(which includes 4.4, 4.5, 4.6 and master currently) to be releases *at 
the same time*,

- the testing / reviewing of sec issues (core team plus sec team) has 
very limited resources, and unfortunately is not very predictable when 
work on open issues is ready,

- the sec-team needs to be ready on "D-Day" for writing the 
sec-bulletins, the sec-mail etc. This sounds easy, but requires some 
editorial know how that goes a bit deeper than a regular "release 
announcement".

Considering these aspects, you might understand that the proposed 
workflow of dedicated "merge freeze for security issues" is currently 
difficult to apply, as it would halt all other activities surrounding 
bug fixing. Unfortunately we find ourselves postponing security releases 
more often than we want to because of the lack of resources (illness, 
holidays, unreviewed issues, etc...).

In this particular sec-release we also have the problem that we need to 
publish a sec-release fast (because of the 0-day exploit in the wild). 
So basically we cannot "undo" the merges that have been commited to the 
branches since the last bug fixing release, so those will be included in 
the release. So currently:

- sec-release 0.x
- regression discovered, release 0.x+1

Other workflow with a merge-freeze would mean:

- release bugfix 0.x
- regression discovered, bugfix release 0.x+1
- no further regressions, release sec-release 0.x+2

That is, one further release to push out, one further release for people 
to consider installing etc.

Other branching / git-techniques might help us to work out a different 
approach, but it won't help us with getting the fixes ready faster and 
it won't remove the potential of including regressions in any release 
(the danger of a regression in a sec-release is usually higher than on 
other bug fixes).

> once a month on a fixed day i would release a bugfix release.

This has been like this before (core team deciding each month if a 
release is worth it), but it turned out to be too bureocratic, so 
currently it handled "on demand" and usually synched with other "release 
events" (like the planned alpha/beta releases of the next version).

Releasing every month might have the danger that "nothing" was fixed in 
the previous month (might happen to 4.5 once it gets more and more 
"stable").

Some tasks regarding the release currently are still "semi-manual":

- publishing the news on typo3.org
- putting the release notes on the Wiki
- writing to the typo3-announce list
- writing to the newsgroups

So it still involves some person willing to do this, which lately has 
been Olly, sometimes Xavier or myself. Timing releases to simply happen 
on the same day minimizes the amount of work.

This being said, we'll discuss the issue of "predictable bugfix 
releases" with the release team, thanks for the input!

Cheers,
Ernesto