[NHibernate-development] NHibernate.Facilities

[Fabio Maulo]

Ok friends.
Now we have the Contrib infrastructure.
Kailuo Wang, the MindLib PL, accept the proposal to port some part of the MindLib directly in our NH contrib below the name of: NHibernate.Facilities

For who want to know what MindLib do the link is:
http://mindlib.wiki.sourceforge.net/

In this case the target of NHibernate.Facilities is to have "cooked code" to manage NH.Session and probably some other facilities.
The "integration" mean that not all MindLib code become part of NH contrib, but only the part that is strictly related with NH.
If there is no opposition the work can be done step-by-step (not all in one shot), with some refactoring, directly by Kailuo Wang and we can propose him some change if needed.
MindLib have a part to work with multi-db and Kailuo studying some improvement... probably the work can be integrated with NHibernate.Shards

Thoughts?

Fabio Maulo

[Ayende Rahien]

There are a lot of those out there.
Rhino Commons,
Spring .NET extensions
Castle NHibernate Facility
Etc

I am not sure that this is a good idea to pick one approach.
Then again, we can spin it off as a way to use it in a standalone fashion...
Not sure about it

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nhibernate-development mailing list
Nhibernate-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nhibernate-development

[Fabio Maulo]

I would like to have one approach full integrated and maintained with NH.
It is a contrib so user can chose NHibernate.Facilities or whatever else.

Rhino.Commons have many things that can be integrated in something like NHibernate.Facilities too.
If you agree we can talk about what is useful to integrate in NH contrib.

In the previous thread about NH.Contrib we talk about contrib target....
I think that our project is the right place where people can find something useful to work with NHibernate.

Fabio Maulo

[Dario Quintana]

Hi,

In the same way that MVC.Net Contrib has differents implementations or bridges for connect/integrate MVC.Net with differents frameworks of IoC (for say something), we could define some interfaces for example for Repositories, Session Managment and later every framework could implement this interfaces to full they implementation.

Another example that come to my mind is Common.Logging. It have implementations for use with Log4net, NLog and who knows. If I write some logging brandnew framework, I implement the common.logging interfaces and it's all right.

What I mean with this, we can manage we own implementation and maintain it, but provide the interfaces and the bridges classes for the other friends frameworks like: Rhino.Commons, Spring.Net, Castle.

Looks like with too much abstractions but, if we opt by a own implementation I think that is the way of do it.

By the way, there is many of another things to fill the NHibernate.Facilities package, like a Pagination Support (present in uNHAddIns), Custom User Types, and so on.

Thoughts?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nhibernate-development mailing list
Nhibernate-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nhibernate-development

--
Dario Quintana
http://darioquintana.com.ar

[Ayende Rahien]

I think we need to define what the facilities is all about.
Because to me, facilities is part of the project, contrib is an external contribution. We make guarantees about quality / copmatability of the project, not for the contrib.

[Fabio Maulo]

2008/1/28, Ayende Rahien <aye...@ayende.com>:

I think we need to define what the facilities is all about.
Because to me, facilities is part of the project, contrib is an external contribution. We make guarantees about quality / copmatability of the project, not for the contrib.

Sometime the name "Facilities" is too generics...
If somebody have a better name for something that help people to manage NH session with different patterns, I open to hear....

For the others things, UserTypes and so on, I think that the previous thread of NH Contrib proposal have the answer.

---
Fabio Maulo

[Karl Chu]

We probably need some guidelines to help us decide what gets added to, and what gets left out of the NHibernate code base.  So let me express my thoughts and I invite you to comment.

Given a piece of code, I would classify it as one of the following:

1. A core piece of functionality of NHibernate (e.g. support for <union-subclass>)
2. A pluggable component for NHibernate (e.g. the JetDriver)
3. Something that extends and builds on top of the functionalities of NHibernate.  It interacts with NHibernate at a deeper level than a client app (e.g. NHibernate.Search)
4. Something that "wraps" NHibernate; and from NHibernate's perspective, it behaves very much like a client app (e.g. Spring.NET integration with NHibernate).
   

For ease of discussion, let me give these things names and call them "Level-1/2/3/4 components".

In my mind, level-1 components should be maintained by the NHibernate core team.  Level-2 components goes into NHibernate.Contrib; the exception to this is a default implementations for each pluggable components that is required for NHibernate to function (e.g. a Proxy factory).

