On Thu, 2003-05-29 at 15:39, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > On Thu, 2003-05-29 at 15:14, Stas Bekman wrote: > > > >>>>I'm not sure why that code was there. So I'm not so confident on removing it. > >>>>mp1's test suite is too poor for regression testing. > >>> > >>> > >>>Yeah, you can say that again. I dunno if it would be eventually worth it > >>>to port mp1's tests to Apache::Test and try and achieve better > >>>covereage. But once again, how long are we planning mp1 will stick > >>>around ? Would it be worth it ? (not for 1.28 for sure) > >> > >>mp1 is here to stay for a while. However if you don't change its guts you are > >>safe from breaking things. Millions of installations are a good test suite ;) > > > > > > Yeah, but this patch is a good example. > > > > I want to stick with : "If it aint broken, don't fix it" > > > > Only problem, it's broken. But it's hard to have any confidence in > > patches like this one that touches 'guts' stuff. > > > > I am just worried that these patches will stay out there for quite a > > long time before they are eventually included. > > > > As I am processing STATUS, I am hoping I'll be able to at least produce > > a viable patch for most issues (or dismiss them). But on what basis > > should we decide what does go in a 1.28-tobe and what stays a patch for > > users to test? > > I think previous it worked as follows: patches were applied long before the > next release was done, so those who use the cvs version get to test things for > a while (1.0 releases aren't very frequent). Based on this, I'd suggest the > following approach: if you are confident that a patch won't break things go > ahead and commit it into 1.28-tobe. If not, release 1.28 and immediately > commit those questionable patches, into 1.29-tobe. You kill 2 birds with this > approach: > 1) you get the issues resolved without risking breaking things > 2) those who need those patches, can always use cvs ;)
This does make a lot more sense, actually. I should have figured that out on my own. But I then have a question. I was trying to review the current STATUS and at least give each issue a shot. Either submit a patch, get more information, document the problem, etc. And I was trying to get all that done prior to a 1.28 release. In light of all this, wouldn't it make more sense to ship 1.28 as CVS stands right about now ? Once it's out there, I could finish my planned review of known issues and get people a change to try it out with CVS. So I guess I am wondering if there are any issues that would NEED to be resolved before 1.28 could be good enough to be shipped out ? > __________________________________________________________________ > Stas Bekman JAm_pH ------> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- -- ----------------------------------------------------------------------------- Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B) http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5 Q: It is impossible to make anything foolproof because fools are so ingenious. perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
