git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.4.x and 2.6.x ... next steps


Going to largely ignore most other input on this thread, beyond the underlying proposals to branch 2.5.x and move to RTC...

On Wed, Sep 12, 2018, 03:20 Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx> wrote:
In my estimation, cleaning up trunk (or a copy of it) via RTC will take forever, at least.

And while that continues, any bugfix can only be done in trunk. We then need 2(!) RTC proposals and votes per fix if it affects 2.4.x. (Which, until 2.6 is out and gets adopted, will be the case almost all of the time.)

We do not even find enough people to look at the proposals for 2.4.x. It's easier to find people outside the project to test fixes in their production systems.

Short: I  do not believe this can work.

I completely agree.

If we pause to consider how we got to http2 already, it was because of Stefan's massive efforts *in CTR mode*. Would this have been a reasonable project to launch in RTC? IMO, no.

If we trust our committers, CTR will let us make far more progress in far less time. Note that all major proposals must be taken to the dev list anyways.

Note that RTC fails to intercept as many bugs as it catches, as easily observed during the 2.4.x generation, but at a very large cost in terms of development feedback loop timing.

If we do not trust our committers we have a much different issue that RTC does not address.

2.5.x are entirely alpha/beta releases, nobody will flinch at a regression or bug.