For obvious reason, Level-4 components shall be left out of the NHibernate code base.  If I have my way, I would default level-3 components to "out"; and we would consider each component on a case-by-case basis.

If we can decide on some guidelines with which we use to measure the "core-ness" of something, we can use that to measure MindLib and see where it fits.

Make sense?  Thoughts?

Karl

[Kailuo Wang]

Hi guys, I am new here but please allow me to express some of my thoughts.
Personally I think MindLib is a level-4 components. And I agree that such components should be left out of the NH code base - just like Seam is a separate project from Hibernate. But I also understand Fabio's concerns: first, there is a great need of such level-4 components - such middle ware between NH and client application; second, there are too many such 3rd party such solutions out there and could be causing some confusion to people who are new to NH. I believe that's the reason Gavin developed Seam. As a project developed and maintained by the same organization and even same founder, Seam automatically became the "official" mid-ware solution and thus also addressed the confusion problem.
I think it might be helpful for NHibernate users - especially new ones, that the NHibernate world also has such a separate but also connected, in some way, mid-ware solution project that has some "official" support. Clearly, I am not saying that MindLib should be the official solution. I just want to let you know how MindLib, in my point of view, can contribute to such solution.
If you learn more about MindLib, you should know it's really not just a session management solution, it is developed to simplify NH based projects as much as Seam does for Hibernate based JSF applications, to consolidate the conflict between the stateless web framework and stateful NH based domain layer. Like in Seam, in MindLib, developers can even avoid interacting with the any Session state management related interfaces, including the ISession itself, 99% of the time (100% in our more than 20 internal projects - some of them based on multiple databases). The key here is the stateful component and the conversation support. Seam achieved that using a stateful component framework that integrates with JSF framework in a MVC architecture application. Asp.net is not a quite a MVC style framework and most .net web application developers are only familiar with it. So MindLib did that by making the Asp.net framework appear stateful with field attributes and an even simpler to use conversation support.
The bottom line is that, I think, NHibernate world needs it's own Seam (it can't be a port though as the Asp.net is a totally different environment) , and I would love to contribute to it.
Looking forward to hear what you guys think.
 
Kailuo Wang

[Ayende Rahien]

Yes, it does.
I like this approach

[Ayende Rahien]

Kailuo,
I haven't looked at the code, and I haven't tried it, but I have a great aversion of things that pretend to be something else.
The abstraction is leaky, and you tend to end up fighting the platform in many advance scenarios.
I think that going the other way, statelessness in the web app with http module for session management + Session.Current, would be a much better low end solution.
We can leave the high end solution to other projects.

[Karl Chu]

Hi Kailuo,

First of all, thank you for your interest in getting involved with NHibernate.

With the handful of NH helpers, extensions, and whatnot out there, I think we can agree that there is a confusion issue.  Before we discuss *how* to address this issue, we first need to decide *whether* we address it.

Hibernate and NHibernate are different from a business point of view.  Hibernate is sponsored by JBoss and it has full time employees working to develop, maintain, and support the products.  JBoss also sells support services for Hibernate.  There is motivation for JBoss to have as much control over the "stack" as possible.  Imagine this scenario: I call up the JBoss support line and ask them a question about my Hibernate/Thingamajig application -- where "Thingamajig" is some obscure open-source web integration library.  After spending hours helping me diagnose the issue, the problem was in Thingamajig.  If I were JBoss, I would say this to myself, "SELF!  What I need is an 'official' equivalent of Thingamajig -- let's call it Seam, then my customers will be more inclined to use it because it is 'official'.  I will be able to better support Hibernate.  On top of that, they will likely pay for support for Seam as well".

The case with NHibernate is different.  Support is provided by the community and no one is compensated for that.  Naming something as "official" means there will unspoken obligation and expectation on the team.  In other words, the motivation for NHibernate is the exact opposite -- to be lean, and leave things out when they can be left out.  We don't want to put more on our plates than we need to.

So back to the first question: Do we address the issue of NH Helpers confusion?  It would be nice, but given the limited resources that we have, I think it would be wise for us to focus on the core at this moment.

Hope it make sense.  Thoughts?

Karl

[Fabio Maulo]

2008/1/30, Karl Chu <kc...@koah.net>:

So back to the first question: Do we address the issue of NH Helpers confusion?  It would be nice, but given the limited resources that we have, I think it would be wise for us to focus on the core at this moment.

Hope it make sense.  Thoughts?

