Scala Incubator resources

Miles Sabin writes:

> I'm still undecided about issue trackers. My own experiences with JIRA
> (all versions, including the top end commercially supported variant)
> are that it's only marginally better than Trac and really pretty
> clunky. I've had several recommendations for Lighthouse,
>
> http://lighthouseapp.com/
>
> which seems a lot more user friendly and has out of the box github
> integration. I'm inclined to go for that ... any other opinions?

I don't disagree on Jira being clunky but the places where I've used it,
it gets the job done (as does Trac). Personally, I find lighthouse (and
github tickets) too simple for all but the most trivial projects.....

But it probably depends on the level of process/workflow you need to
support. Which may need to be defined first....

/Jeppe

Miles Sabin a écrit :
> which seems a lot more user friendly and has out of the box github
> integration. I'm inclined to go for that ... any other opinions?

Internally, we use Redmine (http://www.redmine.org/) and gitosis, but
our projects are rather small for now, and don't have a big amount of
record with it (only 2 months), but it get the job done, is easy and
friendly to use, and the irc chan is welcoming - that's all I can say
for now. And redmine is more a forge à la Trac than just an issue
tracker (it comes with a wiki etc).

I used Trac some times ago (more than one year), and remember it as
being to simple out of the box, and quick to grow unstable with some
plugins in.

Jira is the reference, but I'm still not sure I like it. I prefer
redmine for the sue case I encountered, but I can't say how Redmine
would behave if it has to manage the zillions of Apache projects.

I don't know Lighthouse, so it's difficult to compare.

Xorg project seems to be in the same wondering phase :
http://lists.x.org/archives/xorg-devel/2009-September/002237.html ;)

On Sun, 2009-09-27 at 22:46 +0200, Francois Armand wrote:
> Internally, we use Redmine (http://www.redmine.org/)

Redmine is nice, but I was under the impression that Miles was aiming
for hosted solutions to avoid admin work.

> I don't know Lighthouse, so it's difficult to compare.

I haven't used it either. From the description, it seemed better than
the github issue tracker, but hard to say from screenshots alone. Miles,
do you know any project that has an openly accessible instance?

Best,
Ismael

For me, I think that Mylyn integration is one of the big plus-points with Jira.

It's not a make-or-break proposition, but it is seriously nice to have

On Sun, Sep 27, 2009 at 8:09 PM, Miles Sabin wrote:
> Hi folks,
>
> A quick update on this ...
>
> I've set up a Google group here,
>
>  http://groups.google.com/group/scala-incubator
>
> And a github account here,
>
>  http://github.com/scala-incubator
>
> There seem to be numerous recipes out there for mirroring a SVN
> repository to github ... if anyone has any specific recommendations
> I'd be grateful for suggestions (Paul?).
>
> I'm still undecided about issue trackers. My own experiences with JIRA
> (all versions, including the top end commercially supported variant)
> are that it's only marginally better than Trac and really pretty
> clunky. I've had several recommendations for Lighthouse,
>
>  http://lighthouseapp.com/
>
> which seems a lot more user friendly and has out of the box github
> integration. I'm inclined to go for that ... any other opinions?
>
> We need to sort out distribution of administrative control over these
> accounts. I suggest one person for each proto-working group (Alex and
> Jesse maybe?) and one from EPFL (Toni?).
>
> Otherwise, please subscribe/follow at will ...
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

Ismael Juma writes:

[...]

>> I don't know Lighthouse, so it's difficult to compare.
>
> I haven't used it either. From the description, it seemed better than
> the github issue tracker, but hard to say from screenshots alone. Miles,
> do you know any project that has an openly accessible instance?

Lift used to use Lighthouse, seems the project is still there

http://liftweb.lighthouseapp.com/projects/26102-lift

/Jeppe

On Mon, 2009-09-28 at 08:49 +0200, Jeppe Nejsum Madsen wrote:
> Lift used to use Lighthouse, seems the project is still there

Thanks. From a brief look, it seems good enough. For the guys talking
about Mylyn, there is some primitive access:

http://help.lighthouseapp.com/discussions/tips-tricks/25-integrating-ecl...

Best,
Ismael

On Mon, Sep 28, 2009 at 8:17 AM, Ismael Juma wrote:
> On Mon, 2009-09-28 at 08:49 +0200, Jeppe Nejsum Madsen wrote:
>> Lift used to use Lighthouse, seems the project is still there
>
> Thanks. From a brief look, it seems good enough. For the guys talking
> about Mylyn, there is some primitive access:
>
> http://help.lighthouseapp.com/discussions/tips-tricks/25-integrating-ecl...

OK, we now have a Scala Incubator Lighthouse account,

http://scala-incubator.lighthouseapp.com/dashboard

I've set up projects for modularization and I/O.

Cheers,

Miles

On 27 Sep 2009, at 20:09, Miles Sabin wrote:

Hi folks,

A quick update on this ...

I've set up a Google group here,
And a github account here,

Good stuff. I've also got a Git clone which I took off of PaulP earlier on; did you clone from that or SVN import yourself? 

There seem to be numerous recipes out there for mirroring a SVN
repository to github ... if anyone has any specific recommendations
I'd be grateful for suggestions (Paul?).

I suggest that we follow a highly branched model so that the scala-incubator has some kind of 'upstream' branch which tracks the SVN repo. (I guess you found out how to do this OK so far; but if you just followed the GitHub click-and-connect, you'll need to go a bit further to get updates and the like. I followed Google's guide http://code.google.com/p/support/wiki/ExportingToGit)
I added a GitHub remote branch for my Google Code project. Once I'd checked it out locally, I added a remote URL git remote add github git@github.com:alblue/objectiveclipse.git) so that I can make changes and then upload with 'git push github'. You might find other resources talking about 'origin/master' but since it wasn't (to me) the origin then I decided to name it for the site instead.

I'm still undecided about issue trackers. My own experiences with JIRA
(all versions, including the top end commercially supported variant)
are that it's only marginally better than Trac and really pretty
clunky. I've had several recommendations for Lighthouse,

I tried to access http://scala-incubator.lighthouseapp.com/dashboard, but didn't get any joy in resolving the DNS. Might be a caching issue on my box; I'll try again later.
I'm waiting to get the SCLA sorted; once that's done, I'll let you know so I can be added to the scala-incubator github.
Alex

Great stuff Miles,  Thanks for taking the initiative on this. 

I am able to access the lighthouse site without issues.  Looks good to me. 

I am looking a the github account and there is nothing there yet... I assume that it will mirror the SVN repo? Are you taking care of that process?

FYI.  I am going on vacation next week for 3 weeks and hopefully will be able to find more time to work on Scala IO.  I have been swamped here at work getting ready for the vacation.  But worry not I am still on the job :)

Jesse

On Wed, Sep 30, 2009 at 10:47 AM, Jesse Eichar wrote:
> Great stuff Miles,  Thanks for taking the initiative on this.
>
> I am able to access the lighthouse site without issues.  Looks good to me.
>
> I am looking a the github account and there is nothing there yet... I assume
> that it will mirror the SVN repo? Are you taking care of that process?

Yes, that's the intention ... I'm looking for recommendations for the
best way of doing it.

Cheers,

Miles

On Tue, Sep 29, 2009 at 10:39 PM, Alex Blewitt wrote:
> On 27 Sep 2009, at 20:09, Miles Sabin wrote:
> > There seem to be numerous recipes out there for mirroring a SVN
> > repository to github ... if anyone has any specific recommendations
> > I'd be grateful for suggestions (Paul?).
>
> I suggest that we follow a highly branched model so that the scala-incubator
> has some kind of 'upstream' branch which tracks the SVN repo.

Yes, that's the plan ... it's recommendations for maintaining that
mirror that I'm looking for. git-svn hanging off a cron job? Or are
there better alternatives?

Cheers,

Miles

On Wed, 2009-09-30 at 12:08 +0100, Miles Sabin wrote:
> Yes, that's the plan ... it's recommendations for maintaining that
> mirror that I'm looking for. git-svn hanging off a cron job?

If you don't want to clone from an existing git repository (e.g.
Paul's), then that sounds like the way forward. You may also want to
look at svn2git if you care about branches:

http://github.com/jcoglan/svn2git

Best,
Ismael

On Wed, Sep 30, 2009 at 12:29 PM, Ismael Juma wrote:
> On Wed, 2009-09-30 at 12:08 +0100, Miles Sabin wrote:
>> Yes, that's the plan ... it's recommendations for maintaining that
>> mirror that I'm looking for. git-svn hanging off a cron job?
>
> If you don't want to clone from an existing git repository (e.g.
> Paul's), then that sounds like the way forward. You may also want to
> look at svn2git if you care about branches:
>
> http://github.com/jcoglan/svn2git

I looked and saw this,

Removing github support. It's buggy, and I usually have to make some
changes before pushing the new repo online.

Does anyone have any experience with svn2git?

Cheers,

Miles

On Wed, 2009-09-30 at 12:35 +0100, Miles Sabin wrote:
> I looked and saw this,
>
> Removing github support. It's buggy, and I usually have to make some
> changes before pushing the new repo online.

I saw that too and I don't think it matters. I don't know what the
github support actually does, but maybe it does an automatic push at the
end or something. In any case, if you have a git repo locally, you can
push it to github yourself.

> Does anyone have any experience with svn2git?

I used it for Voldemort as it had many branches that were of interest
and it worked fine. The Scala repo is much older and bigger though.

Best,
Ismael

On Wed, Sep 30, 2009 at 12:46 PM, Ismael Juma wrote:
> On Wed, 2009-09-30 at 12:35 +0100, Miles Sabin wrote:
>> I looked and saw this,
>>
>>   Removing github support. It's buggy, and I usually have to make some
>>   changes before pushing the new repo online.
>
> I saw that too and I don't think it matters. I don't know what the
> github support actually does, but maybe it does an automatic push at the
> end or something. In any case, if you have a git repo locally, you can
> push it to github yourself.
>
>> Does anyone have any experience with svn2git?
>
> I used it for Voldemort as it had many branches that were of interest
> and it worked fine. The Scala repo is much older and bigger though.

OK, do we have many EPFL branches which are of interest or is just
trunk sufficient?

Cheers,

Miles

Do we expect the incubator projects to live on much pass the time when they enter scala trunk, or are they migrating?

If they're migrating into scala itself, why do they need to be hooked onto scala trunk at all?  I started trying to test out what this would look like, and actually SBT works great for working with 2.8.0 snapshots and utilizing these across many projects.

Here's my sample project (which I think is a dependency for Scalax.IO) -Scala Automatic-Resource-Management


Anyway, is this what we're looking at as the kind of thing for a scala incubator, or do you want it developed against scala (and therefore its deliverable is scala itself and not really testable with other libraries.....


- Josh

On Wed, Sep 30, 2009 at 7:48 AM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Sep 30, 2009 at 12:46 PM, Ismael Juma <mlists@juma.me.uk> wrote:
> On Wed, 2009-09-30 at 12:35 +0100, Miles Sabin wrote:
>> I looked and saw this,
>>
>>   Removing github support. It's buggy, and I usually have to make some
>>   changes before pushing the new repo online.
>
> I saw that too and I don't think it matters. I don't know what the
> github support actually does, but maybe it does an automatic push at the
> end or something. In any case, if you have a git repo locally, you can
> push it to github yourself.
>
>> Does anyone have any experience with svn2git?
>
> I used it for Voldemort as it had many branches that were of interest
> and it worked fine. The Scala repo is much older and bigger though.

OK, do we have many EPFL branches which are of interest or is just
trunk sufficient?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

You don't need svn2git - git svn can do the work. Let me put some
advice together later when I'm near a bigger keyboard.

Forking paul's github repo might be easier, though.

As for branches, we should have one for each numbered release (like
2.7.5 etc) but I don't think we need many more upstream branches.

Alex

Sent from my (new) iPhone

On 30 Sep 2009, at 12:48, Miles Sabin wrote:

> On Wed, Sep 30, 2009 at 12:46 PM, Ismael Juma
> wrote:
>> On Wed, 2009-09-30 at 12:35 +0100, Miles Sabin wrote:
>>> I looked and saw this,
>>>
>>> Removing github support. It's buggy, and I usually have to make
>>> some
>>> changes before pushing the new repo online.
>>
>> I saw that too and I don't think it matters. I don't know what the
>> github support actually does, but maybe it does an automatic push
>> at the
>> end or something. In any case, if you have a git repo locally, you
>> can
>> push it to github yourself.
>>
>>> Does anyone have any experience with svn2git?
>>
>> I used it for Voldemort as it had many branches that were of interest
>> and it worked fine. The Scala repo is much older and bigger though.
>
> OK, do we have many EPFL branches which are of interest or is just
> trunk sufficient?
>
> Cheers,
>
>
> Miles
>

On Wed, 2009-09-30 at 13:27 +0100, Alex Blewitt wrote:
> You don't need svn2git - git svn can do the work.

Of course it can. svn2git is just a script that calls into git svn after
all.

Best,
Ismael

On Wed, Sep 30, 2009 at 01:27:48PM +0100, Alex Blewitt wrote:
> Forking paul's github repo might be easier, though.

This would be much preferred from my point of view (and I imagine
everyone who has cloned it.) If you rebuild with git-svn, every commit
will have a new SHA-1 hash and so anyone working from my repo will
basically be in an alien repository with all the associated pain. I
experienced this first-hand as I was using my original git-svn repo for
a long time separately from the github clone, but when the time came to
push a branch from the other repo to github, git just laughed. It's
doable (generate patch set, apply patch set) but not enjoyable.

On Wed, Sep 30, 2009 at 3:15 PM, Paul Phillips wrote:
> On Wed, Sep 30, 2009 at 01:27:48PM +0100, Alex Blewitt wrote:
>> Forking paul's github repo might be easier, though.
>
> This would be much preferred from my point of view (and I imagine
> everyone who has cloned it.) If you rebuild with git-svn, every commit
> will have a new SHA-1 hash and so anyone working from my repo will
> basically be in an alien repository with all the associated pain.  I
> experienced this first-hand as I was using my original git-svn repo for
> a long time separately from the github clone, but when the time came to
> push a branch from the other repo to github, git just laughed.  It's
> doable (generate patch set, apply patch set) but not enjoyable.

I suppose my reasoning for spawning yet another github mirror of EPFL
SVN is that I think it's important that we have something which is
unambiguously associated with an official Scala Incubator project and
guaranteed to be a pristine mirror, rather than just being some random
github mirror, which might not be a mirror forever.

Obviously you're an exceptional someone, but even so I'd be a lot
happier with going down this route if you were able to commit to some
sort of involvement in the Scala Incubator.

Cheers,

Miles

On Wed, Sep 30, 2009 at 03:26:31PM +0100, Miles Sabin wrote:
> I suppose my reasoning for spawning yet another github mirror of EPFL
> SVN is that I think it's important that we have something which is
> unambiguously associated with an official Scala Incubator project and
> guaranteed to be a pristine mirror, rather than just being some random
> github mirror, which might not be a mirror forever.

My mirror doesn't have to be the canonical mirror, it would just be nice
if you started from that so you don't invalidate all my existing
patches. You could pull from svn from that point forward. A git-svn
mirror cloned by you doesn't have any better guarantee of being
"pristine" than one cloned by me.

> Obviously you're an exceptional someone, but even so I'd be a lot
> happier with going down this route if you were able to commit to some
> sort of involvement in the Scala Incubator.

I can't commit to any involvement.

On Wed, Sep 30, 2009 at 4:51 PM, Paul Phillips wrote:
> On Wed, Sep 30, 2009 at 03:26:31PM +0100, Miles Sabin wrote:
>> I suppose my reasoning for spawning yet another github mirror of EPFL
>> SVN is that I think it's important that we have something which is
>> unambiguously associated with an official Scala Incubator project and
>> guaranteed to be a pristine mirror, rather than just being some random
>> github mirror, which might not be a mirror forever.
>
> My mirror doesn't have to be the canonical mirror, it would just be nice
> if you started from that so you don't invalidate all my existing
> patches.  You could pull from svn from that point forward.

Gotcha ... that seems reasonable.

> A git-svn mirror cloned by you doesn't have any better guarantee of being
> "pristine" than one cloned by me.

The idea is that it isn't cloned by "me": It's cloned and maintained
by the stakeholders in the Scala Incubator project.

>> Obviously you're an exceptional someone, but even so I'd be a lot
>> happier with going down this route if you were able to commit to some
>> sort of involvement in the Scala Incubator.
>
> I can't commit to any involvement.

A shame, but also reasonable ...

Cheers,

Miles

On Wed, Sep 30, 2009 at 1:27 PM, Alex Blewitt wrote:
> You don't need svn2git - git svn can do the work. Let me put some advice
> together later when I'm near a bigger keyboard.

Have you found a bigger keyboard yet? ;-)

Cheers,

Miles

On 3 Oct 2009, at 16:11, Miles Sabin wrote:

> On Wed, Sep 30, 2009 at 1:27 PM, Alex Blewitt
> wrote:
>> You don't need svn2git - git svn can do the work. Let me put some
>> advice
>> together later when I'm near a bigger keyboard.
>
> Have you found a bigger keyboard yet? ;-)

