Jacopo Cappellato wrote:
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
Legally the patch falls under the Apache license because it is a change to a
file with an ASL2 header, or a new file that is contributed with such a header.
The little question on the Jira server is nice, but only means so much.
In other words, it is what is in the patch and what it is being applied to that
is more important than how it gets to a committer.
2) follow the project's coding and formatting conventions (we should
create a separate Wiki page for these)
Yeah, this would be nice... Basically the sun standard conventions are the ones
we go with, as listed here:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
These have been around for a while and are stable and well thought out.
3) always try to follow the project's best practices (we should
reference to a separate document for these)
This would be the Best Practices Guide, which could use some feedback and
probably some updating. This is yet another preemptive documentation attempt
that seems to not actually have much demand....
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
Yeah, related to #1, this is very critical, and in fact required. New files
without this will be rejected (or should be rejected...).
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;
Sounds good.
So how do we get this party started? Si: do you want to post your stuff in the
admin space on docs.ofbiz.org and then Jacopo can change it? Or, Jacopo: feel
free to throw this stuff in along with Si's or whatever. I guess it doesn't
matter. Like most things someone just has to find a place to put stuff and then
put it there.
-David
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
