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.
On Wednesday, 14 March 2012 20:39:24 UTC+1, Dario Quintana wrote: > 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 > On Wednesday, 14 March 2012 20:39:24 UTC+1, Dario Quintana wrote: > > 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 >
