Mailing List Archive

> Why not just move to GitHub and be done with it?

+1

On Sat, 4 Apr 2009, David E. Wheeler wrote:
> This week, I moved pgTAP to [GitHub][]. To answer [Brad's questions][] when
> we last discussed GitHub, Git is still a completely distributed system: the
> GitHub tree is just the master tree. Anyone can clone it and send patches,
> or, if they're GitHub users, fork it, make changes, and push them upstream to
> the master. So I could quite easily import all of the Bricolage Subversion
> history into GitHub right now.
>
> [GitHub]: http://github.com/theory/pgtap/tree/master
>
> [Brad's questions]:
> http://www.gossamer-threads.com/lists/bricolage/devel/34997#34997
>
> So, why wouldn't we do this? We would never need to add committers again, and
> it's much easier for anyone to start participating. There's even an
> integrated wiki, and it's free for Open-Source projects like ours. I've been
> using Subversion since 1.0, but Git, once I started to wrap my brain around
> it, seems pretty damned great. Why not just move to GitHub and be done with
> it?

Why not? I need some practice with git. ^.^

On 4-Apr-09, at 1:59 PM, Beaudet, David wrote:

>>
>> Why not just move to GitHub and be done with it?
>
> +1

No complaints here, as I've not actually done anything vis-a-vis
migrating the old wiki to the new Trac one yet. :-(

However, what would we use for bug / issue reporting?

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

> However, what would we use for bug / issue reporting?

Open source projects and educational institutions can get a free Jira license.

On Apr 4, 2009, at 10:38 AM, Phillip Smith wrote:

> No complaints here, as I've not actually done anything vis-a-vis
> migrating the old wiki to the new Trac one yet. :-(
>
> However, what would we use for bug / issue reporting?

What are the limitations for OSS projects using Lighthouse?

David

On 4-Apr-09, at 4:22 PM, David E. Wheeler wrote:

> On Apr 4, 2009, at 10:38 AM, Phillip Smith wrote:
>
>> No complaints here, as I've not actually done anything vis-a-vis
>> migrating the old wiki to the new Trac one yet. :-(
>>
>> However, what would we use for bug / issue reporting?
>
> What are the limitations for OSS projects using Lighthouse?

I guess I just wonder what happens if Lighthouse disappears... would
prefer to see something F/LOSS so that there's an exit strategy.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Apr 4, 2009, at 12:42 PM, Phillip Smith wrote:

>> What are the limitations for OSS projects using Lighthouse?
>
> I guess I just wonder what happens if Lighthouse disappears... would
> prefer to see something F/LOSS so that there's an exit strategy.

Like with Bugzilla? Ugh.

D

On Sat, Apr 04, 2009 at 09:36:35AM -0700, David E. Wheeler wrote:
> Hi All,
>
> This week, I moved pgTAP to [GitHub][]. To answer [Brad's questions][]
> when we last discussed GitHub, Git is still a completely distributed
> system: the GitHub tree is just the master tree. Anyone can clone it
> and send patches, or, if they're GitHub users, fork it, make changes,
> and push them upstream to the master. So I could quite easily import
> all of the Bricolage Subversion history into GitHub right now.
>
> [GitHub]: http://github.com/theory/pgtap/tree/master
>
> [Brad's questions]:
> http://www.gossamer-threads.com/lists/bricolage/devel/34997#34997
>
> So, why wouldn't we do this? We would never need to add committers
> again, and it's much easier for anyone to start participating. There's

Though... this is typcial of distributed SCMs, not only git.

> even an integrated wiki, and it's free for Open-Source projects like
> ours. I've been using Subversion since 1.0, but Git, once I started to
> wrap my brain around it, seems pretty damned great. Why not just move
> to GitHub and be done with it?

git is -still- not a native Windows-friendly version (in fact, there are two forks, as I understand, trying solve this; one native to Windows, one for Cygwin).

I'm personally quite a fan of fossil (http://fossil-scm.org), or secondly, mercurial (http://www.selenic.com/mercurial/wiki/).

Fossil has an integrated wiki, and ticket system (indeed, Richard Hipp, principle author of fossil is also the author of CVSTrac). It's portable (I run on NetBSD, Linux, MacOS X, and Windows), a single binary, and I trust it.

Mercurial is also a single program (Python script), and _was_ my favourite until I discovered fossil.

I'd say either fossil or mercurial are easier to use than git (my opinion), and this reduces the barrier to entry. Both are also portable (further reducing barrier to entry). Fossil has the additional benefits of integrated wiki and ticket system, which follow the repository.

Not sure if there are other considerations for moving to git, or if github itself sweetens the deal any... I'd be curious to know, though!

-bch

--

Brad Harder,
Method Logic Digital Consulting
http://www.methodlogic.net

On Apr 4, 2009, at 1:50 PM, bharder wrote:

>> So, why wouldn't we do this? We would never need to add committers
>> again, and it's much easier for anyone to start participating.
>> There's
>
> Though... this is typcial of distributed SCMs, not only git.

What's nice about GitHub is the social aspect to it. Anyone can "fork"
a project, creating a repo of the project for their very own, and
commit to it as if they owned it. Then, when they're ready to get
their changes into the canonical repository, they can just send a
"pull request." I think that this makes the barrier to joining the
project and contributing (not to mention maintaining your own
distribution, as, e.g., Digital Craftsmen might want to do) much,
*much* simpler.

That said, gitorious might have the same features. I honestly have no
idea; all the Perl people I respect are jumping all over GitHub, which
says a lot to me. Anyone have experience with Gitorious?

>> it is -still- not a native Windows-friendly version (in fact, there
>> are two forks, as I understand, trying solve this; one native to
>> Windows, one for Cygwin).
>
> I'm personally quite a fan of fossil (http://fossil-scm.org), or
> secondly, mercurial (http://www.selenic.com/mercurial/wiki/).

This doesn't bother me in the slightest. Who uses Bricolage on
Windows? You can't even run the test suite there, can you?

> Fossil has an integrated wiki, and ticket system (indeed, Richard
> Hipp, principle author of fossil is also the author of CVSTrac).
> It's portable (I run on NetBSD, Linux, MacOS X, and Windows), a
> single binary, and I trust it.

If it's as ugly as sqlite.org, feh.

> Mercurial is also a single program (Python script), and _was_ my
> favourite until I discovered fossil.

There's a reason Mercurial is on its way out, no?

> I'd say either fossil or mercurial are easier to use than git (my
> opinion), and this reduces the barrier to entry. Both are also
> portable (further reducing barrier to entry). Fossil has the
> additional benefits of integrated wiki and ticket system, which
> follow the repository.

Git is not at all hard to use. It was tricky for me because I have to
think about it differently than I do SVN, but if you're familiar with
Mercurial or Fossil, I wouldn't think you'd have that problem.

> Not sure if there are other considerations for moving to git, or if
> github itself sweetens the deal any... I'd be curious to know, though!

Yeah, GitHub is pretty sweet. See also http://use.perl.org/~schwern/journal/38478
.

Best,

David

Hi,

On Sat Apr 04 10:38:10, Phillip Smith wrote:
> However, what would we use for bug / issue reporting?

We just migrated away from Trac to Redmine and really like it.

http://www.redmine.org/

Has subversion and git integration support.

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>

I used Redmine for a while but it can't handle git branches, and after
a while it decided it quit reading our repo entirely. Also, I think
the repo has to be on the same box as Redmine, which is an issue if we
wanted to have Perl or GitHub host the canonical repo.

On Apr 5, 2009, at 1:50 PM, Alex Krohn wrote:

> Hi,
>
> On Sat Apr 04 10:38:10, Phillip Smith wrote:
>> However, what would we use for bug / issue reporting?
>
> We just migrated away from Trac to Redmine and really like it.
>
> http://www.redmine.org/
>
> Has subversion and git integration support.
>
> Cheers,
>
> Alex
>
> --
> Alex Krohn <alex@gossamer-threads.com>
>

On Apr 4, 2009, at 3:42 PM, Phillip Smith wrote:

> I guess I just wonder what happens if Lighthouse disappears... would
> prefer to see something F/LOSS so that there's an exit strategy.

I wouldn't worry too much about that. GitHub and Lighthouse are run by
leaders in the Rails community and they use it for Rails itself, so I
doubt it's going anywhere.

--
Marshall

On 5-Apr-09, at 6:08 PM, Marshall Roch wrote:

> On Apr 4, 2009, at 3:42 PM, Phillip Smith wrote:
>
>> I guess I just wonder what happens if Lighthouse disappears...
>> would prefer to see something F/LOSS so that there's an exit
>> strategy.
>
> I wouldn't worry too much about that. GitHub and Lighthouse are run
> by leaders in the Rails community and they use it for Rails itself,
> so I doubt it's going anywhere.

That's a helpful endorsement. And, I guess many of us would have local
copies of the git repository, should it ever need to be moved.
However, on the Lighthouse front, it looks like they've been "working"
on some basic features like a ticket exporter for over two years now,
which worries me a bit... and some of their recent performance issues
also are concerning (http://hoth.entp.com/2009/3/3/choppy-waters-around-the-lighthouse
and http://lhstatus.com/).

Just want to avoid something like this down the road: http://ma.gnolia.com/

Some other options we may want to explore (after a few minutes of
Googling, not personal experience):

Git-specific:
http://wiki.github.com/schacon/ticgit
http://wiki.github.com/schacon/ticgit/ticgitweb

Or... Jira
http://www.atlassian.com/software/jira/licensing.jsp#nonprofit
http://confluence.atlassian.com/display/JIRAEXT/Jira+Git+Plugin

Or... Trac
http://trac.edgewall.org/wiki/PluginList#VersionControlSystems

Lighthouse App looks fine too, but just want to ensure we've looked at
the other options.

Thoughts?

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Apr 5, 2009, at 3:00 PM, Phillip Smith wrote:

> That's a helpful endorsement. And, I guess many of us would have
> local copies of the git repository, should it ever need to be moved.
> However, on the Lighthouse front, it looks like they've been
> "working" on some basic features like a ticket exporter for over two
> years now, which worries me a bit... and some of their recent
> performance issues also are concerning (http://hoth.entp.com/2009/3/3/choppy-waters-around-the-lighthouse
> and http://lhstatus.com/).

There is an API; I wouldn't think it'd take too long to script up
something to export stuff.

http://lighthouseapp.com/api

> Just want to avoid something like this down the road: http://ma.gnolia.com/

I heard that.

> Some other options we may want to explore (after a few minutes of
> Googling, not personal experience):
>
> Git-specific:
> http://wiki.github.com/schacon/ticgit
> http://wiki.github.com/schacon/ticgit/ticgitweb

How does one submit a bug report with that?

> Or... Jira
> http://www.atlassian.com/software/jira/licensing.jsp#nonprofit
> http://confluence.atlassian.com/display/JIRAEXT/Jira+Git+Plugin

Would that integrate with GitHub?

> Or... Trac
> http://trac.edgewall.org/wiki/PluginList#VersionControlSystems

The more I use Trac, the more I hate it.

> Lighthouse App looks fine too, but just want to ensure we've looked
> at the other options.

I've not used it, but people I respect seem to like it. I'm sure it
will be deficient in some way.

Best,

David

On 5-Apr-09, at 11:14 PM, David E. Wheeler wrote:

>> Some other options we may want to explore (after a few minutes of
>> Googling, not personal experience):
>>
>> Git-specific:
>> http://wiki.github.com/schacon/ticgit
>> http://wiki.github.com/schacon/ticgit/ticgitweb
>
> How does one submit a bug report with that?


No idea...


>> Lighthouse App looks fine too, but just want to ensure we've looked
>> at the other options.
>
> I've not used it, but people I respect seem to like it. I'm sure it
> will be deficient in some way.



The more I think about it, the more I think: let's just jump in and
figure it out with GitHub and Lighthouse. The project isn't about the
repository and the bug tracker: it's about the product and the
community. If those tools make it easier for people to get involved,
and if they don't make you (David) and the other regular contributors
run away, there's really no downside.

The upside is more involvement, easier learning curve, and being "in
sync" with the tools that more contemporary projects are using.

Anyone going to loose sleep at night if Bricolage moved to GitHub +
Lighthouse?

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Apr 6, 2009, at 6:54 PM, Phillip Smith wrote:

> The more I think about it, the more I think: let's just jump in and
> figure it out with GitHub and Lighthouse. The project isn't about
> the repository and the bug tracker: it's about the product and the
> community. If those tools make it easier for people to get involved,
> and if they don't make you (David) and the other regular
> contributors run away, there's really no downside.

The only one I can see is if the complete Bricolage repository (just
Bricolage, its branches, and tags, *not* the other stuff that's in
Subversion, which can all go into separate repositories) is larger
than 100MB. I'm going to be figuring out how to combine moved
directories from SVN for activitymail into a git repo ([more here][])
in the next few days, and once I do, I'll do the same for Bricolage
and see how big it is.

[more here]: http://support.github.com/discussions/repos/532-how-can-i-import-a-moved-svn-repository

> The upside is more involvement, easier learning curve, and being "in
> sync" with the tools that more contemporary projects are using.

Right.

> Anyone going to loose sleep at night if Bricolage moved to GitHub +
> Lighthouse?

I'll loose a few nights doing the migration to Git, but that will be
it. I'm less sure about the Lighthouse migration, though. Anyone
familiar with moving from Bugzilla to Lighthouse? And, also, it looks
like only two of us can admin it; is that true?

Thanks,

David

On Apr 7, 2009, at 1:14 AM, David E. Wheeler wrote:

> The only one I can see is if the complete Bricolage repository (just
> Bricolage, its branches, and tags, *not* the other stuff that's in
> Subversion, which can all go into separate repositories) is larger
> than 100MB.

The Open Source plan starts with 300MB now, but "The 300MB is a soft
limit setup to prevent abuse of the service. If your open source
project needs more space, email us, we're happy to provide it." (http://github.com/plans
)

--
Marshall

On 5/4/09 04:48, David E. Wheeler wrote:
> On Apr 4, 2009, at 1:50 PM, bharder wrote:
>
>>> So, why wouldn't we do this? We would never need to add committers
>>> again, and it's much easier for anyone to start participating. There's
>>
>> Though... this is typcial of distributed SCMs, not only git.
>
> What's nice about GitHub is the social aspect to it. Anyone can "fork" a
> project, creating a repo of the project for their very own, and commit
> to it as if they owned it. Then, when they're ready to get their changes
> into the canonical repository, they can just send a "pull request." I
> think that this makes the barrier to joining the project and
> contributing (not to mention maintaining your own distribution, as,
> e.g., Digital Craftsmen might want to do) much, *much* simpler.

I can't foresee any situation under which we'd want to do this but then
I am very shortsighted :-)

Do we really have a problem with participation, in the sense of the
current VCS being a barrier to it ?

I'm yet to be convinced that Git offers benefits for 'product'
development, which is what we're engaged in. It certainly works very
well for a mass of closely connected things that make a distribution,
i.e. Linux, but I fear that unintended things might happen as a result
of a freely forkable project.

I think the two things I'd be most concerned about are:

1. People doing lots of work to add something we don't want to put in
the core product (now you have an unhappy developer or you have a fork
of the product and a diluted effort)

There's nothing to stop someone doing that now of course but the git
model seems to imply that it's encouraged.

2. We add a burden on the core team to integrate changesets into the
core product and then maintain them in the future

This reminded me of a post I read recently that sums up my concerns
quite nicely:

http://deflatermouse.livejournal.com/148975.html

I guess what I'm talking about is a change in the development model that
is more than just which VCS we use. I'm not convinced that the problems
we think we have will be solved by moving to git. I'm not even certain
what problems we think we have in this area :-)

On 7/4/09 02:54, Phillip Smith wrote:

> Anyone going to loose sleep at night if Bricolage moved to GitHub +
> Lighthouse?

Not particularly since I guess we're not the people who will need to do
that work. I'm nervous that it's a solution in search of a problem but I
can also see that there's a certain 'freshness' to moving it the latest
thing. I'm also very aware that as I don't use git I'm not familiar with
it. I'm happy to see how it pans out and it'll be a good opportunity to
learn git.

S.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/

On Apr 7, 2009, at 3:48 AM, Simon Wilcox wrote:

> I can't foresee any situation under which we'd want to do this but
> then I am very shortsighted :-)
>
> Do we really have a problem with participation, in the sense of the
> current VCS being a barrier to it ?

Right now it's a PITA to give someone a commit bit. With GitHub, all
someone has to do is create an account and then fork the project. I
don't have to do anything (and neither does Robert Spier).

> I'm yet to be convinced that Git offers benefits for 'product'
> development, which is what we're engaged in. It certainly works very
> well for a mass of closely connected things that make a
> distribution, i.e. Linux, but I fear that unintended things might
> happen as a result of a freely forkable project.
>
> I think the two things I'd be most concerned about are:
>
> 1. People doing lots of work to add something we don't want to put
> in the core product (now you have an unhappy developer or you have a
> fork of the product and a diluted effort)

Well, someone who doesn't discuss things on the list to get buyin gets
what they ask for. At least with GitHub, if this happens, it's a *lot*
easier for them to maintain a fork by regularly pulling changes from
the original. Right now, maintaining patches is a huge PITA.

> There's nothing to stop someone doing that now of course but the git
> model seems to imply that it's encouraged.

Yes. But this isn't "forking" in the sense of multiple BSDs. It's more
like branching, only easier. And, yeah, a fork can become a permanent
fork, but in practice that doesn't seem to be the case.

> 2. We add a burden on the core team to integrate changesets into the
> core product and then maintain them in the future

This is already an issue. Either we accept patches and then maintain
they changes they bring, or we don't. Using GitHub makes no difference
here, except that it's a lot easier to accept patches or pull requests.

> This reminded me of a post I read recently that sums up my concerns
> quite nicely:
>
> http://deflatermouse.livejournal.com/148975.html

Given the number of patches you guys maintain right now, wouldn't
creating a "silo" on GitHub be a hell of a lot easier for maintenance
purposes? As for this:

> No matter how good the tools are I don't want to be spending time
> tracking fixes and feature patches round various Git repositories
> and assembling my own custom version.

I don't think that's happening in practice. It happened for httpd in
the old days because it was the only thing around. The fact that
Apache came along and eliminated that problem shows that people prefer
canonical versions.

But if someone decides to fork, hell, maybe they'll come up with
something good that we can pull back in. At this point, I don't care
what anyone does with the code base. So we might as well make it as
easy for them as possible to go crazy widit.

> I guess what I'm talking about is a change in the development model
> that is more than just which VCS we use. I'm not convinced that the
> problems we think we have will be solved by moving to git. I'm not
> even certain what problems we think we have in this area :-)

I want to make it easier for me to maintain the code, to integrate
patches, to do merges, etc. Right now things work reasonably well
because I've worked hard in the past to make sure of it. But I'm tired
of it, and Git will make *my* job easier.

Best,

David

On 7/4/09 17:31, David E. Wheeler wrote:
> But I'm tired of it, and Git will make *my* job easier.

Sold :-)

S.

On 7-Apr-09, at 1:55 PM, Simon Wilcox wrote:

> On 7/4/09 17:31, David E. Wheeler wrote:
>> But I'm tired of it, and Git will make *my* job easier.
>
> Sold :-)


+1

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com