Stas Bekman wrote: > Philippe M. Chiasson wrote: > >> Stas Bekman wrote: >> >>> As RC6 release didn't reveal any significant problems (a few minor bugs >>> that are either already fixed or will be shortly), I propose that it's >>> time to get 2.0.0 out. I was thinking to work next week to polish things >>> and improve docs and get 2.0.0 towards the end of the week/or the >>> beginning of the following week. >> >> Sounds like a reasonable path to me. If necessary, I can take up the >> release-manager's hat once more if needed, since I have the time to. > > Cool, go for it. > > My plan was to polish things this week (add registryprefork and stuff), > get the 2.0.0-RC on friday and release 2.0.0 on monday if everything is > cool.
I'd probably add slightly more time between the RC and the release, especially if people only have the week-end to test it. I'd rather wait until tuesday or even wednesday, giving time to the folks who stay offline during the week-ends. > Remember that 2.0.0 is about API freeze. Yes, absolutely. > We will certainly have > problems to deal with when people will actually start using 2.0.0. But > before we release 2.0.0 they won't start using it. And it's the main reason I think that getting 2.0.0 out will probably cause more review and bug reports, leading to much better 2.0.n releases shortly after. After all, being a .0.0 release, it's understandable if it's got a few little bugs ;-) > So let's plan for the 2.0.0 release candidate (not RC7) this friday. > >> I would like to sort out the Apache::Reload segv problem before 2.0.0, >> though. > > It has been on the todo list for quite a few months. We can't wait > forever. I suggest that the old pure perl code will be committed instead > of the slightly limping new C code. Yes, like we discussed last time. I am working on a patch to bring back the old pure-perl (warning cursed) module unloading code, and suggest putting it into ModPerl::Util::unload_package_pp and keep the XS implementation as ModPerl::Util::unload_package_xs. Then switch Apache::Reload and friends back to using the pure-perl version until the XS one can be made as robust. I have finally put my finger on the problem though. In modperl_mgv, we cache GV* to the various stashes leading to a package. That optimization assumes that stashes will never dissapear. The new unload code does, thus, SEGV. The problem here, is that even knowing this, there isn't much that can be done while keeping the current XS unloading approach. Unless there is a way to find the various modperl_mgv's pointing to our old stashes and invalidate them somehow. From my understanding of that piece of code, it's not feasible. The modperl_mgv code itself can't verify the validity of it's cached GV* either, so I am not sure if this can be fixed without changing the way I implemented the XS unloading code. Deleting the stashes directly is what avoided all the mandatory warnings and all. -------------------------------------------------------------------------------- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature
