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 <[email protected]>: > 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 >> >> >
