[kepler-dev] Independent developer SDK for Kepler?

[Tony O'Hagan]

Christopher,

Thanks very much for your well considered reply.
I do appreciate the time this takes.

> This is an interesting idea that is between providing static releases
> and dynamic CVS.  However, my personal opinion is that people should
> pick one or the other.  The reason is that if people grab a copy of
> the CVS trees and there is a small bug, then they need to grab another
> copy of the CVS trees and if there is a small bug . . .
> As you can see, I've been down this path before :-)

Understood.  I have also danced on this pole.

> Another middle ground is to provide nightly releases that may or may
> not be stable.  The Ptolemy project does this, though I don't think
> people use them that much.
> 
> I'm very much opposed to people making copies of CVS trees, it flies
> in the face of what open source is about.  For example, for fairly
> good reasons, Kepler duplicates code in the Ptolemy tree.  However,
> this is a maintenance headache, since when those files change in
> Ptolemy, someone needs to merge the changes in by hand.  Yes, version
> control should handle this for us, but it does not.

One open source project that does this very efficiently is Ruby on Rails.
Their approach keeps the control and roadmap direction of the source to a
limited group while still allowing large numbers of contributors.  Submitted
patches should include test case code and the corresponding Trac tickets
minimise the documentation effort for the core team.  This scales very well
for them - but yes it does mean some additional work for the team. Check out
their directions for code contributors:
  http://dev.rubyonrails.org/wiki

I would have been very happy to completely avoid a CVS checkout if the last
beta release of Kepler had included a source code snapshot to download (I
couldn't find it).  I tried to find a matching release tag in CVS but did
not find one that appeared to correspond with the Beta 3 release.  Even
publishing this tag would help.  Obviously a stable release would be much
safer for me to build against.  I roll the dice each time I do a "bleeding
edge" checkout. 

BTW ... To my knowledge CVS does not support multi-repository tree grafting
but Subversion does!  SVN command line tools and TortoiseSVN work ok with
this but I seem to recall that the Subclipse Eclipse plugin does not play
this game very well.  There is a good CVS -> Subversion migration tool.  I
don't think tree grafting would work for me since actor code is sliced over
so many directories but it may be of interest to your teams.

Thanks again,
Tony O'Hagan