Re: mpm-event-optimization
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
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
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
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
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.
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
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.
