[chuck-users] Various general questions

[Tomtom]

Hi.

I totally agree with you about github and the usefulness of public
repositories for opensource project.

Unfortunately, this discussion pops up every three months or so on this
mailing list, and so far nothing has moved in this direction. I guess
this is not a priority to the core devs, but it's their work, so the
decision is in their hands.

Tom

On Fri, 23 Mar 2012 19:43:40 +0100, Robin Haberkorn <robin.haberkorn at googlemail.com> wrote:
> On 23/03/12 18:32, Robert Poor wrote:
> > On Fri, Mar 23, 2012 at 08:37, Robin Haberkorn
> > <robin.haberkorn at googlemail.com> wrote:
> >> 1) Does ChucK have a public source repository?
> > 
> > +10 to this question.  I REALLY recommend GitHub as ChucK's official
> > repository.  It's an awesome facility: you can fork branches for
> > testing new features.  It has a really great bug tracker.  It uses a
> > simple markup language for documentation.  And it's free.
> > 
> 
> I assume the ChucK team already uses some kind of VCS, be it CVS, SVN or
> whatever. I was just wondering whether it is public!?
> 
> But yes, I would also recommend GitHub. CVS or SVN imports really aren't
> that difficult to create. Done it several times. The most time-consuming
> part would be writing the mapping of CVS/SVN usernames to Git
> usernames/emails so everyone gets proper credit/blame for past commits
> on GitHub.
> And by the way, you would also get an independent ChucK wiki for free.
> If dependence on the GitHub company is a concern: if GitHub closes down
> you will have dozens of complete repository clones on users' systems.
> You can also host a public but non-accessible Git repository at the
> university and push to GitHub automatically - or only manually or
> certain branches. There are endless possibilities.
> 
> And as you pointed out Git itself gives you several advantages in the
> development process I've learned to appreciate. For instance if you're a
> core developer, you don't have to make your feature branch public, you
> can keep it in your local repository, rebase it onto the master branch
> and finally fast-forward merge it. You can use the "stash" to
> efficiently handle work-in progress changes, etc.
> But frankly merging is the only thing that *can* give you a headache in
> Git from time to time. This is probably workflow-related. (Plain) Git
> simply does not seem to imply a workflow with multiple stable version
> branches between which you exchange changesets and track their
> relationship. Although using "cherry-picking" something like that can
> probably be built on top of Git.
> However considering what I saw in the CVS Git-mirror, this will likely
> not be an issue with ChucK.
> 
> cheers,
> Robin
> 
> > Does Ge have authority (or at the the persuasive skills) to make this
> > happen?  If not Ge, then whom?
> > 
> > - Rob
> > 
> > P.S.: I'm happy to help set up a public GitHub repository if that would help.
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users