I have recently converted the source repository for Corosync to git with major assistance from Angus (thanks!). This will improve the quality of commits and allow developers to work on destabilizing changes agreed upon by the community for future versions of corosync without impacting maintenance work for stable versions.
Repository location ------------------- read access: git clone git://corosync.org/corosync.git write access: git clone ssh://corosync.org/var/lib/git/corosync.git web access: http://www.corosync.org/git There are three main branches ----------------------------- flatiron - contains current flatiron (1.y.z) stable release - maintained by Steven Dake [email protected] needle - contains next version weaver's needle (2.y.z) stable release - maintained by Honza Friesse [email protected] master - superset of all stable branches in the repository Topic Branches -------------- To allow the development of destabilizing changes without damaging master, topic branches will be supported. The current topic branches targeted for 2.0/3.0 of Corosync are: topic-libqb - integration with libqb - main developer Angus Salkeld topic-rr - redundant ring hardening - main developer Steven Dake topic-snmp - snmp integration - main developer Steven Dake topic-udpu - udpu integration - main developer Steven Dake topic-onecrypt - make one crypto module for all totemnet instead of the same code spread around - no developer topic-netmalloc - have interface driver allocate memory rather then totemsrp - mainly for rdma/ib performance support - main developer Steven Dake topic-iazc - on processors that support unaligned access(x86/x86_64), avoid all the extra memory copies happening in totempg - main developer Steven Dake topic-zerocopy - highly experimental zerocopy implementation - main developer Steven Dake (potential 3.0 work) topic-rdamud - conversion of rdma to use only ibverbs UD mode - main developer Steven Dake (potential 3.0 work) Merging process --------------- When someone submits a patch for review which is a bug fix or trivial feature enhancement, any developer with commit access can review the patch. After reviewing the patch, please switch to the master branch and use git am -s command to sign the patch. The second signoff verifies that the patch has been reviewed for errors by the reviewer. This means the person that submits a patch will never commit a patch, but instead the person signing the patch will commit the change. If the commit is for a topic branch, please follow this same process but switch to the appropriate topic branch indicated in the commit message. Commit messages --------------- Commit messages should follow the below format topic branch name: Short description of change <carriage return> Long description of change Signoff After signing and committing your changes, send them to the mailing list. Merging from topic branches --------------------------- In all cases, the master branch maintainer will be responsible for merging and signing off on a topic branch merge into master. Developers should never merge a topic branch into a stable release - everything must go into master first before going into a stable (flatiron/needle release). Branch manager duties --------------------- The branch manager for a particular branch is responsible for merging master changes into the branch they maintain. When satisfied with the branch and wanting to make a new release, we will have scripts in place to tag/release a new version in the coming weeks. What about developers without write access? ------------------------------------------- Sign your patches and send them as you normally would with git. A committer will review the patch and either commit to master, suggest a topic branch for your work, suggest changes needed to the patch before committing, or reject the patch with appropriate reasoning. If you work is for a topic branch, or you would like a specific topic branch created, please propose it on the ML. Final thoughts -------------- I realize this may seem a little more heavyweight process then we are used to, but I find often my patches are not reviewed, and I often am the only person reviewing patches. I'd like all people with commit access to take a more active role in reviewing per-commit to ensure we have great quality software worthy of the HA acronym. Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
