I would like to add integration with Visual Studio as a consideration point. Proper integration will reduce the friction and the need to depend upon a separate interface for most common functionality.
John Davidson On Wed, Aug 3, 2011 at 5:46 PM, Stephen Bohlen <[email protected]> wrote: > 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 >> >> >> >> >> > >> >> > >> > >> > >> > >
