Sam Ruby wrote:
Ultimately, we'll have to discuss what groups people are assigned to and whether or not /etc/bashrc should be modified so that umask is set to 002 for everybody. What we need to ensure is that there is no problem with permissions of files that people create.
umask isn't automatically set to 002 - I'll see this eventually gets changed (I've been suggesting to people to change it in ~/.bash_profile). All 'system-wide capable' people are in the cocoondev group, there are some other people who are only in project-specific groups.
If other cocoondev.org account owners want to be in the cocoondev group to help Sam out, please indicate so. Currently, there's Jeff, Bruno and Marc, Ovidiu, Sylvain, Tom Klaasen, Sam, and myself. I just added David, too.
At the present time, the various cocoon blocks have gone from yellow (prereq failed) to red (build failed). These are now unblocked because the core build of cocoon now successfully produces a jar. Yea! They fail because these project definitions don't include a dependency on Ant (or Xerces for that matter). These project definitions also don't contain nag entries.
If somebody wants to make a change and test it out on cocoondev, simply update cocoon-2.1/gump.xml and issue the following two commands on cocoondev.org:
build gump scripts
build cocoon-block-htmlYou will find 'build' and a few other useful scripts and utilities in /usr/serverlocal/gump/bin. Add this to your PATH.
Since the project definitions for cocoon's core and blocks are not in gump's cvs but are defined to be retrieved from cocoon's cvs, an extra step is required: namely to commit these changes before building.
Since quite a few people are in multiple groups, and cocoondev isn't necesseraly their primary group, so some chgrp might be needed when you create new files.
Making people take extra actions to 'do the right thing' invites problems.
Let me describe how I would like to encourage this shared resource being used. I gave an example above: make a change and try it out. Build one project then build another that depends on it. No need to worry about classpaths or copying jars - all that is taken care of for you. Whatever change you make is immediately effective.
Make a change any way you like - for example, directly edit the files using your favorite editor, or simply do cvs update commands. Being able to do a cvs update with a "-D date" option is particuarly powerful - you can roll back changes made to projects you depend on and rebuild first that project and then cocoon. With a simple binary search over dates, you can isolate and identify the precise change that broke you. If you are so inclined, make a fix, verify that it works, and send a patch to the owners.
Don't worry too much about how you leave things. Every night (currently at midnight CET), the cocoondev will update to the latest from cvs and these directories will be restored via efficient 'rsync' commands and rebuilt. In fact, if you mess things up too much, simply rm -rf the project directory and do a build - the contents will automatically be restored to the last cvs checkout.
What this requires is that whatever id is used to execute the nightly builds has ability to update any files that people might produce. Umask 002 is an important part of ths - and making sure that I (or whoever is running the nightly build) am in the all the primary groups of everybody who might create files in this directory is another.
I'm still tweaking and improving, but don't be shy. Go forth and play.
Document root is /www/gump.cocoondev.org/webapps/ROOT which is owned by rubys, group cocoondev
</Steven>
