[TYPO3-core] Voting for the new release cycles for TYPO3 CMS
klein.t3 at reelworx.at
Thu Jul 31 01:01:16 CEST 2014
Some might have noticed in the doodle voting that my name had a "No" next to it.
Some might have also noticed I posted a small comment with a link with the rationale behind my vote.
I did this as I tried to find the compromise between sparking a new discussion and still giving interested people some insights in my thoughts.
Since we now had troubles with the voting anyway and some more time is left until the original voting phase should have ended, I decided to share this text here in order to give people the chance to maybe clear things up, which I might be wrong about.
Please let me emphasize again that I do not blame anybody for anything here and hopefully nobody feels offended by my words.
So here is my essay:
First off, thanks to all of you investing time and thoughts into improving our management.
Since I couldn't afford to join in personal meetings in the recent past, I haven't been involved in the creation
process of this concept and hence the following is a collection of notes I made from the perspective of a rather
active Active Contributor, who is not involved in "mission critical" concepts like the one at hand.
I'm also sorry that my comments come in that late - actually way too late - but I had my reasons why I was not able to provide these earlier.
Albeit I recently stated that the concept looks "pretty good", I took the time last night to re-read the whole blueprint and go over all comments
posted on the core list. After that I spent some more time to evaluate possible consequences and to gather open questions.
For those who don't want to read till the end: I can not positively vote on the concept as it does not show more pros than cons and the work needed to implement the pros, outreaches the benefit IMHO.
For those who are interested in my thoughts, read on...
Comments on the Blueprint
One statement: We lack a proper definition what we understand as "long term support".
Currently it was handled in a non-deterministic way of "suddenly" stopping merging patches to an LTS branch, declaring it the state "important bugfixes only".
Unfortunately the importance of a bugfix is only clear in one context, security. In any other case, importance is a very subjective assessment.
The reporter considers a bug a highly important, the release manager tries to reduce work load and classifies close to no bug as important.
In the end we have unhappy reporters, who took the time to report a problem, but got wiped away.
So we should clearly define what LTS actually comprises and to which extend we really provide support. The situation described above is the most unsatisfactory.
We should specify a fixed scheme when new bugfix releases (it is not clear to me whether these are planned and part of LTS or not, but I assume they are) are released.
Be it every second Tuesday or every first Wednesday a month, I don't care.
But the process needs to be much more predictable. (Personally I'm in favour of more smaller updates, especially with the automatic updates promised.)
Regarding the adoption rate of non-LTS releases I'm with Michael Stucki  and I actually doubt that we will get more feedback.
Firstly, we would not be able to handle more feedback at all, unless there's a bunch of highly motivated contributors coming around.
Secondly, considering the current adoption of even LTS versions, major users (which actually use a wide set of features) start to
really adopt new versions after the release of the .1 bugfix release earliest.
What feedback do we want? I actually don't want any feedback on an LTS release (except minor bug reports), I want feedback *before* the release of the LTS version.
Since it is "allowed" to skip one LTS, I expect no change to the amount and the timeliness of feedback from agencies, which rely on LTS only.
They will start working with "recent" versions right before the next applicable LTS is released, that is once every 3 years.
Allowing to skip one LTS.
More information about the TYPO3-team-core