Re: Accepting large contributions (was Re: 10000 msgs limit per session)

[Rajith Attapattu <ra...@gmail.com>]

On Thu, Dec 3, 2009 at 3:36 PM, Aidan Skinner <ai...@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 12:13 AM, Carl Trieloff <cc...@redhat.com> 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:dev-subscribe@qpid.apache.org
>
>

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:dev-subscribe@qpid.apache.org

Re: Moving some of the topics on the list forward.

[Jonathan Robie <jo...@redhat.com>]

I really like this idea. It would have been very helpful to me when I 
was new to the project.

Jonathan

On 12/04/2009 11:56 AM, Carl Trieloff wrote:
>
> I think we could brake the issue apart a bit. Looking at some projects 
> they have additional
> concepts - what is maturing  and who is lead on sections of the 
> project. I think this might give
> us some advantages.  (some of this is Rafi idea :-)
>
> If we create a text file that has the different sections of the 
> project in it, for example:
>
> Broker Java
> Broker C++
> Clients Java
> Clients C#
> Clients C++
> Clients Ruby
> Clients Python
> QMF
> QMan
> Eclipse tools
>
> etc.
>
> Then those that are expert on those sections put their names under 
> them, for example
>
> Alan, Andrew, Gordon, Steve under C++ broker and client  (lists not 
> complete)
> Rob, Rafi, Adian,  Rajith .. under Java broker and client
> etc...
>
> This gives us a few things:
>
> a.) First it means that someone new to the project knows who to hit up 
> on a section of code.
> b.) It also then means that if you are not in a section, then before 
> committing to that section
> of the code base you would ask for comment on your patch.
>
> Thus:
> a.) It establishes an way in which we can bring people onto the 
> project without being concerned a
> committer will work outside their domain without review from other 
> when appropriate committers.
> b.) Makes it possible to also mark some sections of the project at 
> different maturity also for our users.
> c.) Then over time as committers work on certain sections they can add 
> their name to another section
> of the project once they have established a deep understanding of that 
> part of the code.
>
> The list could also work the other way round,
>
> Each committer puts his name on the file, and the the sections of code 
> he wants to be FYI'ed on before
> any major changes in that section if we want more granularity...
>
> For example
> Andrew - C++ IO
> Steve Windows IO
> Ted QMF
>
> etc,
>
> I think generally we sort of do this, but it might be worth putting 
> some structure in to help us manage the
> growth of the project.  Personally I don't want to get into the svn 
> access pre part of the project, the above
> approach I think achieves the same and maybe more.
>
> Thoughts.....
> Carl.
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Moving some of the topics on the list forward.

[Carl Trieloff <cc...@redhat.com>]

I think we could brake the issue apart a bit. Looking at some projects 
they have additional
concepts - what is maturing  and who is lead on sections of the project. 
I think this might give
us some advantages.  (some of this is Rafi idea :-)

If we create a text file that has the different sections of the project 
in it, for example:

Broker Java
Broker C++
Clients Java
Clients C#
Clients C++
Clients Ruby
Clients Python
QMF
QMan
Eclipse tools

etc.

Then those that are expert on those sections put their names under them, 
for example

Alan, Andrew, Gordon, Steve under C++ broker and client  (lists not 
complete)
Rob, Rafi, Adian,  Rajith .. under Java broker and client
etc...

This gives us a few things:

a.) First it means that someone new to the project knows who to hit up 
on a section of code.
b.) It also then means that if you are not in a section, then before 
committing to that section
of the code base you would ask for comment on your patch.

Thus:
a.) It establishes an way in which we can bring people onto the project 
without being concerned a
committer will work outside their domain without review from other when 
appropriate committers.
b.) Makes it possible to also mark some sections of the project at 
different maturity also for our users.
c.) Then over time as committers work on certain sections they can add 
their name to another section
of the project once they have established a deep understanding of that 
part of the code.

The list could also work the other way round,

Each committer puts his name on the file, and the the sections of code 
he wants to be FYI'ed on before
any major changes in that section if we want more granularity...

For example
Andrew - C++ IO
Steve Windows IO
Ted QMF

etc,

I think generally we sort of do this, but it might be worth putting some 
structure in to help us manage the
growth of the project.  Personally I don't want to get into the svn 
access pre part of the project, the above
approach I think achieves the same and maybe more.

Thoughts.....
Carl.











---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org