[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.



--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml