That *will* affect the 2.2 uptake rate because our third parties will take a lot of time to get their modules 64-bit clean (if they do at all).
WHO CARES?!? That's on them. They can release bug fixes after bug fixes, or extend their list of tested/supported platforms as they get around to it. It's their problem.
No, but as we learned from 2.0, third-party modules have a direct impact on the uptake rate. So, making it harder for third-parties to port would make it much harder to see 2.2 in deployment.
As it stands, WE will be in THEIR WAY with incorrect code in apr and httpd. At that point - they cannot address the problems until we release the next version minor (2.4 or 3.0). How unfair is that?
2.0 has the same problem and I've yet to see any real complaints.
I don't want to see 2.2 be the 'end-all-be-all' - I want 2.2 to be a usable and incremental improvement over 2.0.
I still think this needs to be punted to 2.4. It's just *way* too big.
Way too big for you to handle? Ok. Not asking you to develop, test or even review.
Way too big for third-parties to handle easily.
We'll also have to fix up all of httpd to be 64-bit clean.
Not hard.
So say you without any code to back that statement up. We don't even know the extent of the changes at this point.
It's pointless arguing this aspect. Are we done with 2.2? If you want to vote on 2.2 - then vote on 2.2 - don't get in the way of other developers' progress with hand waving. That, I think, is the biggest lesson I took out of the httpd luncheons.
No offense, but I see you holding up the development by saying that 2.2 must wait for changes that aren't even written nor likely to be quickly accomplished and tested. -- justin
