On Sat, Apr 18, 2009 at 9:28 AM, ant elder <[email protected]> wrote:
> > > On Thu, Apr 16, 2009 at 10:16 PM, Luciano Resende <[email protected]>wrote: > >> On Thu, Apr 16, 2009 at 1:33 PM, ant elder <[email protected]> wrote: >> > Ok so ignoring what and why that may have happened in the past as you >> were >> > in favour of this approach before could i assume you yourself will be ok >> > with it again this time? >> > >> >> I think this would be a good improvement, we just need to come up with >> a clear strategy for removing the modules and avoid complaints as we >> had last time. >> >> Suggestions for the process ? >> >> How to ensure no users are using these modules ? >> >> >> BTW, I'll listen to others process suggestions before giving my >> opinion, as my approach didn't work very well last time :) >> > > I'm not sure how easy it would be to come up with a precise strategy as > each case will be slightly different. We should expect to move a few things > and be asked to move them back without getting heat up about it. I think it > will be easier now, there's already stuff moved out of 2.x into contrib > which sets a precedence, just having 2.x changes things as thats where most > new stuff should be happening anyway. The culture and climate of the project > is a little different now too which should help too. > > So i say JFDI. Anything thats not included in the full build and isn't > being actively worked on move it out, anything that _is_ in the build but > isn't usually included in the binary release could be a candidate too. This > is not a rip-and-replace opportunity though, we shouldn't move something out > just as we want to rewrite it in our own style, so if something is moved out > and later on we want to look at similar function again we should try to > resurrect the old code not start from scratch. > > ...ant > > > I've started doing some of this and plan to continue slowly over the next days. Feel free to help. ...ant