I hope that we can address the NH Helpers confusion.
Looking in our's forums many new NH users and many existing prj still have problems with session management in web/win forms.
In theory all of us (19 commiters) can focus on the core but practically each one do what he can (in term of time to spend on it).

Many time is more easy/interesting to add new feature in NH not present in Hibernate, and many time is more interesting to port new packages from Hibernate world instead a ""boring"" port of Hibernate-JAVA code.
I prefer the old Sergey's approach: Any thing you can do in, or about, NH is good if you have time to spend on it.

I think that we can give an official solution, about session management, downloadable with NH....
Something to say : "Do you want start a new prj using NH ?  well... use This solution and than, if you don't like it for some reason, take a look to the others".

Spring and Castle solution mean that the user mu know IoC. The Castle facility don't need Windsor if you don't need the transaction facility... so, at the end, the user must know IoC and need to study Windsor to work with NH.

I really hope that we can give a solution for session management and I hope Kailuo can help us in NH.

Fabio Maulo

[Sergey Koshcheyev]

On Jan 30, 2008 3:13 PM, Fabio Maulo <fabio...@gmail.com> wrote:
> 2008/1/30, Karl Chu <kc...@koah.net>:
>
> > So back to the first question: Do we address the issue of NH Helpers
> confusion? It would be nice, but given the limited resources that we have,
> I think it would be wise for us to focus on the core at this moment.
>

> I prefer the old Sergey's approach: Any thing you can do in, or about, NH
> is good if you have time to spend on it.

Yes, of course, because we can't really keep you from spending your
free time on whatever you want. Or force you to spend your time on
something boring. But I never said that "anything you do in/for NH
will definitely get into the official distribution". The problem is
that once something gets into NHibernate, it's hard to take out and it
requires some constant amount of effort just to keep the thing in a
compilable state.

