You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Luca Toscano <to...@gmail.com> on 2019/10/13 18:58:46 UTC
Time for httpd 2.6.x?
Hi everybody,
in trunk's STATUS there are a lot of suggestions about things to
improve/change for 2.6.x. There have been discussions during the past
couple of years about how/when/if to create a 2.6 release branch, but
for a lot of reasons we didn't do any progress. Would it be something
to consider for the next months?
Luca
Re: Time for httpd 2.6.x?
Posted by Rainer Jung <ra...@kippdata.de>.
I guess you would want to take trunk as a starting point?
We would probably start with releasing (more) 2.5 alphas/betas. Maybe we
can defer branching to the point, where we aim at the first 2.6.0 GA. At
least I am not aware of a pressing need to do more breaking changes in
trunk right now (and before we might reach 2.6.0). Just want to avoid
that we branch unnecessarily early and have to do more backports than
needed.
Anyways: I am +1 for aiming at 2.6.0 and when to branch is more of a
procedural optimization.
Regards,
Rainer
Am 23.10.2019 um 08:28 schrieb Luca Toscano:
> Not even a comment? :)
>
> Luca
>
> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
> <to...@gmail.com> ha scritto:
>>
>> Hi everybody,
>>
>> in trunk's STATUS there are a lot of suggestions about things to
>> improve/change for 2.6.x. There have been discussions during the past
>> couple of years about how/when/if to create a 2.6 release branch, but
>> for a lot of reasons we didn't do any progress. Would it be something
>> to consider for the next months?
>>
>> Luca
Re: Time for httpd 2.6.x?
Posted by Luca Toscano <to...@gmail.com>.
Il giorno dom 3 nov 2019 alle ore 18:52 Jim Jagielski
<ji...@jagunet.com> ha scritto:
>
>
>
> On Nov 1, 2019, at 11:59 AM, Luca Toscano <to...@gmail.com> wrote:
>
> Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
> <mi...@sharp.fm> ha scritto:
>
>
> On 29 Oct 2019, at 15:51, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk?
>
>
> As I recall from v2.4, we branched from trunk, and then we removed anything we deemed “not ready” from the branch. “not ready” had reasonably simple criteria, like “not documented yet”.
>
> So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone.
>
>
> +1.
>
> Let’s get a 2.5 out there, and let people bash on it.
>
>
> If this was the previous way of doing things and it worked, +1 as
> well. Is there anybody willing to start this process?
>
>
> I don't want to start any process w/o more consensus about going forward... In particular, branching 2.5.x from trunk...
Some steps would need to be taken before creating the new branch
(basically 1. -> 5. in Yann's list), this is why I am advocating to
have one or more people with clear ideas that start the process. It
seems that overall nobody strongly disagrees with branching off trunk
(after tidying it up as necessary), but if needed we can have a quick
vote about a procedure to follow and then start the work. My 2c :)
Luca
Re: Time for httpd 2.6.x?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 1, 2019, at 11:59 AM, Luca Toscano <to...@gmail.com> wrote:
>
> Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
> <minfrin@sharp.fm <ma...@sharp.fm>> ha scritto:
>>
>> On 29 Oct 2019, at 15:51, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>> My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk?
>>
>> As I recall from v2.4, we branched from trunk, and then we removed anything we deemed “not ready” from the branch. “not ready” had reasonably simple criteria, like “not documented yet”.
>>
>>> So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone.
>>
>> +1.
>>
>> Let’s get a 2.5 out there, and let people bash on it.
>
> If this was the previous way of doing things and it worked, +1 as
> well. Is there anybody willing to start this process?
I don't want to start any process w/o more consensus about going forward... In particular, branching 2.5.x from trunk...
Re: Time for httpd 2.6.x?
Posted by Luca Toscano <to...@gmail.com>.
Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
<mi...@sharp.fm> ha scritto:
>
> On 29 Oct 2019, at 15:51, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> > My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk?
>
> As I recall from v2.4, we branched from trunk, and then we removed anything we deemed “not ready” from the branch. “not ready” had reasonably simple criteria, like “not documented yet”.
>
> > So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone.
>
> +1.
>
> Let’s get a 2.5 out there, and let people bash on it.
If this was the previous way of doing things and it worked, +1 as
well. Is there anybody willing to start this process?
Luca
Re: Time for httpd 2.6.x?
Posted by Graham Leggett <mi...@sharp.fm>.
On 29 Oct 2019, at 15:51, Jim Jagielski <ji...@jaguNET.com> wrote:
> My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk?
As I recall from v2.4, we branched from trunk, and then we removed anything we deemed “not ready” from the branch. “not ready” had reasonably simple criteria, like “not documented yet”.
> So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone.
+1.
Let’s get a 2.5 out there, and let people bash on it.
Regards,
Graham
—
Re: Time for httpd 2.6.x?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 29, 2019, at 9:36 AM, Eric Covener <co...@gmail.com> wrote:
>
> On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano <toscano.luca@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi everybody,
>>
>> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
>> <yl...@gmail.com> ha scritto:
>>>
>>> So how about:
>>> 0. github workflow? meanwhile...
>>> 1. compare trunk/2.4.x (inventory)
>>> 2. discuss unused/deprecated in trunk to cleanup
>>> 3. address STALLED entries in trunk if it's not for compatibily reasons
>>> 4. do API/ABI breaking changes in trunk
>>> 5. improve trunk w/ things we want in 2.6.x (the real part!)
>>> 6. trunk => 2.6.x
>>> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
>>> 8. 2.6.alpha/beta/gamma/rc/whatever
>>> 9. fix in trunk and backport to 2.6.x
>>> 10. if not good enough goto 8.
>>> 11. 2.6.0
>>> 12+ usual release cycle
>>
>> The above proposal from Yann seems to be something that could work for
>> everybody as far as I can tell, what do you think? Do we need an
>> explicit vote thread?
>
> Nit: Not using 2.5.x is a departure from convention.
>
> I don't think a wholesale vote is needed for #1-5. I am skeptical
> there is interest/velocity in getting past #2.
> By the time we're at #8, I would say a vote is warranted as an
> additional branch has a cost.
My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk?
So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone.
Just my 2c
Re: Time for httpd 2.6.x?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano <to...@gmail.com> wrote:
>
> Hi everybody,
>
> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
> <yl...@gmail.com> ha scritto:
> >
> > So how about:
> > 0. github workflow? meanwhile...
> > 1. compare trunk/2.4.x (inventory)
> > 2. discuss unused/deprecated in trunk to cleanup
> > 3. address STALLED entries in trunk if it's not for compatibily reasons
> > 4. do API/ABI breaking changes in trunk
> > 5. improve trunk w/ things we want in 2.6.x (the real part!)
> > 6. trunk => 2.6.x
> > 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
> > 8. 2.6.alpha/beta/gamma/rc/whatever
> > 9. fix in trunk and backport to 2.6.x
> > 10. if not good enough goto 8.
> > 11. 2.6.0
> > 12+ usual release cycle
>
> The above proposal from Yann seems to be something that could work for
> everybody as far as I can tell, what do you think? Do we need an
> explicit vote thread?
Nit: Not using 2.5.x is a departure from convention.
I don't think a wholesale vote is needed for #1-5. I am skeptical
there is interest/velocity in getting past #2.
By the time we're at #8, I would say a vote is warranted as an
additional branch has a cost.
Re: Time for httpd 2.6.x?
Posted by Luca Toscano <to...@gmail.com>.
Hi everybody,
Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
<yl...@gmail.com> ha scritto:
>
> So how about:
> 0. github workflow? meanwhile...
> 1. compare trunk/2.4.x (inventory)
> 2. discuss unused/deprecated in trunk to cleanup
> 3. address STALLED entries in trunk if it's not for compatibily reasons
> 4. do API/ABI breaking changes in trunk
> 5. improve trunk w/ things we want in 2.6.x (the real part!)
> 6. trunk => 2.6.x
> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
> 8. 2.6.alpha/beta/gamma/rc/whatever
> 9. fix in trunk and backport to 2.6.x
> 10. if not good enough goto 8.
> 11. 2.6.0
> 12+ usual release cycle
The above proposal from Yann seems to be something that could work for
everybody as far as I can tell, what do you think? Do we need an
explicit vote thread?
Luca
Re: Time for httpd 2.6.x?
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Nov 04, 2019 at 09:35:09PM +0100, Ruediger Pluem wrote:
> On 10/25/2019 12:52 PM, Yann Ylavic wrote:
> > My feeling is that it's easier to start from trunk, no strong feeling
> > (an intuitive one).
> >
> > So how about:
> > 0. github workflow? meanwhile...
> > 1. compare trunk/2.4.x (inventory)
> > 2. discuss unused/deprecated in trunk to cleanup
> > 3. address STALLED entries in trunk if it's not for compatibily reasons
> > 4. do API/ABI breaking changes in trunk
> > 5. improve trunk w/ things we want in 2.6.x (the real part!)
> > 6. trunk => 2.6.x
> > 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
> > 8. 2.6.alpha/beta/gamma/rc/whatever
> > 9. fix in trunk and backport to 2.6.x
> > 10. if not good enough goto 8.
> > 11. 2.6.0
> > 12+ usual release cycle
> > ?
> >
> > If in 1. we find that 2.4.x => 2.6.x is easier/better, well just
> > replace 2. with that and drop 6. and 7.
>
> +1 to the above, with a preference to branch from trunk if possible.
+1 also and a strong preference to branch from trunk.
Regards, Joe
Re: Time for httpd 2.6.x?
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/25/2019 12:52 PM, Yann Ylavic wrote:
> On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>> As I said in the past, my idea would be to:
>> - trunk -> trunk-old,
>> - copy 2.4.x -> trunk
>> - any feature to bring from trunk-old to the new trunk needs a champion, e.g. someone who does the work (porting and test cases)
>
> I'm not sure, possibly it would be easier to remove/restore from/to
> trunk than backport to 2.6.x. I think most things are in pretty good
> shape in trunk, core things at least.
> If we were to merge the missing/interesting bits in a
> 2.6.x-copy-of-2.4.x, it could be a mess to find all the commits in
> trunk for each feature.
> (Say something /me did, as you very well know it's very likely to be
> spread over multiple commits and back and forth in time :) )
>
>>
>> To some, that looks like we do not honour past work from people (that was one of the arguments brought forward last time).
>
> If, due to the above difficulty for finding all the relevant bits to
> backport, it ends up being large replacement of code (nay whole files)
> with no real merge, I think that's a point though.
> Basing 2.6.x off trunk would preserve history on the things we want to
> keep and maintain, and possibly would be easier to start with (let's
> discuss that!), so best of both worlds?
>
>> But it is not only about honour of devs, but also about the sweat and tears of the maintainers during 2.6.x releases. If a feature does not find someone to merge from one branch to another, how could we support this feature in a release?
>
> Agreed.
>
>> What do the 5-6 people who handle 99% of all PRs think about this?
>
> My feeling is that it's easier to start from trunk, no strong feeling
> (an intuitive one).
>
> So how about:
> 0. github workflow? meanwhile...
> 1. compare trunk/2.4.x (inventory)
> 2. discuss unused/deprecated in trunk to cleanup
> 3. address STALLED entries in trunk if it's not for compatibily reasons
> 4. do API/ABI breaking changes in trunk
> 5. improve trunk w/ things we want in 2.6.x (the real part!)
> 6. trunk => 2.6.x
> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
> 8. 2.6.alpha/beta/gamma/rc/whatever
> 9. fix in trunk and backport to 2.6.x
> 10. if not good enough goto 8.
> 11. 2.6.0
> 12+ usual release cycle
> ?
>
> If in 1. we find that 2.4.x => 2.6.x is easier/better, well just
> replace 2. with that and drop 6. and 7.
+1 to the above, with a preference to branch from trunk if possible.
Regards
Rüdiger
Re: Time for httpd 2.6.x?
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing
<st...@greenbytes.de> wrote:
>
> As I said in the past, my idea would be to:
> - trunk -> trunk-old,
> - copy 2.4.x -> trunk
> - any feature to bring from trunk-old to the new trunk needs a champion, e.g. someone who does the work (porting and test cases)
I'm not sure, possibly it would be easier to remove/restore from/to
trunk than backport to 2.6.x. I think most things are in pretty good
shape in trunk, core things at least.
If we were to merge the missing/interesting bits in a
2.6.x-copy-of-2.4.x, it could be a mess to find all the commits in
trunk for each feature.
(Say something /me did, as you very well know it's very likely to be
spread over multiple commits and back and forth in time :) )
>
> To some, that looks like we do not honour past work from people (that was one of the arguments brought forward last time).
If, due to the above difficulty for finding all the relevant bits to
backport, it ends up being large replacement of code (nay whole files)
with no real merge, I think that's a point though.
Basing 2.6.x off trunk would preserve history on the things we want to
keep and maintain, and possibly would be easier to start with (let's
discuss that!), so best of both worlds?
> But it is not only about honour of devs, but also about the sweat and tears of the maintainers during 2.6.x releases. If a feature does not find someone to merge from one branch to another, how could we support this feature in a release?
Agreed.
> What do the 5-6 people who handle 99% of all PRs think about this?
My feeling is that it's easier to start from trunk, no strong feeling
(an intuitive one).
So how about:
0. github workflow? meanwhile...
1. compare trunk/2.4.x (inventory)
2. discuss unused/deprecated in trunk to cleanup
3. address STALLED entries in trunk if it's not for compatibily reasons
4. do API/ABI breaking changes in trunk
5. improve trunk w/ things we want in 2.6.x (the real part!)
6. trunk => 2.6.x
7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
8. 2.6.alpha/beta/gamma/rc/whatever
9. fix in trunk and backport to 2.6.x
10. if not good enough goto 8.
11. 2.6.0
12+ usual release cycle
?
If in 1. we find that 2.4.x => 2.6.x is easier/better, well just
replace 2. with that and drop 6. and 7.
Re: Time for httpd 2.6.x?
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Oct 25, 2019 at 1:58 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
> I'm fine w/ whatever we all decide.
+1
Re: Time for httpd 2.6.x?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 25, 2019, at 6:59 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 24 Oct 2019, at 14:14, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from trunk have maintained the 2.4.x ABI backwards compatibility.
>>
>> So I would propose that if we do the below, which I am fine w/ BTW, that the 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI changes.
>>
>> Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, untested and wonky stuff that I would be somewhat worried about releasing... So that's why I like basing 2.6.x off of 2.4.x rather than trunk.
>
> I would rather we stick to our existing practise of branching off trunk, then evaluating what we want in 2.6 and explicitly removing what we don't want.
>
> This is what we did when 2.4 came out, and it worked well.
>
I'm fine w/ whatever we all decide.
Re: Time for httpd 2.6.x?
Posted by Graham Leggett <mi...@sharp.fm>.
On 24 Oct 2019, at 14:14, Jim Jagielski <ji...@jaguNET.com> wrote:
> Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from trunk have maintained the 2.4.x ABI backwards compatibility.
>
> So I would propose that if we do the below, which I am fine w/ BTW, that the 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI changes.
>
> Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, untested and wonky stuff that I would be somewhat worried about releasing... So that's why I like basing 2.6.x off of 2.4.x rather than trunk.
I would rather we stick to our existing practise of branching off trunk, then evaluating what we want in 2.6 and explicitly removing what we don't want.
This is what we did when 2.4 came out, and it worked well.
> FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't see the attraction or need to revisit it.
I don’t want us reinventing any wheels.
The goal here is to get v2.6 out the door, not reinvent our long established processes from scratch, particularly when the work on the processes sucks time out of work on httpd’s codebase itself.
Regards,
Graham
—
Re: Time for httpd 2.6.x?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from trunk have maintained the 2.4.x ABI backwards compatibility.
So I would propose that if we do the below, which I am fine w/ BTW, that the 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI changes.
Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, untested and wonky stuff that I would be somewhat worried about releasing... So that's why I like basing 2.6.x off of 2.4.x rather than trunk.
FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't see the attraction or need to revisit it.
> On Oct 23, 2019, at 9:02 AM, Luca Toscano <to...@gmail.com> wrote:
>
> Thanks a lot for all the answers, waiting for more people to chime in!
> What I personally like (at a very high level):
>
> 1) create a 2.6.x branch from 2.4.x and start backporting commits from
> trunk (with votes etc..), up to the point that we feel 2.6.0 GA is
> ready, then follow the regular release process. Christophe's tool for
> visualizing diffs between trunk and 2.4.x could be really handy and
> helpful.
> 2) Leave trunk as it is, and consider fixing the issues currently outstanding.
> 3) Use STATUS to decide what modules/code is to be deprecated.
> 4) Decide when 2.4.x should be considered EOLed in the future.
> 5) Decide how/when to bump minor versions in the future, so anybody
> adding/contributing code to httpd will have a very high level
> expectation of when some code can be released. IIRC during the past
> threads it was mentioned that a lot of people contributed with good
> code still sitting in trunk due to backporting issues to 2.4.x
> (breaking ABI etc..). It is not really fair and it surely drives away
> contributors that aim to work on major changes to httpd.
>
> Luca
>
>
> Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing
> <st...@greenbytes.de> ha scritto:
>>
>> Hi All,
>>
>> I agree with CJ here.
>>
>> As I said in the past, my idea would be to:
>> - trunk -> trunk-old,
>> - copy 2.4.x -> trunk
>> - any feature to bring from trunk-old to the new trunk needs a champion, e.g. someone who does the work (porting and test cases)
>>
>> To some, that looks like we do not honour past work from people (that was one of the arguments brought forward last time). But it is not only about honour of devs, but also about the sweat and tears of the maintainers during 2.6.x releases. If a feature does not find someone to merge from one branch to another, how could we support this feature in a release? What do the 5-6 people who handle 99% of all PRs think about this?
>>
>> As to the list of things to abandon from 2.4.x, we could handle those like the backport voting in STATUS.
>>
>> Cheers, Stefan
>>
>>> Am 23.10.2019 um 10:18 schrieb Christophe JAILLET <ch...@wanadoo.fr>:
>>>
>>> Hi Luco,
>>>
>>> I've nothing against a 2.6.x branch.
>>> My only fear is things in trunk that is incomplete and or not enough reviewed.
>>> In other words, our backport mechanism with at least 3 votes is safeguard for me.
>>>
>>> My personal point of view is that 2.6.x should be built with backports from trunk, just as done actually for 2.4.x.
>>> But I know it is not the point of view of many others that consider that what is in trunk is (or should be) functional, reviewed and tested.
>>> Anyway, even if some things are less reviewed, alpha, beta and GA are there to give others the opportunity to test and report issues, so I is maybe not that bad to go this way, after all.
>>>
>>>
>>> If we want to go on the 2.6 way, maybe we could open some discussion:
>>>
>>> - should we deprecate or remove some 2.4.x functionalities or modules? (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low activity, ...)
>>>
>>> - should we remove things in trunk that are incomplete or lack consensus: (this illustrate my fears above)
>>> - mod_serf and libserf support? : serf project looks mostly inactive nowadays, mod_sef have no documentation
>>> - pcre2 support? (comments in commits or code say that it is incomplete and that there is performance or memory management issues)
>>> - things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
>>>
>>> - should we increase the APR minimum version and cleanup existing code accordingly? (i.e. switch from some ap_ to apr_ functions)
>>>
>>> - we could start to write a "new_features_2_6.html" in order to list new goodies and incompatibilities and changed behavior
>>>
>>>
>>> just my 2c.
>>>
>>> CJ
>>>
>>> Le 23/10/2019 à 08:28, Luca Toscano a écrit :
>>>> Not even a comment? :)
>>>>
>>>> Luca
>>>>
>>>> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
>>>> <to...@gmail.com> ha scritto:
>>>>> Hi everybody,
>>>>>
>>>>> in trunk's STATUS there are a lot of suggestions about things to
>>>>> improve/change for 2.6.x. There have been discussions during the past
>>>>> couple of years about how/when/if to create a 2.6 release branch, but
>>>>> for a lot of reasons we didn't do any progress. Would it be something
>>>>> to consider for the next months?
>>>>>
>>>>> Luca
>>>
>>>
>>
Re: Time for httpd 2.6.x?
Posted by Luca Toscano <to...@gmail.com>.
Thanks a lot for all the answers, waiting for more people to chime in!
What I personally like (at a very high level):
1) create a 2.6.x branch from 2.4.x and start backporting commits from
trunk (with votes etc..), up to the point that we feel 2.6.0 GA is
ready, then follow the regular release process. Christophe's tool for
visualizing diffs between trunk and 2.4.x could be really handy and
helpful.
2) Leave trunk as it is, and consider fixing the issues currently outstanding.
3) Use STATUS to decide what modules/code is to be deprecated.
4) Decide when 2.4.x should be considered EOLed in the future.
5) Decide how/when to bump minor versions in the future, so anybody
adding/contributing code to httpd will have a very high level
expectation of when some code can be released. IIRC during the past
threads it was mentioned that a lot of people contributed with good
code still sitting in trunk due to backporting issues to 2.4.x
(breaking ABI etc..). It is not really fair and it surely drives away
contributors that aim to work on major changes to httpd.
Luca
Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing
<st...@greenbytes.de> ha scritto:
>
> Hi All,
>
> I agree with CJ here.
>
> As I said in the past, my idea would be to:
> - trunk -> trunk-old,
> - copy 2.4.x -> trunk
> - any feature to bring from trunk-old to the new trunk needs a champion, e.g. someone who does the work (porting and test cases)
>
> To some, that looks like we do not honour past work from people (that was one of the arguments brought forward last time). But it is not only about honour of devs, but also about the sweat and tears of the maintainers during 2.6.x releases. If a feature does not find someone to merge from one branch to another, how could we support this feature in a release? What do the 5-6 people who handle 99% of all PRs think about this?
>
> As to the list of things to abandon from 2.4.x, we could handle those like the backport voting in STATUS.
>
> Cheers, Stefan
>
> > Am 23.10.2019 um 10:18 schrieb Christophe JAILLET <ch...@wanadoo.fr>:
> >
> > Hi Luco,
> >
> > I've nothing against a 2.6.x branch.
> > My only fear is things in trunk that is incomplete and or not enough reviewed.
> > In other words, our backport mechanism with at least 3 votes is safeguard for me.
> >
> > My personal point of view is that 2.6.x should be built with backports from trunk, just as done actually for 2.4.x.
> > But I know it is not the point of view of many others that consider that what is in trunk is (or should be) functional, reviewed and tested.
> > Anyway, even if some things are less reviewed, alpha, beta and GA are there to give others the opportunity to test and report issues, so I is maybe not that bad to go this way, after all.
> >
> >
> > If we want to go on the 2.6 way, maybe we could open some discussion:
> >
> > - should we deprecate or remove some 2.4.x functionalities or modules? (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low activity, ...)
> >
> > - should we remove things in trunk that are incomplete or lack consensus: (this illustrate my fears above)
> > - mod_serf and libserf support? : serf project looks mostly inactive nowadays, mod_sef have no documentation
> > - pcre2 support? (comments in commits or code say that it is incomplete and that there is performance or memory management issues)
> > - things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
> >
> > - should we increase the APR minimum version and cleanup existing code accordingly? (i.e. switch from some ap_ to apr_ functions)
> >
> > - we could start to write a "new_features_2_6.html" in order to list new goodies and incompatibilities and changed behavior
> >
> >
> > just my 2c.
> >
> > CJ
> >
> > Le 23/10/2019 à 08:28, Luca Toscano a écrit :
> >> Not even a comment? :)
> >>
> >> Luca
> >>
> >> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
> >> <to...@gmail.com> ha scritto:
> >>> Hi everybody,
> >>>
> >>> in trunk's STATUS there are a lot of suggestions about things to
> >>> improve/change for 2.6.x. There have been discussions during the past
> >>> couple of years about how/when/if to create a 2.6 release branch, but
> >>> for a lot of reasons we didn't do any progress. Would it be something
> >>> to consider for the next months?
> >>>
> >>> Luca
> >
> >
>
Re: Time for httpd 2.6.x?
Posted by Stefan Eissing <st...@greenbytes.de>.
Hi All,
I agree with CJ here.
As I said in the past, my idea would be to:
- trunk -> trunk-old,
- copy 2.4.x -> trunk
- any feature to bring from trunk-old to the new trunk needs a champion, e.g. someone who does the work (porting and test cases)
To some, that looks like we do not honour past work from people (that was one of the arguments brought forward last time). But it is not only about honour of devs, but also about the sweat and tears of the maintainers during 2.6.x releases. If a feature does not find someone to merge from one branch to another, how could we support this feature in a release? What do the 5-6 people who handle 99% of all PRs think about this?
As to the list of things to abandon from 2.4.x, we could handle those like the backport voting in STATUS.
Cheers, Stefan
> Am 23.10.2019 um 10:18 schrieb Christophe JAILLET <ch...@wanadoo.fr>:
>
> Hi Luco,
>
> I've nothing against a 2.6.x branch.
> My only fear is things in trunk that is incomplete and or not enough reviewed.
> In other words, our backport mechanism with at least 3 votes is safeguard for me.
>
> My personal point of view is that 2.6.x should be built with backports from trunk, just as done actually for 2.4.x.
> But I know it is not the point of view of many others that consider that what is in trunk is (or should be) functional, reviewed and tested.
> Anyway, even if some things are less reviewed, alpha, beta and GA are there to give others the opportunity to test and report issues, so I is maybe not that bad to go this way, after all.
>
>
> If we want to go on the 2.6 way, maybe we could open some discussion:
>
> - should we deprecate or remove some 2.4.x functionalities or modules? (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low activity, ...)
>
> - should we remove things in trunk that are incomplete or lack consensus: (this illustrate my fears above)
> - mod_serf and libserf support? : serf project looks mostly inactive nowadays, mod_sef have no documentation
> - pcre2 support? (comments in commits or code say that it is incomplete and that there is performance or memory management issues)
> - things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
>
> - should we increase the APR minimum version and cleanup existing code accordingly? (i.e. switch from some ap_ to apr_ functions)
>
> - we could start to write a "new_features_2_6.html" in order to list new goodies and incompatibilities and changed behavior
>
>
> just my 2c.
>
> CJ
>
> Le 23/10/2019 à 08:28, Luca Toscano a écrit :
>> Not even a comment? :)
>>
>> Luca
>>
>> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
>> <to...@gmail.com> ha scritto:
>>> Hi everybody,
>>>
>>> in trunk's STATUS there are a lot of suggestions about things to
>>> improve/change for 2.6.x. There have been discussions during the past
>>> couple of years about how/when/if to create a 2.6 release branch, but
>>> for a lot of reasons we didn't do any progress. Would it be something
>>> to consider for the next months?
>>>
>>> Luca
>
>
Re: Time for httpd 2.6.x?
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Hi Luco,
I've nothing against a 2.6.x branch.
My only fear is things in trunk that is incomplete and or not enough
reviewed.
In other words, our backport mechanism with at least 3 votes is
safeguard for me.
My personal point of view is that 2.6.x should be built with backports
from trunk, just as done actually for 2.4.x.
But I know it is not the point of view of many others that consider that
what is in trunk is (or should be) functional, reviewed and tested.
Anyway, even if some things are less reviewed, alpha, beta and GA are
there to give others the opportunity to test and report issues, so I is
maybe not that bad to go this way, after all.
If we want to go on the 2.6 way, maybe we could open some discussion:
- should we deprecate or remove some 2.4.x functionalities or
modules? (mod_imagemap, mod_cern_meta, maybe NetWare support which has
really low activity, ...)
- should we remove things in trunk that are incomplete or lack
consensus: (this illustrate my fears above)
- mod_serf and libserf support? : serf project looks mostly
inactive nowadays, mod_sef have no documentation
- pcre2 support? (comments in commits or code say that it is
incomplete and that there is performance or memory management issues)
- things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
- should we increase the APR minimum version and cleanup existing
code accordingly? (i.e. switch from some ap_ to apr_ functions)
- we could start to write a "new_features_2_6.html" in order to list
new goodies and incompatibilities and changed behavior
just my 2c.
CJ
Le 23/10/2019 à 08:28, Luca Toscano a écrit :
> Not even a comment? :)
>
> Luca
>
> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
> <to...@gmail.com> ha scritto:
>> Hi everybody,
>>
>> in trunk's STATUS there are a lot of suggestions about things to
>> improve/change for 2.6.x. There have been discussions during the past
>> couple of years about how/when/if to create a 2.6 release branch, but
>> for a lot of reasons we didn't do any progress. Would it be something
>> to consider for the next months?
>>
>> Luca
Re: Time for httpd 2.6.x?
Posted by Mario Brandt <jb...@gmail.com>.
+1
Luca Toscano <to...@gmail.com> schrieb am Mi., 23. Okt. 2019, 08:29:
> Not even a comment? :)
>
> Luca
>
> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
> <to...@gmail.com> ha scritto:
> >
> > Hi everybody,
> >
> > in trunk's STATUS there are a lot of suggestions about things to
> > improve/change for 2.6.x. There have been discussions during the past
> > couple of years about how/when/if to create a 2.6 release branch, but
> > for a lot of reasons we didn't do any progress. Would it be something
> > to consider for the next months?
> >
> > Luca
>
Re: Time for httpd 2.6.x?
Posted by Luca Toscano <to...@gmail.com>.
Not even a comment? :)
Luca
Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
<to...@gmail.com> ha scritto:
>
> Hi everybody,
>
> in trunk's STATUS there are a lot of suggestions about things to
> improve/change for 2.6.x. There have been discussions during the past
> couple of years about how/when/if to create a 2.6 release branch, but
> for a lot of reasons we didn't do any progress. Would it be something
> to consider for the next months?
>
> Luca
Re: Time for httpd 2.6.x?
Posted by Rich Bowen <rb...@rcbowen.com>.
Disclaimer: I've been pretty much absentee for a while so take my opinions
with a grain of salt.
From a PR perspective, 7 years is a heck of a long time and it would be
great to remind people that httpd is in fact an actively developed project
doing exciting and modern things.
mod_md all by itself justifies a big splash - most of the world appear to
be still completely unaware of it and while I know version numbers mean
more (and sometimes less) than "yay new thing" it gives us an opportunity
to make a bigger splash.
Apachecon 2020 will be our 25th birthday, as has been mentioned. Having a
New Shiny to talk about on such an important year would be awesome.
Shosholoza,
Rich
On Sun, Oct 13, 2019, 20:59 Luca Toscano <to...@gmail.com> wrote:
> Hi everybody,
>
> in trunk's STATUS there are a lot of suggestions about things to
> improve/change for 2.6.x. There have been discussions during the past
> couple of years about how/when/if to create a 2.6 release branch, but
> for a lot of reasons we didn't do any progress. Would it be something
> to consider for the next months?
>
> Luca
>