On 01/20/2017 09:37 PM, Graham Leggett wrote:
> On 20 Jan 2017, at 7:47 PM, David Zuelke <d...@heroku.com> wrote:
>
>> I'd actually like to question the whole practice of porting features back to
>> older branches. I think that's the core reason why trunk is in total
>> disarray, and why no substantial releases have been made. There is just no
>> reason for anyone to push forward the state of 2.6 or even 3.0 if you can
>> just backport whatever you want.
>
> The reason this is bad is because Apache httpd comes with a module ecosystem
> - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that
> the ABI can break, and therefore all modules that depend on that version must
> be recompiled. This includes modules that are closed source and offered by a
> proprietary vendor, or are open source but provided in binary form by a
> distro.
I share this concern. If you put new features only in 2.current+1 then most
users have to wait for years until they can
use them due to the lack of support by third parties for 2.current+1. You might
argue if you speed up with increasing
x in 2.x and faster deprecating older 2.y you would solve that issue and 3rd
parties would simply speed up their model.
But I don't think so. I think and some actually do they would create there own
fork of 2.x and only supply the
modules for that fork leaving you locked in a closed vendor solution with
"features" added by them. Nothing I am keen on.
>
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if
> that feature does not break existing behaviour in any way. This is entirely
> reasonable, convenient, and what we’ve been doing since the 1990s.
>
>> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start
>> the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right
>> now? It's already "stable". It doesn't need more features that suddenly
>> change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of
>> what users are looking for).
>>
>> That's how PHP does it now... new features can go into x.y.0, and once that
>> is released (actually, once it's in beta stage), anything that is not a
>> small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal
>> because these releases land every year now, like clockwork.
>
> So you have to wait a year for new features to see a release? Definitely not
> keen on that.
>
>> I have said this in the other thread that hasn't gotten much traction ("A
>> new release process?"). The PHP team was in the exact same spot as HTTPD a
>> few years ago. No substantial progress, stale branches, no light at the end
>> of the tunnel, and a lot of fighting.
>
> We’ve had a significant amount of progress, a trunk that is so stable that
> almost all fixes and features can be backported to v2.4 without any fear of
> incompatibility, and the “fighting” is limited to very few individuals.
>
> We’re not broken, we don’t need fixing.
I wouldn't say we don't need fixing. But IMHO we don't need fixing in the way
proposed.
We need to work on getting a better testing in place. Honestly I don't have an
answer at hand how to do this,
but from my personal point of view I think that our perl framework is sometimes
a little hard to work with
(might be my own limitation) and we lack the possibility of doing internal API
tests more easily (I know that you can do
certain tests by creating C test modules in the perl framework, but that should
be easier).
That would increase stability of our release and avoid regressions better.
But the cause for introducing regressions isn't because a feature is ported
back, we have regressions as well on bug
fixes, the cause is in most cases the complexity of the code ported back or
better the complexity of the code region
touched.
And by complexity in this case I don't mean necessarily the number of code
lines ported back. A one line change can
cause ugly regressions if it messes with a complex subject.
But maybe that tells us that we need to restructure these areas of code to make
them easier to understand and thus
more stable to changes.
Honestly the stuff above sounds like a lot of thankless work and not sexy and
that maybe the reason why we lack progress
here.
Regards
Rüdiger
