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 Tue, Mar 13, 2012 at 16:20, David Schmitt <[email protected]> wrote:
> 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
>
>
>
> On 2012-03-13 19:49, Oskar Berggren wrote:
>
>> 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://blog.unhandled-exceptions.com>
>>>> http://twitter.com/sbohlen
>>>>
>>>>
>>>> On Mon, Mar 12, 2012 at 9:06 AM, Oskar Berggren<oskar.berggren@gmail.**
>>>> com <[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
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
