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.
On Monday, 12 March 2012 14:43:27 UTC+1, sbohlen wrote: > 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 > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > On Mon, Mar 12, 2012 at 9: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 >> > >
