|
Message
From: Marko Mlinar <markom@o...>
Date: Fri, 18 Apr 2003 15:32:56 +0200
Subject: [openrisc] opencores comunity guidelines
Hi!
With couple of guys here we compiled a list of guidelines for openrisc project
in order to increase productivity, stability and to help new developers join
the group.
If we will find these guidelines usable, we can extend them to OC developers
guidelines.
Please tell me if you have some comments or anythings sounds unreasonable,
Marko
-----------------------
* Until the contributor/developer comes familiar with the system, policy and
strategy, all patches should be reported to the openrisc mailing list. After
a grant by a project maintainer, it is preferred that developer commit the
patch.
* Maintainer status is granted by any of current maintainers
* All planned features/fixes should be first discussed on the openrisc mailing
list, so that comunity together can steer the development and to prevent CVS
problems and unnecessary work.
* The source tree must always build and pass ATS tests on the
supported platforms, i.e. do not check in partially-completed work,
except on a private CVS branch. Supported platforms are any platform that
official ATS builds work on.
* It is the responsibility of those that make CVS checkins to look at the
results of subsequent ATS builds and fix any problems that occur. Developers
are "on the hook" until ATS tests pass - it is not sufficient for the build
to work in your own development environment. If the tree can't be fixed in a
timely manner, changes should be backed out.
* If the tree doesn't build, no one else should check in until it does build
again. (Except those that are trying to fix it, obviously.)
* All CVS checkins are required to have comprehensive CVS message,
which describes what the patch does. Even for small patches, message should be
rather comprehensive, e.g.: 'Missing comment to function xxx added'.
This allows developers to track changes and new features via cvs-checkins
mailing list without committing a lot of time.
* Submitted code must be abundant with well written comments
* When modifying existing code, formatting and white-spaces should be
preserved.
|
 |
Browse
