http://ofbiz.116.s1.nabble.com/Re-svn-commit-r918926-in-ofbiz-site-images-follow-us-b-png-index-html-tp1578166p1589248.html
+1 - and thanks for laying it out Ean. I guess the only question remains is what stops us from moving in this direction if we can achieve exactly what Ean's talking about? This sounds like something that would allow all of us the ability to manage the pieces we want to without polluting the code base with internal initiatives.
Alas, I do feel like this might be a huge departure for many - but this seems like it might fix many of the contentious issues that waste a ton of time around here.
> ----- "Jacopo Cappellato" wrote:
>> 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
>
> This is exactly the way things are handled in the Linux kernel and exactly why Adam and I have been excitedly calling out "use GIT, use GIT!". The kernel team long ago ran into the problems of scaling control with the size of the contributing community. Originally they handled everything as a bunch of shell scripts that glued a workflow together out of tar balls and patchsets. Eventually that gave way to BitKeeper, which was up to the task but crippled by its proprietary nature. That lead to GIT.
>
> In my mind, we should clone the Linux source management model because what we are running into is already a solved problem for them. There should be a very limited (perhaps even 1 or 2) number of people who commit directly to the SVN repository and those 1 or 2 people should be primarily focused on architecture and style rather than developing new features. Under this model, a commit process might look like this:
>
> (Advance warning: there are mild comedic elements in this exchange. Adjust mental tone to "positive".)
>
> - Hans: I've just radically expanded the ProjectManager to automatically synchronize itself with todo-items on BaseCamp, JIRA, DebBugs, Bugzilla and LaunchPad.
> - David: Wow, that's interesting, let me take a look at that. (pulls a copy of Hans' updates into a branch in his GIT repository)
> - David: This is cool stuff Hans, but the 2,700 line commit with the comment "make stuff work" and the varying 3,4,7 and 9 space indents mixed with tabs trouble me. Can you fix that?
> - Hans: I'm terribly busy making some money over here David and what I've done is very important. Can someone out there polish up those tiresome flaws and work our David's complaints?
> - SomeGuyOnTheList: Gosh, I really need BaseCamp integration. I'll try to help.
> (various conversations, patches and history rewriting occur between SomeGuy and Hans)
> - SomeGuyOnTheList: Hey David, I've worked with Hans this past week or so and its a lot cleaner now. You want to pull the latest version from Hans or my repo?
> - David (pulling the latest version): The vastly improved state of this code puts a song in my heart! I am no longer a man whose will has been broken by the travails of building concensus in a community with divergent interests! I am free and I shall happily commit these changes!
>
> (a vast cheer goes up from ERP-less small businesses everywhere)
>
> This fairytale can easily become a reality because, unlike the Linux community in its time of darkness, the tools to make it happen are a solved problem. We merely have to borrow best practices from our friends who can both provide us examples and advice if we need it.
>
> --
> Ean Schuessler, CTO Brainfood.com
>
[hidden email] -
http://www.brainfood.com - 214-720-0700 x 315