If you really like what Kailuo did (I must admit I haven't looked)
then document it, write a few articles about it, show how it solves
users' problems, and if it's really good, it will get used and will
become a de-facto standard no matter if it's included into NH or not.

Sergey

[Fabio Maulo]

2008/1/30, Sergey Koshcheyev <serge...@gmail.com>:

If you really like what Kailuo did (I must admit I haven't looked)
then document it, write a few articles about it, show how it solves
users' problems, and if it's really good, it will get used and will
become a de-facto standard no matter if it's included into NH or not.

MindLib have enough documentation and Kailuo write enough articles in code-project too.
I'm going to talk about the part of MindLib help NH users to manage sessions and transactions in some forum...

By the way I still think that 4 types of 2L-cache, Oracle userTypes, MSSql userTypes and JetDrive have, minimal, the same sense to give, to NH user, an official way to solve session and transaction management.

Fabio Maulo

[Sergey Koshcheyev]

> By the way I still think that 4 types of 2L-cache, Oracle userTypes, MSSql
> userTypes and JetDrive have, minimal, the same sense to give, to NH user, an
> official way to solve session and transaction management.

I personally think putting all those into NHibernate was a mistake. We
should have been much more selective.

[Fabio Maulo]

2008/1/30, Sergey Koshcheyev <serge...@gmail.com>:

> By the way I still think that 4 types of 2L-cache, Oracle userTypes, MSSql
> userTypes and JetDrive have, minimal, the same sense to give, to NH user, an
> official way to solve session and transaction management.

I personally think putting all those into NHibernate was a mistake. We
should have been much more selective.

Which will be the target of our Contrib area ?

--
Fabio Maulo

[Karl Chu]

> I think that we can give an official solution, about session management,
> downloadable with NH....

I prefer that we endorse a third-party solution (be it Spring, Castle, or MindLib) without absorbing it into the NH code.  It still gives user some level of confidence that it is "the right way" of doing something.

> I personally think putting all those [2L-cache, user types] into NHibernate was a mistake. We

> should have been much more selective.

I agree.  The main reason for NH.Contrib is to slowly sever them off the NH code base, and let those who have an interest and a stake to maintain them do so.

Karl

[Sergey Koshcheyev]

On Jan 30, 2008 4:14 PM, Fabio Maulo <fabio...@gmail.com> wrote:
> 2008/1/30, Sergey Koshcheyev <serge...@gmail.com>:

>
> Which will be the target of our Contrib area ?

I personally would eliminate the contrib area completely. If somebody
else finds that stuff important to maintain, I've heard Sourceforge is
hosting open-source projects for free ;-)

[Karl Chu]

> I've heard Sourceforge is hosting open-source projects for free ;-)

LOL!

Anyway, I wonder if NH.Search, Validator, and Shards should be separate SF projects as well (I am asking sincerely).

Karl

[Ayende Rahien]

I liked your previous structure. I think they should be part of the package

[Kailuo Wang]

Karl,

Thanks for your detailed explanation.
I understand that NH team don't have enough source to address this confusion and you want to focus on core at this moment. My guess, maybe I am too naive, is that as long as MindLib is in a separate distribution package, it can has its own sub-community and development team, it won't add much responsibilities to the core team. ( Isn't that what NHibernate.Contrib for?)
I think the idea here is to expand the community (not the NHibernate distribution) so that new user can easily find the whole solution of developing apps on NH. My personal belief is that from an end user's point of view, one big and integrated community is better than many small and loose communities. By "integrated"  here I mean same issue tracking site, same forum site and same wiki site. The core team is always the core team and should focus on the core, but why not try make the community more and more strong?

Kailuo Wang

[Sergey Koshcheyev]

On Jan 30, 2008 4:26 PM, Karl Chu <kc...@koah.net> wrote:
> > I've heard Sourceforge is hosting open-source projects for free ;-)
>
> LOL!
>
> Anyway, I wonder if NH.Search, Validator, and Shards should be separate SF
> projects as well (I am asking sincerely).

I'm inclined to answer yes to this as well. What will happen to
Search, Validator and Shards once their current developers lose
interest or decide there's nothing left to do and move on? Should it
be the responsibility of the NH team to maintain the projects
afterwards? I don't think so. It should be up to the original author
to either ensure the project lives on or accept the responsibility for
letting it die.

But really, any decision made on this matter can eventually be
reversed with more or less effort, so you could try either way and see
what works better. I'm not the project lead and I don't want my
opinion to stop you from doing something you think is right.

[Fabio Maulo]

2008/1/30, Karl Chu <kc...@koah.net>:

Anyway, I wonder if NH.Search, Validator, and Shards should be separate SF projects as well (I am asking sincerely).

:(

Fabio Maulo

[Fabio Maulo]

I hope to have many other prj, strictly related with NH, integrated in it.
Is more easy for the user to find what he need to work with NH and give us the opportunity to still really integrated.
A little example...
Castle.Facility and MindLib have something like an unneeded override of NH configuration. What they need is where is the NH session-factory-configuration xml file for each RDBMS, all others informations are included in session-factory section.
If we have a integrated solution will be more easy talk between teams.

By the way I respect the PL decision.

Fabio Maulo

P.S. work porting Hibernate-JAVA code is not boring for me... I LOVE it, and I hope to have time to port 90% of H3.2.5 features for NH2.0 release.
P.P.S. we are working for a new AST query parser too.... but is not official, is unofficial ;)

[Dario Quintana]

I disagree.

Imagine if I need to do a little modification to NHibernate Core because Search,Validator,Shards demands....

- I need to write a Jira ticket,
- Wait to somebody apply the patch, or my self...don't know.
- Later make an update of the NHibernate code on my separated nhibernate-copy-code in another SF project.
- Build the new NHibernate.
- Use the code on my Search/Validator/Shards.

I know, this doesn't happen every day, but, I disagree with leave a different SF for each of this projects.
Hibernate doesn't, why us?

And now imagine if a change on NHibernate break the tests on Search,Validator or Shards... ugly.

On Jan 30, 2008 1:26 PM, Karl Chu <kc...@koah.net> wrote:

> I've heard Sourceforge is hosting open-source projects for free ;-)

LOL!

Anyway, I wonder if NH.Search, Validator, and Shards should be separate SF projects as well (I am asking sincerely).

Karl

[Ayende Rahien]

Well, my usual stack is NHibernate -> Castle -> Rhino
Recently I did a big project with that, lot of advance stuff. You wouldn't believe the number of changes that I had to do all across the stack to get it working properly.
It is a PITA, yes. But a manageable one.
In this case, we are talking not about separate projects, but about parts that integrate into the core of NHibernate. Yes, they do so with the publicly provided extension points, but I view them as part of the project.

[Sergey Koshcheyev]

First, please understand that alive subprojects are not the problem!
It's the dying/dead/stagnated/abandoned subprojects that are the
problem. Currently Search, Validator, Shards are all reasonably alive
and well. But what do you propose we do to these projects when their
maintainers leave and they begin to slowly die off? I'd like to hear ideas.

Further replies inline.

Dario Quintana wrote:
> I disagree.
>
> Imagine if I need to do a little modification to NHibernate Core
> because Search,Validator,Shards demands....
>
> - I need to write a Jira ticket,
> - Wait to somebody apply the patch, or my self...don't know.
> - Later make an update of the NHibernate code on my separated
> nhibernate-copy-code in another SF project.
> - Build the new NHibernate.
> - Use the code on my Search/Validator/Shards.
>
> I know, this doesn't happen every day, but, I disagree with leave a
> different SF for each of this projects.

You have commit access so the process is simplified to "commit changes
to NHibernate, use the code". In general, I'd expect subproject leads to
have commit access to NHibernate for this exact reason.

You can check out both projects into two sibling directories and adapt
your build system to handle this.
Another possibility is to have the projects in the same SVN tree but
totally separated. This is almost the same as the first option except
that the NHibernate team will have to decide whether to grant access to
somebody who wants to work on NHibernate Subproject, instead of leaving
this decision to the NHibernate Subproject lead.

> Hibernate doesn't, why us?

Because all Hibernate subprojects are managed by JBoss/Red Hat, people
working on Hibernate subprojects are employed by JBoss/Red Hat, and so
it can be expected that they will live together and die together (let's
hope not). Our situation is different.

> And now imagine if a change on NHibernate break the tests on
> Search,Validator or Shards... ugly.

If the change introduces a bug, the NHibernate team will fix it easier
if they can focus on just NHibernate instead of having to care about 50
other subprojects. If the change doesn't introduce a bug then it's up to
the subproject maintainers to upgrade their tests.

Also note that I'm speaking about the team in general. Of course some
members of the team (you, Ayende, Fabio, others) will work on several
projects and as I said above, I expect that subproject leads will have
commit access to NHibernate. But for somebody who wants to join the team
and focus on the Core, we shouldn't make it a requirement to have
knowledge of the internals of Search, Validator, Shards, or whatever else.

[Ayende Rahien]

Fabio recently did a lot of breaking changes to Search, which I later fixed. That worked fairly well.

In general, I don't think it is a problem.

I propose the following structure:
- Core is core :-)
- Subprojects are part of NH
- If a change in NH breaks a subproject, the committer can either fix it or ask the subproject lead to do it.
- If a significant amount of time passes without a fix, the project is removed from the build script
- Sometimes later, it is moved to the Attic

In other words, LRU

[Dario Quintana]

Ok, I understand you, that are not a problem.

I just reply the question (with my personal criteria) of Karl about differents SF projects for the sub-projects (Searh, Validators, Shards).

Thanks to you and Ayende for reply.

Best regards.

On Jan 30, 2008 3:33 PM, Sergey Koshcheyev <serge...@gmail.com> wrote:

First, please understand that alive subprojects are not the problem!
It's the dying/dead/stagnated/abandoned subprojects that are the
problem. Currently Search, Validator, Shards are all reasonably alive
and well. But what do you propose we do to these projects when their
maintainers leave and they begin to slowly die off? I'd like to hear ideas.

...

[Fabio Maulo]

2008/1/30, Sergey Koshcheyev <serge...@gmail.com>:

First, please understand that alive subprojects are not the problem!
It's the dying/dead/stagnated/abandoned subprojects that are the
problem. Currently Search, Validator, Shards are all reasonably alive
and well. But what do you propose we do to these projects when their
maintainers leave and they begin to slowly die off? I'd like to hear ideas.

That is my original idea when I propose NH.Contrib and the new project distribution structure taking example from Firebird project structure.
NH have many injectable "things" and I think that the best place to find something useful to work with NH is the NH project.
Each sub-prj can have an "independent" structure but who work in each sub-prj have the full support of NH core team... basically we have an team that work not only in NH core (who can work on it) but in something else that help NH users too.
Like you know, there are committers that start to work in NH for a "no core" reason but later they contributed to the development of core so, sometimes, we can improve the probability that NH not die.

Suppose that Shards not exists in Hibernate, how we can interpret this phrase:
"... talking to multiple relational databases inevitably complicates the development of your application.Hibernate Shards is a framework that is designed to encapsulate and minimize this complexity by adding support for horizontal partitioning to Hibernate Core."
In which Karl's level we put it ? level-3 or level-4 ?

Suppose that a guy think to port or write something like EntityManager:
"Hibernate EntityManager wraps the powerful and mature Hibernate Core. You can fall back to Hibernate native APIs, native SQL, and native JDBC whenever necessary."
In which Karl's level we put it ? level-3 or level-4 ?

The fact that anybody can start a work out-side NH is extremely clear.
What I don't have clear is why we can't provide some other useful integrated project to help people working with NH.

Bye.
Fabio Maulo

[Kailuo Wang]

Karl,


So, what do you think is the chance of letting MindLib (actually Fabio and I decided to rename it to NHibernate.Burrow) join the NHibernate.Contrib project?
I hope that NHibernate.Burrow can join the NHibernate community but I will understand the decision you make.
Thanks,


Kailuo Wang

[Karl Chu]

Hi Kailuo,

I still have mix feelings about adding NH.Burrow to NH.Contrib; and more generally, about the future of NHibernate.Contrib.  I am at work now and cannot take too much time out to write a full response.  I will response more fully later today (in about 8 to 10 hours).

Thanks,
Karl

[Karl Chu]

Hi Kailuo and others,

This has been occupying my mind for the last couple of days.  Without boring you with my thought processes and everything that went through my mind, here is my proposal; which I think is a happy medium.  Its structure and organization is inspired by that of Castle Contrib

1. NHibernate.Contrib becomes a separate SF project to which everything non-core goes
   
2. Every owner of a subproject will be made an admin of NH.Contrib
3. Each subproject gets its own root-level sub-folder.  Owners of subprojects are free to do whatever he/she wishes in its own folder
   
4. Nothing in NHibernate.Contrib is supported by the core team (technically, there is not even promises of support for the core)
5. Each subproject minds its own releases, documentation, and other administrative tasks
   
6. NH.Burrow can go into NHibernate.Contrib

How does that sound?

Karl

[Fabio Maulo]

2008/1/31, Karl Chu <kc...@koah.net>:

1. NHibernate.Contrib becomes a separate SF project to which everything non-core goes
   
2. Every owner of a subproject will be made an admin of NH.Contrib
3. Each subproject gets its own root-level sub-folder.  Owners of subprojects are free to do whatever he/she wishes in its own folder
   
4. Nothing in NHibernate.Contrib is supported by the core team (technically, there is not even promises of support for the core)
5. Each subproject minds its own releases, documentation, and other administrative tasks
   
6. NH.Burrow can go into NHibernate.Contrib

How does that sound?

Search, Validator, Shards and so on become part of Contrib ?

Fabio Maulo

[Fabio Maulo]

2008/1/31, Fabio Maulo <fabio...@gmail.com>:

2008/1/31, Karl Chu <kc...@koah.net>:

How does that sound?

Search, Validator, Shards and so on become part of Contrib ?

For me sound OK (even if I'm prefer other thing).

Please, do you can define which prj is "In" and which is "Out"?
Sometimes the v10brach can help us to take a decision.....

Later somebody can create the NHContrib prj in some place (SF, GoogleCode, CodePlex, what ever) and he can move the "out-prjs" there, while we delete the "out-prjs" from our NH.
Than NHContrib future is out of our decision.
Do I well understand ?

Fabio Maulo

[Kailuo Wang]

Karl,

Thanks for your deliberate consideration.
I agree with your decision.

Kailuo Wang

[Karl Chu]

Yes, I am intending on putting Search, Validator, and Shards into Contrib.  I submitted NH.Contrib to SourceForge for approval.  Once it is approved, I will set up some basic structure and move some current subprojects there.

Once NH.Contrib is up and running, maintenance of it will then be up to each owner of the subprojects.

Karl

[Karl Chu]

Thanks to everyone who gave input on this.

Karl

[Pelton, Brian]

I am a non-commiter, but I have a question to help me (and others) understand this….

 

I understand that NH.Contrib is a separate project and owned by several project leads.

 

How does a project become part of NH.Contrib?  Is there an approval process or criteria? Can any project join NH.Contrib?  Could it get cluttered with half-baked attempts?

 

I ask because NH.Contrib seems to become an official collection of NH extensions.  If it is merely a collection of projects of no certain state, then why group them together?

 

It seems to me that you still have to have someone or a group of someones who own the NH.Contrib project itself and can admit projects into it and potentially / possibly kick stale projects out of it.

 

Or, I am over thinking this…

 

--Brian

[Karl Chu]

There will be some guidelines for adding and removing projects, as well as some "rules and regulations" for subprojects.

Karl