We are starting to get patches from some new developers already.
This is great, it means NCO is soon to become a true opensource project.
Here is how the CVS access and patch submission will work:
0. You can always just upload patches via the "Patch manager"
feature on the sourceforge NCO project page without ever
following the instructions below on becoming a an NCO developer
with CVS write access. However, I urge you to consider the
few, one time-only steps, to becoming an NCO developer because
it makes incorporating your changes much easier for everyone
in the long run. Continue reading for how to do this.
1. If you add new features to NCO, e.g., the min/max/ttl patch,
you should add a few test cases to bld/nco_tst.sh which test
for correct behavior of the new feature. This also serves as a
check so future changes will not break the feature and go unnoticed.
Always use 'make test' to verify that your patch has not broken existing
features before committing your patch. 'make test' invokes an
(undocumented) script which checks behavior of key NCO features
with large files. nco_tst.sh is our guard against insanity.
Note that nco_tst.sh requires fast net access the first time to
download a large test netCDF file. During this process you
should post any tentative user-visible changes you are making
to the discussion forum, e.g., "I need a switch to turn on
frobbing with ncwa, how about -Q?"
2. Before you become an autonomous member of the NCO project
(and thus obtain CVS write access) you must upload your first
patches to the "Patch manager" to establish your credentials.
I will test your first set of patches and add you to the project
(enabling CVS write access) if they look good and appear to work.
Make sure your patches are against the bleeding edge code in the
repository (i.e., use CVS, see below for instructions) so that I
can apply them cleanly.
3. If you don't already know it you should practice CVS so you
can update the CVS repository yourself. doc/nco_src_frg.txt
shows the basic CVS commands to download NCO, you should read
the CVS manual for complete instructions.
Basically the process looks like this. The first time you must
check out NCO as an anonymous user, with no special priveleges,
cvs -d:pserver:anonymous@cvs.nco.sourceforge.net:/cvsroot/nco login
cvs -z3 -d:pserver:anonymous@cvs.nco.sourceforge.net:/cvsroot/nco co -kk nco
cd nco
cvs update -kk (periodically use this to update your repository to the latest code )
Now you have the current code. Make your changes to this code.
Test them with 'make test' if appropriate. Upload your patches
and any notes describing what they do with the "Patch manager" on
sourceforge. I (or, soon, others) will test them. If they they look
good I'll make you a member of the project with write access. Then,
keeping your patches safe somewhere, delete nco, and check it out
with developer/write status using your sourceforge login and ssh,
e.g., (substitute your name for zender)
Now you have a repository with write access. Now you can begin
making changes to the NCO repository as often as you like. Each
time you do you commit the changes with a message like.
cd bld
cvs commit -m "Fixed rpm-generation capability" Makefile
To synchonize your code with the updates of others to the repository
you will periodically need to do a
cvs update -kk
4. Now you've committed your code changes but you (probably intentionally!)
neglected one thing, Update the manual! the nemesis of programmers!
This is not required but it is really important to keep the manual
current so that new users know what NCO can do. The manual is written
in texinfo, which is not that hard to learn.
5. Once you have committed your patches to the codebase and
made sure they are working, we should tag the changes with, e.g.,
cvs tag -c nco1_1_53
and announce a new release. Let's wait until someone gets to this
stage before we decide how to new releases in more detail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A further note on submitting patches. The best way to submit patches
for most files is to use the diff/patch commands rather than uploading
the whole file to the patch manager. Here's an example.
Suppose you change the Makefile so that your bld/Makefile is now
different than the CVS repository and you want others to test your
patch before commiting your changes to the repository. This would
be the case if you did not have CVS write access, or if you simply
weren't ready to commit the code yet for whatever reason.
Go to your toplevel nco directory and create a patch using
cvs diff -c bld/Makefile > make_patch_01
You can also use just plain
cvs diff -c > make_patch_01
and the patch will be for all files that have changed relative
to the current CVS repository.
Then simply upload the patch to the patch manager.
We on the other hand who are testing your patch will
place the patch in our ~/nco directory and apply it with
patch -p0 < make_patch_01
If the patch needs changing then edit it and upload it
as, e.g., make_patch_02 and repeat the process until
the patch looks good, and then it is ready to commit
to the CVS tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This will prompt you for a password, but (since you are user anonymous)
there is no password, so just hit return. This allows everyone to check out
the latest code and it is referred to as anonymous CVS access.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are starting to get patches from some new developers already.
This is great, it means NCO is soon to become a true opensource project.
Here is how the CVS access and patch submission will work:
0. You can always just upload patches via the "Patch manager"
feature on the sourceforge NCO project page without ever
following the instructions below on becoming a an NCO developer
with CVS write access. However, I urge you to consider the
few, one time-only steps, to becoming an NCO developer because
it makes incorporating your changes much easier for everyone
in the long run. Continue reading for how to do this.
1. If you add new features to NCO, e.g., the min/max/ttl patch,
you should add a few test cases to bld/nco_tst.sh which test
for correct behavior of the new feature. This also serves as a
check so future changes will not break the feature and go unnoticed.
Always use 'make test' to verify that your patch has not broken existing
features before committing your patch. 'make test' invokes an
(undocumented) script which checks behavior of key NCO features
with large files. nco_tst.sh is our guard against insanity.
Note that nco_tst.sh requires fast net access the first time to
download a large test netCDF file. During this process you
should post any tentative user-visible changes you are making
to the discussion forum, e.g., "I need a switch to turn on
frobbing with ncwa, how about -Q?"
2. Before you become an autonomous member of the NCO project
(and thus obtain CVS write access) you must upload your first
patches to the "Patch manager" to establish your credentials.
I will test your first set of patches and add you to the project
(enabling CVS write access) if they look good and appear to work.
Make sure your patches are against the bleeding edge code in the
repository (i.e., use CVS, see below for instructions) so that I
can apply them cleanly.
3. If you don't already know it you should practice CVS so you
can update the CVS repository yourself. doc/nco_src_frg.txt
shows the basic CVS commands to download NCO, you should read
the CVS manual for complete instructions.
Basically the process looks like this. The first time you must
check out NCO as an anonymous user, with no special priveleges,
cvs -d:pserver:anonymous@cvs.nco.sourceforge.net:/cvsroot/nco login
cvs -z3 -d:pserver:anonymous@cvs.nco.sourceforge.net:/cvsroot/nco co -kk nco
cd nco
cvs update -kk (periodically use this to update your repository to the latest code )
Now you have the current code. Make your changes to this code.
Test them with 'make test' if appropriate. Upload your patches
and any notes describing what they do with the "Patch manager" on
sourceforge. I (or, soon, others) will test them. If they they look
good I'll make you a member of the project with write access. Then,
keeping your patches safe somewhere, delete nco, and check it out
with developer/write status using your sourceforge login and ssh,
e.g., (substitute your name for zender)
export CVS_RSH=ssh
cvs -dzender@cvs.nco.sourceforge.net:/cvsroot/nco login
cvs -z3 -dzender@cvs.nco.sourceforge.net:/cvsroot/nco co -kk nco
Now you have a repository with write access. Now you can begin
making changes to the NCO repository as often as you like. Each
time you do you commit the changes with a message like.
cd bld
cvs commit -m "Fixed rpm-generation capability" Makefile
To synchonize your code with the updates of others to the repository
you will periodically need to do a
cvs update -kk
4. Now you've committed your code changes but you (probably intentionally!)
neglected one thing, Update the manual! the nemesis of programmers!
This is not required but it is really important to keep the manual
current so that new users know what NCO can do. The manual is written
in texinfo, which is not that hard to learn.
5. Once you have committed your patches to the codebase and
made sure they are working, we should tag the changes with, e.g.,
cvs tag -c nco1_1_53
and announce a new release. Let's wait until someone gets to this
stage before we decide how to new releases in more detail.
A further note on submitting patches. The best way to submit patches
for most files is to use the diff/patch commands rather than uploading
the whole file to the patch manager. Here's an example.
Suppose you change the Makefile so that your bld/Makefile is now
different than the CVS repository and you want others to test your
patch before commiting your changes to the repository. This would
be the case if you did not have CVS write access, or if you simply
weren't ready to commit the code yet for whatever reason.
Go to your toplevel nco directory and create a patch using
cvs diff -c bld/Makefile > make_patch_01
You can also use just plain
cvs diff -c > make_patch_01
and the patch will be for all files that have changed relative
to the current CVS repository.
Then simply upload the patch to the patch manager.
We on the other hand who are testing your patch will
place the patch in our ~/nco directory and apply it with
patch -p0 < make_patch_01
If the patch needs changing then edit it and upload it
as, e.g., make_patch_02 and repeat the process until
the patch looks good, and then it is ready to commit
to the CVS tree.
Further clarification on CVS:
As stated in the previous message,
the first time you checkout the source you must log in with
cvs -d:pserver:anonymous@cvs.nco.sourceforge.net:/cvsroot/nco login
This will prompt you for a password, but (since you are user anonymous)
there is no password, so just hit return. This allows everyone to check out
the latest code and it is referred to as anonymous CVS access.