> > > I do not want to discourage people, I am just trying to make you
> all
> > > consider the consequences if you mess up.
> >
> > Maybe we need a new branch, called "cruise-control". This would
> never be
> > updated directly, but would periodically (say weekly for now, more
> often
> > as we approach deadlines or releases) merge in master, then trigger
> its
> > own cruise control test. Things that broke the cruise-control branch
> > would incur the wrath of Ross, and maybe an automatic roll-back of
> that
> > branch to the last known good state.
> >
>
> I like this approach.
I think this approach is terrible and misses the whole point of
cruisecontrol. It will automagically test your code for you with a bunch of
compilers (and eventually the test cases etc) to save you the trouble of
doing it. What it won't let you do is break something and then say "oh never
mind, some other shmuck will fix it for me and I don't have to take any
responsibility".
> I'll inject a comment or 2 here. I personally think we as a community
> should be a bit conservative with development branches we publish to
> git.ambermd.org. (I personally don't publish any of my -dev branches
> on
> git.amber, but on a local gitosis repo set up here)*. I think that's a
> better alternative to dumping everything on git.amber in many (not all)
> cases. (I count 18 branches on git.ambermd.org:/amber.git, many of
> which
> haven't been touched in a long time). The frequent merge advice is
> good
> advice, and I echo it.
I disagree here. I would actually encourage people to keep their work on the
central AMBER git repository. That way we all have the option of checking
out a branch if need be to see how things are diverging, if you get stuck
with something someone else could easily just switch their branch and take a
look to try to help etc. We see the logs so can see what various people are
working on etc. This keeps us together as a team and prevents fragmentation.
It also means code isn't lost on the half life of a graduate student. The
branch won't die when the student leaves. It might not grow any further but
we will always have it in case someone else wants to carry on the work.
The central git server is also enterprise class hardware, mirrored and
backed up frequently. If you keep your branch there as well as having the
working clone on your home machine then you automatically have offsite
backup for your work.
The only real downside to this is that it makes cloning the tree take
longer. However, I have new hardware on order including new switches and
solid state drives that should improve this considerably over the coming
months.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Nov 12 2011 - 14:30:03 PST
