THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Info | ||
|---|---|---|
| ||
The OFBiz project will next release 2 products: the framework (which for now includes applications) and the plugins. It is the responsibility of committers to maintain both products. So committers should checkout the framework and include the plugins using the Gradle pullAllPluginsSource. It is the also responsibility of committers to help fellow contributors to achieve a successful resolution of issues in JIRA. Committers should try, as much as possible, to avoid that patch files submitted to issues grow stale. It is a waste of effort and precious time on the part of a fellow contributor when patches grow stale, as rework needs to be done. Timely evaluation of patch files prevents the need for rework and re-evaluation. Showing interest in the work of fellow contributors builds better relationships and a healty community. When doing so, an efficient rule of thumb for productivity is the Ten minutes rule: if you can commit a patch in less than 10 minutes then just do it! Of course not don't do that all the day long. Another important responsibility of a committer is participating in voting, especially the ones for new releases.. |
...
- Use a SVN 1.8 or newer client. Because we use repo dictated configCommitters should set up their SVN client to use and no longer need the official OFBIZ Subversion client configuration file, at least for OFBiz (you might need for other purposes...)
- When a committer adds a new file type, it must be put it as a svn:auto-prop at the OFBiz root level in ASF Subversion repo. Here is a commit example: http://svn.apache.org/viewvc?view=revision&revision=1840885
- Committers should review contributions to ensure that they follow good coding standards, are well-commented and understandable, and follow our coding conventions
- The commit message should follow the general Commit message template.
Committers should write a meaningful description of the feature being committed in the commit log so other developers and committers could understand what is happening.
Note title Here are some commit comments examples of badness taken from an Adam's message in dev ML - Fixed bug (reported by $user)? from $location.
When reading history, the full discussion leading up to a proper bug fix is not important. But a description of the bug, and the solution, are necessary.
Quite often, when trying to find a bug, the original sources are not available. All you have at your disposable is the installed system image. The changelog describing the software installed very often accompanies the installation. It's quite possible that no outside access is available. Embedded system deployments do this quite frequently.
When scanning a changelog for possible hints into why something is/isn't working, if I have to switch back and forth from the target system, and an external system, to figure out what is going on, then it will leave a sour taste in my mouth. Going forward, I would be reluctant to recommend the software again.
Additionally, no one is you. There are 6 billion other people on this planet, and you are the only one who knows what you are thinking. We can't read minds. It becomes even more difficult to do so, 2-3(or more) years in down the road. So, describe what you have done at the time you have done it.
Also, not everone knows how jira works. Or confluence. Or AutoConfigMaintenceWidgetApplication. What you may thing as a sensible cross-reference(OFBIZ-####, debbugs ####) may mean nothing to the person reading your changelog.
- I did some things in FooClass, FooImpl, some more stuff in BarWidget, and yet more interesting tidbits in YellowSubmarine; basically, stuff all over the place.
This bad changelog is not about poor descriptions of the changes. It's about listing multiple, 100% completely separate improvements/fixes into a single commit.
If there were 10 lines changed, and 1 line was not related, it's possible that you could still notice that 1 extra line. But if you have 1000 lines changes, and there are 3 groups of changes, and they are all intermingled, it becomes very difficult to verify that each separate change was actually implemented correctly.
It's much better to split up such changes, and commit them separately. There are several ways to do this. svk/hg/git can be used to mirror svn, have local changes, then push when you are done. You can use multiple svn checkouts, and redo your changes, one step at a time.
- Fixed bug (reported by $user)? from $location.
...