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.



On Mon, Mar 12, 2012 at 10:06 AM, Oskar Berggren
<[email protected]>wrote:

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



-- 
@darioquintana

Reply via email to