You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2012/07/11 18:25:53 UTC
mpm-event-optimization
About 4 months ago we moved Paul's event optimization stuff
to its own branch, and since then no work as been done on it
at all...
I'd like for us to consider putting it back into trunk, so we
can work out the bugs and issues and getting it up to snuff.
This is in conjunction with my effort to reboot 'simple' (which
I've been working on externally)...
Re: mpm-event-optimization
Posted by Jim Jagielski <ji...@jaguNET.com>.
Sometimes creating, or at least vocalizing, a "plan" is enough to
encourage people to kick-up the activity levels to push out a
release that has more than what's been expected ;)
On Jul 16, 2012, at 1:38 PM, Stefan Fritsch wrote:
> On Monday 16 July 2012, Jim Jagielski wrote:
>> On Jul 13, 2012, at 3:57 PM, Stefan Fritsch wrote:
>>> On Thursday 12 July 2012, Jim Jagielski wrote:
>>>> To be clear, yes, the intent was to ensure that all patches
>>>> from trunk got into 2.4 before we re-merge. My expectation is
>>>> that the event optimizations will eventually find their way
>>>> into 2.4.x (and not be part of 2.6.x) and so getting them back
>>>> into trunk allows people to work them. Except for main
>>>> branches, most side-branches just don't get worked.
>>>>
>>>> So my plan is:
>>>> 1. We push all trunk event improvements into 2.4.x
>>>> 2. We release 2.4.3
>>>> 3. We re-merge the event optims back to trunk.
>>>
>>> FWIW, I would prefer not to delay 2.4.3 for that.
>>
>> Delay 2.4.3 for what?
>
> Waiting for all mpm_event fixes to be reviewed. But with the current
> increase of activity, maybe there won't be any delay.
>
Re: mpm-event-optimization
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 16 July 2012, Jim Jagielski wrote:
> On Jul 13, 2012, at 3:57 PM, Stefan Fritsch wrote:
> > On Thursday 12 July 2012, Jim Jagielski wrote:
> >> To be clear, yes, the intent was to ensure that all patches
> >> from trunk got into 2.4 before we re-merge. My expectation is
> >> that the event optimizations will eventually find their way
> >> into 2.4.x (and not be part of 2.6.x) and so getting them back
> >> into trunk allows people to work them. Except for main
> >> branches, most side-branches just don't get worked.
> >>
> >> So my plan is:
> >> 1. We push all trunk event improvements into 2.4.x
> >> 2. We release 2.4.3
> >> 3. We re-merge the event optims back to trunk.
> >
> > FWIW, I would prefer not to delay 2.4.3 for that.
>
> Delay 2.4.3 for what?
Waiting for all mpm_event fixes to be reviewed. But with the current
increase of activity, maybe there won't be any delay.
Re: mpm-event-optimization
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 13, 2012, at 3:57 PM, Stefan Fritsch wrote:
> On Thursday 12 July 2012, Jim Jagielski wrote:
>> To be clear, yes, the intent was to ensure that all patches
>> from trunk got into 2.4 before we re-merge. My expectation is
>> that the event optimizations will eventually find their way
>> into 2.4.x (and not be part of 2.6.x) and so getting them back
>> into trunk allows people to work them. Except for main
>> branches, most side-branches just don't get worked.
>>
>> So my plan is:
>>
>> 1. We push all trunk event improvements into 2.4.x
>> 2. We release 2.4.3
>> 3. We re-merge the event optims back to trunk.
>
> FWIW, I would prefer not to delay 2.4.3 for that.
>
Delay 2.4.3 for what?
Re: mpm-event-optimization
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 12 July 2012, Jim Jagielski wrote:
> To be clear, yes, the intent was to ensure that all patches
> from trunk got into 2.4 before we re-merge. My expectation is
> that the event optimizations will eventually find their way
> into 2.4.x (and not be part of 2.6.x) and so getting them back
> into trunk allows people to work them. Except for main
> branches, most side-branches just don't get worked.
>
> So my plan is:
>
> 1. We push all trunk event improvements into 2.4.x
> 2. We release 2.4.3
> 3. We re-merge the event optims back to trunk.
FWIW, I would prefer not to delay 2.4.3 for that.
Re: mpm-event-optimization
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 11, 2012, at 1:53 PM, Stefan Fritsch wrote:
> On Wed, 11 Jul 2012, Jim Jagielski wrote:
>> About 4 months ago we moved Paul's event optimization stuff
>> to its own branch, and since then no work as been done on it
>> at all...
>>
>> I'd like for us to consider putting it back into trunk, so we
>> can work out the bugs and issues and getting it up to snuff.
>> This is in conjunction with my effort to reboot 'simple' (which
>> I've been working on externally)...
>
> But there have been quite a few bugfixes in trunk's mpm event since the branch. We should get these into 2.4 first before we do radical changes in trunk. There are also the patches from http://mail-archives.apache.org/mod_mbox/httpd-dev/201203.mbox/%3C201203022118.08839.sf%40sfritsch.de%3E but I didn't have enough cycles to finish and commit those, yet.
>
> Of course, this should not prevent anyone from committing improvements to the mpm-event-optimization branch.
>
To be clear, yes, the intent was to ensure that all patches
from trunk got into 2.4 before we re-merge. My expectation is
that the event optimizations will eventually find their way
into 2.4.x (and not be part of 2.6.x) and so getting them back
into trunk allows people to work them. Except for main
branches, most side-branches just don't get worked.
So my plan is:
1. We push all trunk event improvements into 2.4.x
2. We release 2.4.3
3. We re-merge the event optims back to trunk.
Re: mpm-event-optimization
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wed, 11 Jul 2012, Jim Jagielski wrote:
> About 4 months ago we moved Paul's event optimization stuff
> to its own branch, and since then no work as been done on it
> at all...
>
> I'd like for us to consider putting it back into trunk, so we
> can work out the bugs and issues and getting it up to snuff.
> This is in conjunction with my effort to reboot 'simple' (which
> I've been working on externally)...
But there have been quite a few bugfixes in trunk's mpm event since the
branch. We should get these into 2.4 first before we do radical changes in
trunk. There are also the patches from
http://mail-archives.apache.org/mod_mbox/httpd-dev/201203.mbox/%3C201203022118.08839.sf%40sfritsch.de%3E
but I didn't have enough cycles to finish and commit those, yet.
Of course, this should not prevent anyone from committing improvements to
the mpm-event-optimization branch.