Time for httpd 2.6.x?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Time for httpd 2.6.x?

Luca Toscano
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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Luca Toscano
Not even a comment? :)

Luca

Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Mario Brandt-2
+1

Luca Toscano <[hidden email]> 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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Rainer Jung-3
In reply to this post by Luca Toscano
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
> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Marion & Christophe JAILLET
In reply to this post by Luca Toscano
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
> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Stefan Eissing
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 <[hidden email]>:
>
> 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
>> <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Luca Toscano
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
<[hidden email]> 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 <[hidden email]>:
> >
> > 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
> >> <[hidden email]> 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
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Rich Bowen
In reply to this post by Luca Toscano
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Jim Jagielski
In reply to this post by Luca Toscano
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 <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>>> <[hidden email]> 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
>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Yann Ylavic
In reply to this post by Stefan Eissing
On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Graham Leggett
In reply to this post by Jim Jagielski
On 24 Oct 2019, at 14:14, Jim Jagielski <[hidden email]> 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



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Jim Jagielski


> On Oct 25, 2019, at 6:59 AM, Graham Leggett <[hidden email]> wrote:
>
> On 24 Oct 2019, at 14:14, Jim Jagielski <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Yann Ylavic
On Fri, Oct 25, 2019 at 1:58 PM Jim Jagielski <[hidden email]> wrote:
>
> I'm fine w/ whatever we all decide.

+1
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Luca Toscano
In reply to this post by Yann Ylavic
Hi everybody,

Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Eric Covener
On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano <[hidden email]> wrote:

>
> Hi everybody,
>
> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
> <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Jim Jagielski


On Oct 29, 2019, at 9:36 AM, Eric Covener <[hidden email]> wrote:

On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano <[hidden email]> wrote:

Hi everybody,

Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Graham Leggett
On 29 Oct 2019, at 15:51, Jim Jagielski <[hidden email]> 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



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Luca Toscano
Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
<[hidden email]> ha scritto:

>
> On 29 Oct 2019, at 15:51, Jim Jagielski <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Jim Jagielski


On Nov 1, 2019, at 11:59 AM, Luca Toscano <[hidden email]> wrote:

Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
<[hidden email]> ha scritto:

On 29 Oct 2019, at 15:51, Jim Jagielski <[hidden email]> 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...

Reply | Threaded
Open this post in threaded view
|

Re: Time for httpd 2.6.x?

Luca Toscano
Il giorno dom 3 nov 2019 alle ore 18:52 Jim Jagielski
<[hidden email]> ha scritto:

>
>
>
> On Nov 1, 2019, at 11:59 AM, Luca Toscano <[hidden email]> wrote:
>
> Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
> <[hidden email]> ha scritto:
>
>
> On 29 Oct 2019, at 15:51, Jim Jagielski <[hidden email]> 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
12