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