On Thu, Dec 3, 2009 at 3:36 PM, Aidan Skinner <[email protected]> wrote: > On Wed, Dec 2, 2009 at 12:13 AM, Carl Trieloff <[email protected]> wrote: > >> If there are a lot of devs/ users that want it that and put the effort in >> to build such a thing and maintain it, for >> example create a c++ shim for JMS for RDMA/IB. And a strong community forms >> then why not? >> >> I.e. Those that do have more say in the definition of the model, and the >> debate conclusion should come >> from those investigating into the module being invested in. I.e. if a set >> of people show up and make IKVM >> work and support it, why not? >> >> Does this invalidate another client that is also being actively maintained, >> that is clearly no. > > I think the crux of this part of the issue is that we don't really > have any policy/practicies for bringing in new code bases. In the past > new clients have just been added by existing commiters with out much > in the way of notice, debate or discussion. > > It's not really worked out well. > > Other Apache projects take these through the incubator, but that's > mostly dealing with IP clearance. It doesn't really help prevent large > code drops which are then basically abandoned. > > If we're going to avoid turning into the sourceforge of AMQP projects > (something which I sometimes worry we're in danger of) we might want > to think about this. :) > > It's particularly important where we're importing something which > duplicates (fully or partially) existing functionality, if only so > that the situation is sufficiently clear to people trying to make an > informed decision about what best suits their needs. > > - Aidan > -- > Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org > "A witty saying proves nothing" - Voltaire > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
I agree that we didn't have a consistent policy about accepting large contributions. We often welcomed these contributions without much scrutiny and relied heavily on trust as for certain areas the project lacked the necessary skill set to make an informed decision. Another reason for our laxed approach was due to us being in a rapid growth stage as a project and diversity and community building was important. To be fair I think this is probably a common issue for most projects in their initial stages. But as a project matures things usually change for the better. A reasonable analogy would be a startup vs an established company. Also at Apache community comes first and code second, in that active participation is encouraged. All though they are not necessarily conflicting goals, however they sometimes do. Striking a proper balance is crucial for the success of the project. While a very liberal policy for accepting code contributions could lead to bit rot, a more constricting policy may hinder growth and innovation and stifle the community. So I think we need to consider all aspects carefully when grafting a policy. We need to ensure the quality of our code and end user experience while still maintaining a healthy policy towards accepting contributions. I think several folks have expressed a desire to follow a similar approach as Apache does when accepting code contributions. A sandbox/experimental area would be a great fit for new contributions. The release process will ensure that such contributions are explicitly marked experimental. Once proven in terms of maintainability and demand, we could then graduate them into the main area. The main area should also be organized into a core set of components and an optional set of tools etc. For example I consider brokers and clients as core components, while QMF + the various management tools as value additions on top of the core components. It's also possible that we could partition svn privileges accordingly. While the bar for granting write access to experimental/sandbox may be less stringent, access to the main area could be higher. This will ensure that we are still maintaining a liberal policy towards code contributions while still controlling the quality of the main code base. Anything that rots in the experimental area could be thrown into an attic and then eventually discarded. Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
