X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fccvs;h=e5a53432682c09a998cae91d5352ef4f31a73d2e;hb=33497c046809d9d58b68d92e173fb71146b3c051;hp=d57197201162478d9eb091fb64186c6bf89fd7fe;hpb=8c9185b6dd660ad4dbf73fd561a985e2430a3b5a;p=mono.git
diff --git a/web/ccvs b/web/ccvs
index d5719720116..e5a53432682 100644
--- a/web/ccvs
+++ b/web/ccvs
@@ -63,20 +63,23 @@
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.
- 1) The change is a typo fix or a one-liner build or trivial fix. In
+
+
+ - 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.
- 2) The change is larger. In this case the patch *must* be sent to
+
- 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.
+
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
@@ -123,39 +126,114 @@
Once you know you can commit a patch (because of the rules above) there
are a few other small rules to follow:
+
- - Always add a changelog entry with a meaningful explanation
+
- Always add a ChangeLog entry with a meaningful
+ explanation, this file should be located in the same directory
+ as the change you make.
+
+
- The ChangeLog entry must be pasted on the CVS
+ commit log, so the CVS commit log can be used to map to the
+ changes as well.
+
+
- 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.
+
- If you fix a bug, add a regression test for it in the regression
- suite
+ suite.
+
- Don't commit unrelated changes together with a fix: do fine-grained
- commits
+ commits.
+
- 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
+ whitespace. Do a 'cvs diff -u' of the files you're going to commit and
check the changes.
+
- Don't do reformatting commits, unless you're the original author of
- the code
+ the code.
+
- 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.
-
- Never remove copyright notices from the code
-
- Never remove licensing info from code
+
+
- Never remove copyright notices from the code.
+
+
- Never remove licensing info from code.
+
- Never commit code you didn't write yourself or code that doesn't
- have a suitable license
-
- Follow the style conventions
+ have a suitable license.
+
+
- Follow the style conventions.
+
- Keep an eye on performance considerations, especially for code in
- core classes, ask on the list for guidance
+ core classes, ask on the list for guidance.
+
- 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.
+
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:
+
+
+ cvs co -r mono-1-0 mono
+ cvs co -r mono-1-0 mcs
+ cvs co -r mono-1-0 libgdiplus
+
+
+ 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.