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
> >> >>
> >> >
> >
> >
>
