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
