One more twist on the old repo: a comment line could be added at the top of every file too. Something along the lines of:
//YOU ARE SEEING AN OUTDATED VERSION OF THIS FILE //The new NHibernate repository can be found at https://github.com/nhibernate/nhibernate-core Diego On Fri, Aug 19, 2011 at 08:30, Stephen Bohlen <[email protected]> wrote: > re: nhforge, there already are links ("Download NH3.2.0", "Getting > Started", "Find answers in our forums", etc.) that handle most of the > user-oriented actions so I think we're (perhaps) just talking about adding a > "get the source" link or similar to the main section of the homepage there. > If anyone wants to replace the text-based links with more obvious 'button > graphics' or some-such, I'd certainly be in favor of that effort (to > increase the prominence of these links for newcomers to nhforge). I can see > the argument that displaying them as text links doesn't result in their > being featured prominently enough to get a visitor's attention quickly. > > I would (perhaps) suggest also that we consider doing something about the > "Downloads" menu item b/c its both full of mostly outdated content *and* > misleading in that it makes one think that's where I'd go to download NH. > Perhaps we change the menu item to "Community-posted downloads" or > something...? it looks like the community has begun to post downloads here > that are really available elsewhere (SF, etc.), probably because navigating > SF to find the downloads is too annoying/difficult. > > Since the page pointed to by the "Downloads" menu ( > http://nhforge.org/media/) seems to mostly contain bins for things like NH > Spatial, NHV, Castle AR, FluentNH, etc., it seems clear to me that having a > central source for authoritative links to the latest bins/packages for the > broader NH 'universe' of related projects would be valuable. > > To accommodate this need, I would suggest that we consider changing the > link on the homepage that reads "Download NH3.2.0" from linking directly to > the NH GA bins to instead redirecting to some pre-authored page on nhforge > that contains a more comprehensive collection of download links (latest NH > GA, each of the latest NHContrib bin packages, FluentNH, uNHAddins, ConfORM, > whatever) all organized and categorized/labeled to make it easy for someone > to find whatever NH-related download they are seeking. To make it simple to > permalink to this one page, I propose that this page url be just > http://nhforge.org/downloads/ or something equally simple to > remember/share with others. Then we need to just maintain the currency of > the links on this one page as downloads are updated, etc. over time (the > homepage need not change). > > This -- the redesign of elements of nhforge to increase clarity of > navigation/cohesiveness of user experience -- is certainly a useful > discussion, but IMO its somewhat off-topic for the more narrow pressing > discussion of VCS choice. > > Getting back to that, re: the disposition of the SVN repo my vote would be > to use the approach suggested earlier of adding the > OBSOLETE_DO_NOT_USE_THIS_REPO.txt file (or sim.) message to every folder and > deleting the .csproj, .sln, NANT, binary references, etc. content (e.g. > pretty much everything but the .cs files) so that existing links retain > their proper function but anyone checking out from the repo is left with an > unbuildable tree. > > This will permit existing permalinks (well, as we're discussing, clearly > NOT perma- at all <g>) to remain navigable/intact for blog posts, etc. while > providing a non-ignorable flag-in-your-face about where the authoritative > repo has been relocated. > > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > > On Thu, Aug 18, 2011 at 8:53 PM, Patrick Earl <[email protected]> wrote: > >> Given that github doesn't have download metrics and NHForge doesn't >> have bandwidth, I think it makes sense to leave the files on SF.net. >> I also agree strongly about providing obvious download links on >> nhforge.org. As far as I'm concerned, SF.net should be nearly >> invisible, since it's hard to navigate, ugly, and not really providing >> much in the way of services to us anyways. >> >> Regarding the repository, it sounds like various people have linked to >> the old repository. I think it would be worth considering simply >> turning off the SVN service. There would be no question of the >> authoritative source if the SVN repository was simply not present. >> This would prevent stale links to old versions of the source. >> Granted, if the links already specify the revision, then this isn't so >> problematic. That said, is there really that much in the way of >> linkage that's worth preserving? Losing a number of links is in my >> mind less important than being unambiguous about the home. Many times >> in the past I've been looking for the project repo and I have come >> across a stale one first. On the same train of thought, we should >> have big obvious links to our major web sections from the main page of >> the nhforge site... downloads, reporting issues (not just jira, but a >> page that tells HOW to do it), source control, and the rest of the >> nhforge content. >> >> Patrick Earl >> >> On Thu, Aug 18, 2011 at 6:20 PM, Stephen Bohlen <[email protected]> >> wrote: >> > Yeah, thought not :) >> > >> > Given the constraints we have, I think the answer is probably "leave the >> > downloads where they are on SF" for now. Its already in place, works >> fine, >> > and its location is common knowledge among present adopters. >> > >> > We might want to more prominently feature the links on nhforge to the >> > downloads on SF, but otherwise I'd probably argue for leaving all else >> > as-is. >> > >> > Choosing a different VCS can probably be done without really needing to >> make >> > changes to any other aspects (JIRA, downloads, whatever) of the >> > infrastructure. >> > >> > There's probably a separate long-term conversation about centralizing >> > everything under one roof/hoster/system/domain but its sounding to me >> like >> > this needs to be a different decision process not on the critical path >> for >> > our resolving the VCS issue amongst ourselves. >> > >> > Does this seem reasonable? >> > >> > -Steve B. >> > ________________________________ >> > From: John Davidson <[email protected]> >> > Sender: [email protected] >> > Date: Thu, 18 Aug 2011 19:58:09 -0400 >> > To: <[email protected]> >> > ReplyTo: [email protected] >> > Subject: Re: [nhibernate-development] VCS Vote >> > NHForge definitely does not have the bandwidth capacity to manage the >> > download volume. >> > John Davidson >> > >> > On Thu, Aug 18, 2011 at 7:27 PM, Stephen Bohlen <[email protected]> >> wrote: >> >> >> >> I fear that the issue with nhforge-hosted downloads is both bandwidth >> and >> >> metrics-capture (both of which SF does handle just fine for the most >> part). >> >> Is there an (easy) way to capture metrics from nhforge? >> >> >> >> People are used to going to SF for downloads and prominent links to SF >> >> download pages from nhforge for new adopters starting at nhforge seem >> like >> >> an ok compromise to me. >> >> >> >> -Steve B. >> >> >> >> ________________________________ >> >> From: Julian Maughan <[email protected]> >> >> Sender: [email protected] >> >> Date: Fri, 19 Aug 2011 07:18:25 +0800 >> >> To: <[email protected]> >> >> ReplyTo: [email protected] >> >> Subject: Re: [nhibernate-development] VCS Vote >> >> >> >> +1 for consolidation then :) >> >> >> >> That tends to suggest to me that hosting downloads on SF would be a bad >> >> idea. If release downloads are to be regarded as a front-of-shop >> concern >> >> (which I think they should), can't we host releases on the NHForge >> server? >> >> The user then doesn't have to be redirected to an unrelated, >> ad-sponsored >> >> page on SF (at the back-of-shop, to continue the analogy) >> >> >> >> On 19/08/2011 6:56 AM, "Stephen Bohlen" <[email protected]> wrote: >> >> > Agreed. I'd posited early on that along w a move to *some* VCS >> hosting >> >> > provider we needed to consolidate the all else around NHForge so that >> all >> >> > existing deprecated resources could simply point to NHForge as a hub >> from >> >> > which links to all else (JIRA, downloads, whatever) could emanate. >> >> > >> >> > With JIRA remaining hosted by Atlassian, source somewhere (yet to be >> >> > decided), what other than downloads still needs a 'home' at this >> point? >> >> > >> >> > -Steve B. >> >> > -----Original Message----- >> >> > From: Julian Maughan <[email protected]> >> >> > Sender: [email protected] >> >> > Date: Fri, 19 Aug 2011 06:48:15 >> >> > To: <[email protected]> >> >> > Reply-To: [email protected] >> >> > Subject: Re: [nhibernate-development] VCS Vote >> >> > >> >> > I just think if the project infrastructure is too fragmented, it will >> >> > become >> >> > confusing. I think we can divide the infrastructure into two >> categories: >> >> > front-of-shop and back-of-shop. I think it is important there is one >> >> > place >> >> > users go for downloads, doco, etc. (NHForge). The back-of-shop stuff >> - >> >> > eg >> >> > (VCS, bug-tracker) - it doesn't matter so much. That is the reason I >> >> > raised >> >> > the question about download hosting. >> >> > On 19/08/2011 6:37 AM, "Stephen Bohlen" <[email protected]> wrote: >> >> >> Yeah, some time ago (early on in this last attempt at this) I >> pointed >> >> >> out >> >> > that there are indeed two distinct categories in which we're trying >> to >> >> > make >> >> > a decision: VCS specifically and project infrastructure more broadly >> >> > (issue >> >> > tracking, announcements, etc). >> >> >> >> >> >> Even if we go to github for VCS, I'm not sure this precludes our >> >> >> retaining >> >> > sourceforge + nhforge in the other roles (e.g., as we were already >> >> > discussing earlier today re: central hub for downloads, etc ). >> >> >> >> >> >> Couldn't a move to github for VCS leave all else exactly as-is and >> be a >> >> > (relatively) non-invasive change (wondering....)? >> >> >> >> >> >> -Steve B. >> >> >> -----Original Message----- >> >> >> From: Julian Maughan <[email protected]> >> >> >> Sender: [email protected] >> >> >> Date: Fri, 19 Aug 2011 06:24:45 >> >> >> To: <[email protected]> >> >> >> Reply-To: [email protected] >> >> >> Subject: Re: [nhibernate-development] VCS Vote >> >> >> >> >> >> +1 >> >> >> >> >> >> I don't have a problem with git or using GitHub as a source code >> host. >> >> >> However, GitHub doesn't seem as good as Google Code or CodePlex in >> >> > offering >> >> >> a project 'home'. Larger projects like NServiceBus, that use GitHub >> for >> >> >> their source, often have a strong alternative web presence with >> their >> >> >> website. If we use GitHub, I believe NHForge will need to be >> improved >> >> >> to >> >> >> become a better project home. Do we have the resources for this >> >> > improvement? >> >> >> Maybe not. >> >> >> On 19/08/2011 3:28 AM, "Richard Brown" <[email protected]> >> wrote: >> >> >>> Oops, sorry. I should have read more carefully. >> >> >>> On 18 Aug 2011 20:25, "Fabio Maulo" <[email protected]> wrote: >> >> >>>> The meaning is: >> >> >>>> -1 = Do not use the github repository, find another alternative. >> >> >>>> >> >> >>>> On Thu, Aug 18, 2011 at 3:23 PM, Richard Brown >> >> >>>> <[email protected] >> >> >>>>wrote: >> >> >>>> >> >> >>>>> Is that -1 for github? Or -1 for this specific branch? >> >> >>>>> >> >> >>>>> (just checking there isn't something wrong with the import I >> wasn't >> >> >> aware >> >> >>>>> of.) >> >> >>>>> On 18 Aug 2011 19:11, "Fabio Maulo" <[email protected]> >> wrote: >> >> >>>>> > -1 >> >> >>>>> > >> >> >>>>> > On Thu, Aug 18, 2011 at 2:43 PM, Patrick Earl < >> [email protected]> >> >> >> wrote: >> >> >>>>> > >> >> >>>>> >> So we need to ensure there has been a clear decision on the >> >> >>>>> >> source >> >> >>>>> >> control matter. Committers should indicate one of the >> following >> >> >>>>> >> options. >> >> >>>>> >> >> >> >>>>> >> +1 = Use the github repository. >> >> >>>>> >> -1 = Do not use the github repository, find another >> alternative. >> >> >>>>> >> >> >> >>>>> >> Please respond on this thread with your vote. >> >> >>>>> >> >> >> >>>>> >> Patrick Earl >> >> >>>>> >> >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > -- >> >> >>>>> > Fabio Maulo >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> Fabio Maulo >> >> >> >> >> > >> > >> > >> > >
