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
>
