diff options
Diffstat (limited to 'web/ccvs')
| -rw-r--r-- | web/ccvs | 413 |
1 files changed, 359 insertions, 54 deletions
@@ -1,28 +1,282 @@ * CVS Access - If you are an active Mono developer, you can get a CVS account - that hosts the Mono source code. + Here we describe how one obtains commit access to the Mono CVS + repository and the responsibilities that come with that access + privilege. - If you are not a developer, but want to track the development, please - see the <a href="anoncvs.html">AnonCVS</a> instructions. + These only apply to the Mono CVS repository, and not to the <a + href="http://forge.novell.com/modules/xfmod/community/?monocomm">Mono + Community</a> repositories at Novell Forge. - Send an e-mail to miguel with your public SSH key for this - purpose. Please specify if the key was generated with SSH1 or SSH2. +** What is CVS? - If you are using SSH2, please generate your key using: + Briefly, CVS is a system tool used to store and maintain files and + a history of their changes over time. The Mono source code and related + files are kept on a CVS server at Ximian. + +** What Access? + + We mean "commit" access. This is the privilege to make permanent + changes to the Mono source code and related files. You need an account + created by the CVS server administrator in order to commit changes to + the files on that server. + +** How Does One Obtain Access? + + Any active Mono developer can get a CVS account. Normally one is + considered an 'active' developer after sending several patches to the + mailing lists and/or bugzilla for review. + + If you are not a developer, but want to access the latest sources, + please see the <a href="anoncvs.html">AnonCVS</a> + instructions. If you are not a direct contributor to Mono, + but want to host your .NET or Mono-based project, you can use + <a href="forge.html">Novell Forge</a>. + + + If you feel you are ready for a CVS account send an e-mail to + <a href="mailto:miguel@ximian.com">miguel</a> with your public OpenSSH + key for this purpose. We only support SSH2 at this point. + +* Policies + + It is necessary that everyone with CVS commit access respect and + adhere to the following rules. If you ask for and are granted CVS + access, you are agreeing to follow these policies. + +** Code License + + If you are about to commit code to a module, the code that is + being committed should be released under the same license as + the code that the module has. + + Check the license if you are unsure, but it is basically: + class libraries X11; compiler and tools: GPL; runtime: LGPL. + + If in doubt, check with the maintainers of the module, or send + mail to mono-hackers-list@ximian.com. + +** Changing code + + Even if you have CVS commit access, that doesn't mean you can change + code at will in any directory or module. Directories and Namespaces + have a sort of unofficial ownership. If you are not the owner of a + piece of code and you want to make changes/fixes to it, there are two + cases. + + <ul> + <li> The change is a typo fix or a one-liner build or trivial fix. In + this case almost anyone can commit (always remembering to add the + proper changelog entry to explain the change). We say "almost anyone", + because changes to certain directories almost always should be reviewed + first. Such as changes to core stuff: corlib/System, System.Collections, + mini/, metadata/, System.IO. + + <li> The change is larger. In this case the patch *must* be sent to + mono-devel-list for review by the owner of the code and by the other + hackers. Always submit such patches to the list or bugzilla, although + you may put the owner of the code in the CC header. Hackers come and go. + Mailing a patch to only a personal address is a good way to get the + patch forgotten and missed. Plus, getting the patches reviewed as well + as reviewing them, is a good thing, so try to get used to it. + </ul> + + Note: If the patch is an addition of code and doesn't change any of the + existing code, the rules are slightly relaxed: there is more freedom + in committing such changes, if they don't interfere with the existing + codebase. + +** Owning Code + + Now, how do you get to be the owner of a chunk of code? The answer is + simple. You wrote the code, so you're the unofficial owner. There is + also another way. After sending a few patches for the code, the + owner (or the core developers of mono, if the owner somehow disappeared) + trusts you and tells you you're free to commit without getting his + review first. + + + Here is a (partial) list of namespaces/directories with their owners: + <ul> + <li>Debugger module and debug code in mono: martin + <li>mcs compiler: miguel, martin, ravi + <li>Reflection/Reflection.Emit: lupus, zoltan + <li>IO-layer: dick + <li>mini: lupus, dietmar + <li>test suite: nickd (though anyone should feel free to add test cases) + <li>System.IO: dick, ville + <li>security stuff: spouliot + <li>ilasm: jackson + <li>System.Web and related: gonzalo + <li>System.Xml: eno, piers + <li>Remoting: dietmar, lluis + <li>interop/marshal: dietmar + <li>threads: dick + </ul> + + If you are the owner of a piece of code, feel free to commit code, and + delegate the work to others. + + But, if you're not the owner of the code, committing a rewrite without + getting a review first is not good cvsitizenship (especially when the + rewrite claimed to fix bugs, but not a single regression test has been + added to the suite). + +** Commit Rules + + Once you know you can commit a patch (because of the rules above) there + are a few other small rules to follow: + + <ul> + <li>Always add a ChangeLog entry with a meaningful + explanation, this file should be located in the same directory + as the change you make. + + <li>The ChangeLog entry <b>must</b> be pasted on the CVS + commit log, so the CVS commit log can be used to map to the + changes as well. + + <li>The ChangeLog and the files that comprise related changes + should be committed together, not one by one, otherwise the + history is pretty much useless if related changes are + separated during the commit. + + <li>If you fix a bug, add a regression test for it in the regression + suite. + + <li>Don't commit unrelated changes together with a fix: do fine-grained + commits. + + <li>Always check what you're committing: make sure you're only committing + what you need and make sure you don't change line endings and + whitespace. Do a 'cvs diff -u' of the files you're going to commit and + check the changes. + + <li>Don't do reformatting commits, unless you're the original author of + the code. + + <li>When fixing bugs, don't follow the documentation blindly, it may + well be wrong. Test the behavior on the MS runtime or ask on the list + for discussion if unsure. Don't be afraid of having your changes + reviewed. + + <li>Never remove copyright notices from the code. + + <li>Never remove licensing info from code. + + <li>Never commit code you didn't write yourself or code that doesn't + have a suitable license. + + <li>Follow the style conventions. + + <li>Keep an eye on performance considerations, especially for code in + core classes, ask on the list for guidance. + + <li>Do a regression test run and a bootstrapping build if making changes + to core functionality before committing. Do not commit code that would + break the compile, because that wastes everybody's time. Two things + are important in this step: trying to build your sources and making + sure that you add all the new files before you do a commit. + + </ul> + + Also, remember to pat yourself on the back after the commit, smile and + think we're a step closer to a better free software world. + +* Branches + + We have branched the CVS modules `mono', `mcs' and + `libgdiplus', the tag to fetch these branches is: `mono-1-0', + so you use the following command to fetch the mono-1-0 + branches: + +<pre> + cvs co -r mono-1-0 mono + cvs co -r mono-1-0 mcs + cvs co -r mono-1-0 libgdiplus +</pre> + + I personally use a directory called `mono-1-0' to keep these + together and a separate directory keeps my HEAD development, + and I configure each one to different prefixes, so I can test + and run code with HEAD or mono-1-0. + +*** mono-1-0 policy + + This branch will only get bug fixes to critical and major errors. + You must still get approval from the maintainer of the code to + check-in code into this branch. + + Before submitting a patch for this branch, you should run all + appropriate regression tests. Upcoming mono-1.0.x versions + will be produced from this branch. + +*** mono HEAD policy + + HEAD should continue to build at all times: HEAD is not a + dumping ground for partial work: you still must ensure that + the build is not broken, and that no regressions are caused. + Unlike the main branch, you do not need approval to minor + changes, the same old rules apply. + + But for any large architectural change, you must check with + the maintainers and get approval for the patches. For these + large changes, if you are touching someone else's code, you + should contact the maintainer of that code and get approval + from them. + + You must assume that HEAD will be packaged and distributed at + any point, this will be the branch that we use for making the + mono-1.1.x releases that will lead to our stable mono-1.2.x + release. + + So, the bottom line is: do not check-in known regressions that + break the build. A lot of work is underway, and we must + ensure the tree works. + + +* Using CVS. + + This is a small tutorial for using CVS. + +** Generating an SSH key + + If you are using SSH version 2, please generate your key using: <pre> ssh-keygen -t rsa </pre> - And mail me the id_rsa.pub file. + And mail <a href="mailto:miguel@ximian.com">miguel</a> the + id_rsa.pub file. - If you are using SSH1, run: + If you are using SSH version 1, run: <pre> ssh-keygen </pre> - And mail me your identity.pub file. + And mail <a href="mailto:miguel@ximian.com">miguel</a> your + identity.pub file. + + If you are using SSH from SSH Communications Security (they offer + a free SSH client for personal use), you have to use OpenSSH to + convert your public key to the required format. You have to use + OpenSSH's ssh-keygen program and write the following: + +<pre> + ssh-keygen -i -f id_XXX.pub > my_public_key.pub +</pre> + + where the file id_XXX.pub is your public key file, + normally located under ~/.ssh/ or ~/.ssh2/. + Send to <a href="mailto:miguel@ximian.com">miguel</a> the + my_public_key.pub file. + + The *exact* format for this file must be: + +<pre> + ssh-rsa XXXXX.... +</pre> You will need CVS and SSH. Windows users can get both by installing Cygwin (<a @@ -58,7 +312,7 @@ ** Making patches Usually you will want to make a patch to contribute, and let - other people review it before commiting it. To obtain such a + other people review it before committing it. To obtain such a "patch", you type: <pre> @@ -67,7 +321,96 @@ mail mono-list@ximian.com < file.diff </pre> -** Keeping track of changes. +** Committing your work + + Once you get approval to commit to the CVS, or if you are + committing code that you are the maintainer of, you will want + to commit your code to CVS. + + To do this, you have to "add" any new files that you created: + +<pre> + cvs add new-file.cs +</pre> + + And then commit your changes to the repository: + +<pre> + cvs commit file-1.cs file-2.cs +</pre> + +* Using SVN + + This is a small tutorial for using SVN (subversion). + For a more complete tutorial on subversion, look at + <a href="http://svnbook.red-bean.com/">the svn book</a> + or <a href="http://subversion.tigris.org">the svn homepage</a> + +** Generating a key + + Follow the cvs instructions above. + +** Checking out the sources + + To checkout the sources for the first time use the command: + + Note: You should be running 0.35.1 (latest) of svn before attempting + anything here. + +<pre> + svn co svn+ssh://mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop +</pre> + + If you have a different username on mono-cvs and the local computer + you can do the following: + +<pre> + svn co svn+ssh://username@mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop +</pre> + + before checking out. + +** Updating your sources + + You can update your repository to the latest copy of MonoDevelop by + running the following command: + +<pre> + svn up +</pre> + + from inside your repository. + +** Committing your work + + Before you commit anything, you should first update to the latest + sources by following the updating directions. After you are up to date + you need to run a: + +<pre> + svn add filename +</pre> + + for every file that you have created. You can get a list of these files + by running: + +<pre> + svn status +</pre> + + After all the files are added, run: + +<pre> + svn commit +</pre> + + to commit your changes. + +** For more information + + Look at the MonoDevelop website (coming soon) + +* Keeping track of changes. We provide two e-mail based mechanisms to keep track of changes to the code base: @@ -86,28 +429,6 @@ We hope to offer LXR and Bonsai in the future as well. -** Commiting your work - - Once you get approval to commit to the CVS, or if you are - commiting code that you are the maintainer of, you will want - to commit your code to CVS. - - To do this, you have to "add" any new files that you created: - -<pre> - cvs add new-file.cs -</pre> - - And then commit your changes to the repository: - -<pre> - cvs commit file-1.cs file-2.cs -</pre> - -** The Mailing List - - To keep track of the various development and changes to the - CVS tree, you can subscribe to the mono-cvs-list@ximian.com. To subscribe, send an email message to mono-cvs-list-request@ximian.com and in the body of the message put `subscribe'. @@ -115,24 +436,8 @@ This will send you an email message every time a change is made to the CVS repository, together with the information that the author of the changes submitted. - -** Recommendations - - Please do not commit code that would break the compile to the - CVS, because that normally wastes everybody's time. Two things - are important in this step: trying to build your sources and making - sure that you add all the new files before you do a commit. - - To build the sources, most of the type trying the `make' command - is enough. In some cases (the class libraries) we use nant, so - you need to run nant manually. - - Use ChangeLog entries so we can keep textual descriptions of - your work, and use the contents of your ChangeLog file as the - CVS commit message (ie, paste the contents of this into the - editor buffer). - If you are making changes to someone else's code, please make - sure you get in touch with the maintainer of that code before - applying patches. You want to avoid commiting conflicting - work to someone else's code. + You might also want to track the live changes, subscribe to + the <a + href="mailto:mono-patches-request@ximian.com">mono-patches@ximian.com</a> + to receive the patches as they are checked into CVS. |