Heh :-)

OK, so the first piece of advice would be to clone PaulP's repository.
You can do this via GitHub, and probably saves some kind of resources
in doing so (whether that's any kind of back-end optimisations or
simply reduced network bandwidth is back-end dependent). The main
reason for this is that it'll preserve whatever history there has been
to date from Paul's account and make it easier to do merges between
them at some later point. You can then do a git-clone of your new
GitHub repository, and then you're good to go.

Once you do the clone though, there is a question of how you do the
SVN updates. We probably need a canonical Git representation of the
upstream SVN source. We could rely on Paul to do that (in which case,
you can just pull/fetch from him) or we could set up some kind of job
that does the SVN updates.

The way that SVN is configured is in the .git/config directory; you'll
want an entry that looks like the below. The svn-remote is used for
git svn commands; the remote is for other Git repositories. Here's
what my setup looks like for my ObjectivEClipse project:

[svn-remote "svn"]
url = https://objectiveclipse.googlecode.com/svn
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
[remote "github"]
url = git@github.com:alblue/objectiveclipse.git
fetch = +refs/heads/*:refs/remotes/github/*

The first is the SVN mapping, with the URL to fetch. It's using HTTPS
here but that's because I want to push up as well; in the case of
Scala, having a read-only copy is fine as well. The fetch says I'm
mapped to the 'trunk' SVN and the branches are mapped to Git remote
branches (c.f. tags). If the path is different on the SVN distro (e.g.
svn/main) then you'd use fetch=mail:refs/remotes/trunk or similar.

You'll also need a pointer to the current SVN repo. You should have
got this when you cloned Paul's repository, but it'll be in .git/refs/
remotes/trunk and point to an SHA1 hash (git identity) that looks like
d6e7f5cf93bcd34837f25b60e9bb9122346c6785 - if you don't have it, you
can examine the git log to find out the last sync point with SVN and
simply cat the name of the git tree at that point (e.g. from git log)

commit d6e7f5cf93bcd34837f25b60e9bb9122346c6785
Author: rrusaw
Date: Fri Sep 18 01:28:06 2009 +0000

Added initial support for parsing block object expressions with
some simple

git-svn-id: https://objectiveclipse.googlecode.com/svn/trunk@142
b0dc983c-f6

Once you've got your repo, you can add those entries manually to
the .git/config, or use the git svn init to set it up. (You can verify
if the SVN has worked by doing 'git svn info'). You can then do git
svn fetch to pull latest sources, and git push github to get those up
onto github. (I use 'github' as a remote name; if you've just done a
direct clone, it might be called 'origin', which is the default remote
name).

If you're going to do the pulling yourself, then the easiest thing to
do is set up a daily cron job which does this automatically. The SVN
will be read anyway, and you can automate the push by setting up a
passwordless SSH key (instructions via GitHub or http://alblue.blogspot.com/2005/08/howto-ssh-logins-using-keys.html)
and then paste the public key into GitHub's settings page - then as
long as the SSH key is available you should be able to automatically
push)

We probably should set up a branch specifically for tracking the
upstream SVN info (via git branch) instead of doing work on trunk/
head. Then we can pull/merge that into the main scala incubator tree
as needed.

Hope this helps and sorry for the delays in locating a suitable sized
keyboard ...

Alex