Move nhcontrib to github?

[Oskar Berggren]

A problem with the contrib-projects are that they seem to not be as
maintained as one would like. Especially when new versions of
NHibernate are released, there are incompatibilities. At least
sometimes this may be only a matter of a rebuild, to get the assemble
version dependency right.

Some of the contrib projects have started to show up in multiple
unrelated incarnations on github, causing duplication of work and
fragmentation.

Some of the projects have automatic builds on teamcity.codebetter.com,
based on the SVN repo, but there are unresolved compilation and test
failures dating months or years back.

And yet people seem to be using at least some of these projects.

What is the promise we as "NHibernate core" want to make concerning
these contrib projects? The name and their inclusion on nhforge seems
to indicate some level of "officialness", in which case problems
reflect badly on NHibernate as a whole.

I think we should move these projects to Github in the nhibernate
organizations as the official master repo. This should make it easier
for others to contribute and actually send changes back to the
upstream project.

Following that I think it would be great (and easier than now) if we
could try to at least maintain build compatibility and automatic
builds in relation to new versions of NHibernate.

Perhaps some of the people who have made their own move to github
could be interested in maintaining the upstream version.

/Oskar

[Stephen Bohlen]

All of this seems like a reasonable proposition to me -- I agree with your evaluation of some of the challenges/deficiencies in the present nhcontrib setup and I'm (generally) in favor of doing things to address some of these very same shortcomings.

This suggestion (move to github) has been made several times in the past and the stumbling block has usually been that at least some of the present 'leads' for the nhcontrib projects didn't all want to move their efforts to github, preferring to remain elsewhere for their choice of VCS.  There is merit in centralizing these projects for all the reasons you point out, but not at the expense of losing any of the presently-active nhcontrib maintainers (e.g., if moving to github is a win all-around, then I'm for it, but if it results in any existing nhcontrib maintainers deciding its not worth their effort, then I'm probably against it).

I'd be entirely supportive of (re)asking the existing nhcontrib project leads whether their willingness to move to github has changed since the question was last asked (probably > 1 year ago by now).

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Gerke Geurts]

In the process it probably would make sense to break the contrib project up into smaller subprojects. Forking the whole project brings in a lot of stuff that often is not of use when wanting to patch or extend one of the subprojects.

 

Regards,

Gerke.

[Oskar Berggren]

I also thought about splitting them into separate repositories which
in a way feels natural. One drawback though: If we want to try and be
better at promptly providing builds for new NHibernate releases,
perhaps it's more efficient to keep them together (or in a few groups)
to be able to update/release them as a group. Perhaps they are
different enough that this goal will be difficult to achieve anyway?

/Oskar

2012/3/13 Gerke Geurts <gge...@gmail.com>:

[David Schmitt]

My experience with setting up jenkins at my company suggests that it's
better to have small independent projects, so that broken builds or
broken projects do not interfere with healthy projects.

Regards, David

[Diego Mijelshon]

I have to agree here. Half the projects in nhcontrib haven't seen a new code line in 2 years (see  http://nhcontrib.svn.sourceforge.net/viewvc/nhcontrib/trunk/src/?sortby=date#dirlist)

It would be nice to have "near-core" libs released* within a week of the core GA release.

By "near-core" I mean Caches, Attributes and probably Spatial.
 
    Diego

*: and by "released" I mean available on NuGet.

On Mon, Mar 12, 2012 at 9:06 AM, Oskar Berggren<oskar.berggren@gmail.com>

[Thomas G Mayfield]

I'd be happy to take over maintenance of NHibernate.JetDriver since it's seen so little change over the last few years.  I've a repo out on github with bugfixes and improvements ( https://github.com/tgmayfield/nhibernate.jetdriver ), and I use the library on a fairly frequent basis for work for integrating with older tools.  It'd be easy enough to move that repo elsewhere, or start fresh and do a code review with someone on the changes.

[Rory Plaire]

+1 on splitting; I never needed most of the projects and navigating the big bundle has always been troublesome.

 

I could provisionally take on NHibernate Search since we're keeping it up to date internally anyway.

 

Would there be sub-repositories under the NHibernate "area" on github? Keeping all the projects together in some way, even if they are independent, would be a big help for findability.

 

-r

[Dario Quintana]

When we started with with nhcontrib the main idea was to maintain all contrib projects together, in one place. Indeed, as you may see the folder structure you'll find a trunk/lib folder, the idea was to maintain there the last NHibernate release, then every contrib-project should reference those libs. Was a naive idea, every project has it's own release-cycle, and some are a little abandoned (to say the truth), and even some projects needed the current-trunk NHibernate version.

Ok, that was little of History Channel, now ... I can move to NHibernate Validator and Shards to GitHub, if you wish. I can talk for this project (NHV) and a half (NH.Shards).

In the future, we can move contact every project admin, to do the same.

Like Stephen said, maybe others developers don't want to move to Github (particulary, I'm too married with Hg, but I can live), and we can't do that much about that. 

--
@darioquintana

[Gerke Geurts]

I'd be happy to contribute to NHibernate.Shards, as we run an up-to-date version internally (a clone of which currently resides at http://code.google.com/p/nhshards/).

 

Regards,

Gerke.

[Dario Quintana]

I haven't created the repos as part of an organization, I've imported from the sf svn:

https://github.com/darioquintana/NHibernate-Validator

https://github.com/darioquintana/NHibernate-Shards

--
Dario Quintana