IMO the research, suggestions, and confirmations that this thread has
already elicited from several in the community do count as valuable
action/progress so I think we're proceeding not all that poorly thus far.
Once we reach consensus on exactly what we're going to do, hopefully we
should be able to do it in pretty short order.
Of course, my suggestion of 8/15 was just a target for us and if we miss
because we are too careful in making the right choice, I'd prefer to err on
the side of being slower and more certain that we're making the right
selection. That said, your sense of urgency is welcomed (and of course its
the other reason I threw out the date: nothing motivates decision-making
quite like a looming deadline, even if its a completely made-up one <g>).
I think the way to proceed is to divide the choices into several broad
categories (each somewhat independent of each other) and try to reach
agreement on each of them (leading to subsequent action).
Categories:
* issue tracking platform
* project homepage location (e.g., what and where is "NHCentral?")
* source control platform
** Issue Tracking Platform **
It seems that we are tending towards the decision to remain with (the new)
hosted JIRA for issue tracking and that we believe that our hosted platform
has already-available integration modules for either git or hg (almost
certainly the two candidates for DVCS selection). Are there any objections
to the choice to remain with JIRA for issue tracking (assuming it can be
well-integrated to link issues to commits in whatever DVCS we select)?
** Project Homepage location **
One of the major problems I have seen with OSS projects that move around
from platform to platform (even just once!) is that the project's sense of
self gets badly diluted. Old, outdated, abandoned homepages with
incorrect/superseded info, download links, and more make it frustrating for
adopters to find what they are looking for, etc. We have ALREADY
experienced a very tiny part of this phenomenon in the nhibernate forums on
hibernate.org where sometimes people STILL post issues that (obviously) go
unanswered, etc. IMO its very important as part of any move that the
existing project pages, download links, etc. are removed and replaced NOT
with new new links but with a single link to a single authoritative project
space that contains all the info needed to get started with either consuming
or contributing to NHibernate.
I would propose that we rely heavily on NHForge.org for this and adjust the
SF page(s) and links, any new readme files, etc. in any DVCS we select, etc.
to offer only a single link to a starting page on NHForge.org that contains
all info about the project (link to issue tracker, link to downloads, link
to ref docs, etc.). This leaves us with only a single authoritative place
to ensure all links, etc. are correct/updated.
What are people's thoughts on the viability of this suggestion?
** Source Control Platform **
In past discussions, this has become a choice between git and hg. Its
reasonable to assume that this is still the decision-point that remains to
resolve in this area. If there is a third candidate we want to consider,
someone reading this thread please point it out. It also seems reasonable
to conclude that this also boils down to a choice between github or
bitbucket rather than other choices for ecosystems that offer either or both
git and/or hg (e.g., hg on codeplex or git on googlecode, etc.). If this
assumption is incorrect, someone please point that out as well.
Comparing hg vs. git on their technical merits doesn't seem (to me at least)
to yield enough of a difference in any critical must-have feature to be
itself a deciding factor. If anyone feels otherwise, please let us know
("we must choose XYZ because its the only one of the two that has feature
ABC that we really need in order for this project to be a success!").
As this choice between git/github and hg/bitbucket has always been presented
to me, the following seem to be the arguments in favor of the hg/bitbucket
choice:
* hg installs and runs better/simpler on Windows
* this lowers the barrier-to-entry of anyone getting the code and submitting
patches (well, forks in this case, but you get the point <g>)
The frequent arguments advanced in favor of git/github seem to be:
* the github ecosystem (e.g., "social coding") is its winning feature
* this lowers the barrier-to-entry of anyone getting the code and submitting
patches (again, forks!)
Are their other arguments for or against hg or git that we need to
consider? I would like to get as many of them listed here so that we have
as much info as possible upon which to try to reach a consensus. We're
looking for actual pros and cons for this decision, NOT just "+1 for github,
it rocks!" but an actual *reason* one or the other might "rock".
All opinions welcomed (and yes, I realize this is a rehash of other threads
on this very topic, but lets try to get them all in one place one last time
to facilitate making a final choice on this matter).
Thanks, everyone --!
Steve Bohlen
[email protected]
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen
On Wed, Aug 3, 2011 at 11:09 AM, Patrick Earl <[email protected]> wrote:
> I'll wait to do anything then. How should we proceed with reaching a
> decision? I feel a definite sense of urgency since the deadline has
> been selected and we haven't started the work yet.
>
> Patrick Earl
>
> On Wed, Aug 3, 2011 at 7:15 AM, Stephen Bohlen <[email protected]> wrote:
> > It should be noted that while all this research is extremely valuable and
> > quite helpful, no actual decision has been reached re: what changes we're
> > actually going to be making at this early point in the process :)
> >
> > -Steve B.
> > ________________________________
> > From: Mauricio Scheffer <[email protected]>
> > Sender: [email protected]
> > Date: Wed, 3 Aug 2011 09:52:37 -0300
> > To: <[email protected]>
> > ReplyTo: [email protected]
> > Subject: Re: [nhibernate-development] Re: DCVS
> > Yes, I can pull any last minute commits.
> > You can store the filter-branch script in a gist, no need for a full
> > repository...
> >
> > --
> > Mauricio
> >
> >
> > On Wed, Aug 3, 2011 at 2:30 AM, Patrick Earl <[email protected]> wrote:
> >>
> >> This is great advice. Thanks Mauricio. I found an article that gives
> >> some tips on how to accomplish the tag thing you mentioned, as well as
> >> some other clean-ups.
> >>
> >> http://thomasrast.ch/git/git-svn-conversion.html
> >>
> >> Based on what you've said, it sounds like we need to do at least a
> >> couple things.
> >>
> >> 1. Have committers sign up for github accounts so the history can be
> >> mapped nicely. Unless more mass user actions come up, it seems like a
> >> good idea to start a separate urgent thread to have committers provide
> >> their details for the conversion.
> >>
> >> 2. Write a script that will convert your repository appropriately.
> >> Is it safe to assume that you'll be able to pull any last minute
> >> changes from SVN into your repo? I propose that we set up a GIT
> >> repository to store the script to be used for the conversion. We can
> >> then refine it and learn a bit along the way.
> >>
> >> If nobody else does it, I'll do these things tomorrow to get the ball
> >> rolling.
> >>
> >> Patrick Earl
> >>
> >> On Tue, Aug 2, 2011 at 1:46 PM, Mauricio Scheffer
> >> <[email protected]> wrote:
> >> > It's not really *required* to do this mapping, it's only very
> convenient
> >> > so
> >> > that github can create links from every commit to the committer
> account,
> >> > and
> >> > also for future statistics.
> >> >
> >> > Another thing to decide is what to do about tags. Git-svn models tags
> as
> >> > separate commits (because each svn tag creates a new revision), but
> >> > that's
> >> > not how git usually handles tags. You could go over each tag and
> >> > redefine
> >> > it, e.g. instead of the 3.1.0GA tag being here :
> >> >
> >> >
> https://github.com/mausch/NHibernate/commit/a971c20f9be652a59bc467d8e61bbad2f2928ef3
> >> > as a separate commit, it would be here:
> >> >
> >> >
> https://github.com/mausch/NHibernate/commit/3c2d5fdbeeebc87f089bac2306792b8ef4459a81
> >> > which is the commit before that. Clone the repository and use gitk to
> >> > better
> >> > visualize this.
> >> > Also, tags in git can be lightweight, annotated or even
> >> > cryptographically
> >> > signed if you're really paranoid about people redistributing code with
> >> > edited tags.
> >> >
> >> > --
> >> > Mauricio
> >> >
> >> >
> >> > On Tue, Aug 2, 2011 at 4:27 PM, Mauricio Scheffer
> >> > <[email protected]> wrote:
> >> >>
> >> >> Right now, on my github mirror all committers have names
> autogenerated
> >> >> by
> >> >> git-svn. For example: "patearl
> >> >> <patearl@d2eaab8a-a80d-0410-be94-99ecdb4ea5df>".
> >> >> Git filter-branch should be used to change all commits and map those
> >> >> autogenerated names to the actual github accounts (e.g. the email
> used
> >> >> for
> >> >> https://github.com/patearl ), otherwise all commits are pretty much
> >> >> anonymous, detached from their actual owners.
> >> >> Here's a sample script that does this for a single user:
> >> >> http://progit.org/book/ch6-4.html#changing_email_addresses_globally
> >> >> The filter-branch docs also has some examples about this:
> >> >>
> http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
> >> >>
> >> >> Cheers,
> >> >> Mauricio
> >> >>
> >> >>
> >> >> On Tue, Aug 2, 2011 at 4:00 PM, Patrick Earl <[email protected]>
> wrote:
> >> >>>
> >> >>> On Tue, Aug 2, 2011 at 10:35 AM, Mauricio Scheffer
> >> >>> <[email protected]> wrote:
> >> >>> > If NHibernate decides to move to git, you might be interested in
> my
> >> >>> > github mirror: https://github.com/mausch/NHibernate , which
> contains
> >> >>> > of course the whole history, is up to date, and has all tags and
> >> >>> > branches.
> >> >>>
> >> >>> That sounds great Mauricio. Thanks for the heads up.
> >> >>>
> >> >>> > All that would be needed to complete the migration is mapping the
> >> >>> > committers to their proper github accounts (which isn't hard, just
> >> >>> > some filter-branches, doesn't take too long). So the slowest part
> >> >>> > (migrating the actual commits from SVN to git) is already done.
> >> >>>
> >> >>> Can you suggest what you mean here to do the mapping? It sounds
> like
> >> >>> you have a very clear idea of what needs to be done.
> >> >>>
> >> >>> > Of course, tooling support is a separate issue. I don't know what
> >> >>> > tools NHibernate currently uses that depend on SVN (could be nant
> >> >>> > for
> >> >>> > tagging, TeamCity, JIRA integration, ...)
> >> >>>
> >> >>> TeamCity has built-in GIT support, so that shouldn't be a problem.
> >> >>> The releases haven't even been using the SVN revision for the
> version
> >> >>> number, so we're more or less okay on that front. We don't have
> JIRA
> >> >>> set up with any VCS integration right now, so integrating would only
> >> >>> be an improvement. Do we have some sort of script or anything to
> run
> >> >>> tagging on release? The release process is a mystery to me
> >> >>> personally. :)
> >> >>>
> >> >>> Patrick Earl
> >> >>
> >> >
> >> >
> >
> >
>
