> I also find it interesting to see the different reactions in different > ASF projects I keep an eye on as they convert. APR and HTTPD, for > example, don't seem to have any real problems with the conversion, while > mod_perl seems to keep running into issues. I guess it's just different > projects having different usage patterns for the software.
I'm not entirely sure that we aren't making some of these issues up, or at least making more of them than everyone else. from my pov, the real issues are these: - commit email subject - no commit template - the whole svn:external bit all the rest fall under "svn is different than cvs, and different isn't as good because making my mind undifferent takes up my few remaining precious tuits." that's not criticism either - I felt the same way the first time I had to use svn (though I got over it). david and I started a one-way conversation with infrastructure@ about making commit emails better which went nowhere. if we can control our own mailer and messages I think I'd like to prove to everyone that we can come up with something better using a SVN::Notify subclass than they can modifying some global python script. but, alas, I don't have the tuits to do it on my own atm. now, the commit template issue is a global one that all project need to deal with. apparently everyone else is ok with it, or not making a big enough fuss to make it something to worry about. so, we either accept it and move on, or take care of it ourselves through [EMAIL PROTECTED] the most serious issue is the svn:external bit, and it seems like we are in exactly the same place as httpd/apr - you are required to have apr and apr-util right under srclib/ to get httpd to build (as well as for release). but nobody over there is complaining about how svn ignores foo or doesn't do bar. so, the problem is either our mindset or something is really wrong with our setup. in either case, both are fixable (just in different places). if the solution is to checkout mod_perl then checkout A-T then we should just do it, since it will just be for the developers anyway and everyone is used to doing the same for httpd. I can't see another real issue out there at the moment, but there may well be others. fwiw, I checked out httpd/apr/mod_perl from svn as soon as they were available and my nightly builds have gone off without a hitch since, so I have no real complaints at all (save the way it was all kind of thrown together, but no sense in complaining about that). >> or just send them both to the same list, that's what httpd seems to do. > > > thanks, but we aren't not httpd. you know, animosity like this can't have a net positive effect on anyone. mod_perl is probably the project most closely tied to httpd outside of apr, but they have 10 million times the userbase that we do - being developmentally consistent with what is essentially our parent project lowers the bar for both new mod_perl developers and httpd developers who would like to see mod_perl succeed. for me, whenever I talk about how httpd does one thing or another this connection and desire for community crossover is what I have in mind. it is in our best interest to maintain a somewhat consistent feel between the two projects - not to follow them over a bridge, of course, but to follow them into battle even if it doesn't quite make sense to us on the ground :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
