From: Paul P. <bay...@gm...> - 2011-01-10 20:37:52
|
I have to admit I like you three being sorts of gatekeepers to the repository to make sure not just anything is making it in. But I also understand having only 3 people becomes more difficult as the project grows. That being said, I have a few thoughts, and they are just that, so anyone feel free to reject, improve or approve the following. I think this is a good discussion to be had. What if you begin allowing certain committers, but only you 3 have commit access to trunk. I.e. we begin using branches & tags. Exhibit #1: http://en.wikipedia.org/wiki/Apache_Subversion#Branching_and_tagging If we started today, we would immediately make tag 1.0.0 from trunk. Since most will not be committing to trunk, there's a couple of options for branches, but here's one. There is a primary development branch into which all completed work will be done. Any committer can put their work there, but should only commit finished milestones, not works in progress. More advanced developers can create a personal branch, in which works in progress may be committed. E.g. I may make "xmlvm/branches/ppoley/synchronizedSupport". When finished, they will merge their work into the development branch with a comment such as: "Support for synchronization merge -r5260:5283 http://xmlvm.svn.sourceforge.net/svnroot/xmlvm/branches/ppoley/synchronizedSupport " Any unwanted commits will be reverse merged out of the branch. Since only the 3 will have access to trunk, they will merge a set of stable changes into trunk from time to time & then immediately make a new tag to mark the milestone. This still puts somewhat of a bottle neck on the 3, but a much smaller one since this doesn't have to be done for each change. One downside is not immediately being able to immediately see original committer when looking at trunk, but if the merge into trunk is done in the same manner as above including the merge command, you can go to that branch & see who did what. In this way, the development branch does not change. If for some reason we felt the development branch had been corrupted by changes that didn't make it to trunk, we could delete the branch & recreate it from trunk at the same location. Thanks, Paul On Sun, Jan 9, 2011 at 6:03 PM, Arno Puder <ar...@pu...> wrote: > > Guys, > > we had some internal discussions regarding the future of XMLVM from a > project management perspective. Right now there are three core team > members (Sascha, Wolfgang, and myself) who are the only ones to have > commit rights. Contributors have to submit their patches to an online > review system where the core team members review the patch and if > accepted, commit it to the Subversion repository by mentioning the name > of the contributor in the commit log. We have laid out the guidelines > concerning coding conventions that can be found at: > http://xmlvm.org/contribute/ > > We believe that in order to grow as a project, we need to be more > flexible with regards to this process. In the long run the current model > does not scale with regards to the amount of work. > > We propose to introduce a new role within the XMLVM project: the role of > a committer. A committer, just like the core team members, has commit > rights to the Subversion repository. The core team can offer a > contributor the role of committer if the contributor has proven > him-/herself over a period of time to deliver high-quality patches that > follow XMLVM coding conventions. A committer typically is responsible > for a certain module within XMLVM. Within that module, the committer can > make changes according to his or her discretion. If a change is > necessary outside that module, the modification should be done by > consulting the core team. As a good practice, major changes should be > discussed on the mailing list anyways. If a committer repeatedly > violates XMLVM coding conventions, the core team member can rescind the > commit rights. > > We would like to put these guidelines up for discussion on the mailing > list. We believe that it will help grow XMLVM as well as acknowledge and > recognize significant contributions by some developers. > > The XMLVM Core Team > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |