+1 Jacques
> Hi, > > what about adding a few more rules about committing best practices? > > Something like: > > 1) when committing a patch contributed by another person, always put a > comment in the commit log with the name of the person and (possibly) the > Jira id to which the patch was attached; contributions should be > explicitly donated by the author to the project and so the best way to > receive them is thru Jira; committers should not committ patches > received by them thru a private channel > > 2) follow the project's coding and formatting conventions (we should > create a separate Wiki page for these) > > 3) always try to follow the project's best practices (we should > reference to a separate document for these) > > 4) before a commit make sure that there are no license issues with it > and always add the ASL2.0 header to new source files > > 5) committers should setup their svn client to use the official OFBiz > Subversion client configuration file > > 6) each commit's log should be meaningful and descriptive > > 7) it’s very important to commit related changes together in a > single revision (if a single logical change is spread over several > commits, it becomes more difficult to revert the change and also more > difficult to track which files the change touched); each commit should > represent an indipendent logical unit; for example, when possible, try > to commit separately a bug fix and a new feature; formatting changes > should be kept separated from functional changes; > > Jacopo > > David E. Jones wrote: > > > > I think this is certainly good enough to put on docs.ofbiz.org, and you > > should have permissions to write in the admin section (if you don't let > > me know and I'll hook you up). > > > > -David > > > > > > Si Chen wrote: > >> No other comments? So everybody agrees with this? > >> > >> > >> On Jun 20, 2006, at 10:16 AM, Si Chen wrote: > >> > >>> You're right. I think that's actually how most projects do it. > >>> > >>> > >>> On Jun 19, 2006, at 7:10 PM, David E. Jones wrote: > >>> > >>>> Si, > >>>> > >>>> This looks pretty good and the body of the text is fine for a first > >>>> pass in my opinion, with just a few editorial fixes perhaps. > >>>> > >>>> For the new committer guidelines this isn't quite the process that > >>>> is generally followed. Usually committer privileges are given on an > >>>> invitation only basis. If someone is clearly getting involved a lot > >>>> with the project and helping with issues and submitting lots of > >>>> patches that look good, then the invitation to be a committer is > >>>> pretty natural. If someone asks for commit privileges we should > >>>> certainly consider the request, but the more natural progression of > >>>> it is that it happens on an invitation basis from one or more > >>>> existing committers, and then the PPMC would vote on it if that > >>>> person is interested and accepts the offer. That's way it has > >>>> worked in that past anyway... > >>>> > >>>> -David > >>>> > >>>> > >>>> Si Chen wrote: > >>>>> Hi everybody. > >>>>> > >>>>> As the project has grown in the last two years, we have more > >>>>> committers, so we thought it might be nice to have something which > >>>>> described more "formally" what the committers do and how one becomes > >>>>> a committer of the project. This is a preliminary list, based on an > >>>>> email David wrote to the PPMC and some added comments from others, > >>>>> with my own modifications: > >>>>> > >>>>> ---- > >>>>> > >>>>> OFBiz is a community driven project, and the point of a community- > >>>>> driven project is to build software that would work in a large > >>>>> variety of situations with a large group of other other people. > >>>>> Therefore, it is really important than the project is written in a > >>>>> way which would benefit many potential users, and that the community > >>>>> works together towards that goal. > >>>>> > >>>>> This is especially important for the commiters of the project to > >>>>> remember, since they would be making decisions not just for your own > >>>>> organization or your own clients, but for all current and future > >>>>> users of OFBiz as well. Thus, commit privileges carry with them a > >>>>> responsibility for "the greater good" of the project. > >>>>> > >>>>> Nothing should be committed that breaks existing functionality just > >>>>> to make something easier for a particular client or customization > >>>>> effort. This means, in particular, that if some progress is made on > >>>>> a certain effort but you can't finish it in the time you have > >>>>> available, then don't commit it if it breaks anything that was there, > >>>>> just keep it local or attach it to a Jira issue or something if you > >>>>> want others to be able to get involved (or just it to the point where > >>>>> the stuff it broke works again, then commit it.) > >>>>> > >>>>> To avoid code ownership, anyone can work on anything, but please be > >>>>> sensitive to areas where you are not familiar with the code and check > >>>>> with others who have worked in the area before doing something. A > >>>>> good practice is to ask someone who is more familiar with something > >>>>> to review it before you commit it, and if they have objections > >>>>> respect it and find a compromise that works for everyone. > >>>>> > >>>>> To become a committer, you should be highly familiar with OFBiz and > >>>>> should already have had a significant number of contributions > >>>>> accepted into the project. > >>>>> > >>>>> Committers should be actively involved in contributing new code or > >>>>> review patches from the community. If someone has stopped making new > >>>>> contributions for a while, we should find out why. > >>>>> > >>>>> Committers should be nominated by another committer and should be > >>>>> accepted by all the other committers without serious objection. In > >>>>> other words, not just a majority of other committers but a consensus > >>>>> of all the other committers. I'm not saying that we must always like > >>>>> everything somebody has done, but if there are serious objections, we > >>>>> would need to address those first. > >>>>> > >>>>> --- > >>>>> > >>>>> We did not discuss any formal processes earlier, but I'm thinking > >>>>> perhaps the following: > >>>>> 1. To become a committer, to write one of the existing commiters to > >>>>> be nominated. Then the nomination will be forwarded to the ofbiz- > >>>>> ppmc, discussed and voted upon there. > >>>>> 2. Should the PPMC do an annual review of the committers and > >>>>> community members to see if any of the committers have "left the > >>>>> project" and if any new developers should be invited to join? > >>>>> > >>>>> Si > >>>>> > >>>>> _______________________________________________ > >>>>> Dev mailing list > >>>>> [EMAIL PROTECTED] > >>>>> http://lists.ofbiz.org/mailman/listinfo/dev > >>>> _______________________________________________ > >>>> Dev mailing list > >>>> [EMAIL PROTECTED] > >>>> http://lists.ofbiz.org/mailman/listinfo/dev > >>> > >>> _______________________________________________ > >>> Dev mailing list > >>> [EMAIL PROTECTED] > >>> http://lists.ofbiz.org/mailman/listinfo/dev > >> > >> > >> _______________________________________________ > >> Dev mailing list > >> [EMAIL PROTECTED] > >> http://lists.ofbiz.org/mailman/listinfo/dev > >
