> Are there any objections to the choice to remain with JIRA for issue
> tracking
Not from me.
> I would propose that we rely heavily on NHForge.org
Agreed ... even if we changed the underlying server, we should still use that
domain, and point everything else to it. Of note, the old forum does have a
sticky post at the top redirecting to the new Google-group, but it perhaps
doesn’t shout it very clearly (notwithstanding you can’t ‘force’ people to read
anything.)
> * the github ecosystem (e.g., "social coding") is its winning feature
I’m truly ambivalent about git vs. hg, and github vs. bitbucket (if SVN was
super-fast and entirely disconnected, I’d keep it in a heartbeat.) However, I
suspect that given the (very) limited committer resources we have, I think our
single biggest deciding factor when choosing a DVCS hub is going to be choosing
the one that provides the best contribution from the community. (Note, by
‘best’ I mean quality over quantity ... quality patches are rare.)
Unfortunately I don’t think there’s any way you can ‘prove’ which of these is
the beast choice in advance of the decision ... I think we just need to rely on
anecdotal evidence from people who have used both as to how many (high quality)
contributions are received on each; github appears to win on this point.
From: Stephen Bohlen
Sent: Wednesday, August 03, 2011 10:46 PM
To: nhibernate-development
Subject: Re: [nhibernate-development] Re: DCVS
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
>> >>
>> >
>> >
>
>
