On Wed, Oct 20, 2010 at 05:14:47PM -0700, Steven Dake wrote: > 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 sd...@edhat.com > needle - contains next version weaver's needle (2.y.z) stable release - > maintained by Honza Friesse jfrie...@edhat.com > 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.
We could use kernel style "Reported-by:", "Tested-by": and "Reviewed-by:" > > 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. > This (the topic branch stuff) seems overkill to me. I would rather: 1) tell the ML what I am doing 2) publish a git tree where I happily (and potentially others) get things working 3) have others preview the code (to prevent wrong design choices) 4) then cleanup the commits and post them to the ML 5) reviewer can then commit (with sign-off) to master. > 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. I'll do more review. -Angus > > Regards > -steve > _______________________________________________ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
