On Mar 11, 2010, at 8:56 AM, David E Jones wrote: > > On Mar 11, 2010, at 12:28 AM, Adam Heath wrote: > >> Jacopo Cappellato wrote: >>> On Mar 11, 2010, at 8:14 AM, Adam Heath wrote: >>> >>>> What I am about to propose may sound rather severe, but I would like >>>> to see a moratorium on any new features. Test cases and bug fixes >>>> only. Ofbiz has gotten *WAY* *TOO* BUGGY*. >>> >>> Very interesting Adam. I may be wrong but I am under the impression that >>> you have missed some of the irony in David's words. >> >> Oh, I saw the irony. I just gave a more concrete example of a real, >> very critical problem. >> >> There are lots of new people who've come on board since the last time >> I was involved with ofbiz, and the quality of the project has gone >> down hill. > > You're right Adam, this is a great example of a part of the project that has > wandered a lot with lots of "cooks in the kitchen" and many changes are made > without really understanding what is going on or what side-effects might > arise. > > Thank you for taking this approach to these issues. This is the best sort of > contribution when issues are found, and a nice way to collaborate by > respecting changes from others but also pitching in to help fix things. > > From a bigger picture perspective... what are other ways we could handle this > better? > > On a historical note, this is the very reason why I pushed originally to have > a very limited set of committers with write access to the framework. Later on > this group grew to include all PMC members (a mistake IMO) and now includes > all committers (I was okay with it at the time, and even though this was > recent I also consider this a mistake). > > Things are just too complicated for casual changes to have a good chance of > working well. Or, that's my opinion anyway. What might be nice is to restrict > access to the framework, and maybe even have people acting as moderators for > different parts of the framework. For example, if you can't make any changes > to the Entity Engine without going through Adam Heath then this may slow > things down a bit, but there would be a review of the design and > implementation of every new feature or fix and that would lead to more > consistency and quality in the design and implementation of the tool, making > it hopefully easier to use and safer to rely on. > > That's not exactly in the spirit of open community, but maybe it's a better > way to go? > > -David >
David, thanks for sharing your thoughts about our strategy about committers and commit rights. If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this. We actually may want to explore the following strategy: 1) do not change commit rights but 2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas Kind regards, Jacopo
