You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Scott Deboy <sd...@comotivsystems.com> on 2008/03/04 22:14:09 UTC
FW: (qpid) Diversity
I'm curious what other incubator folks think about qpid's plan for disclosing the organizational diversity of their committership/PMC (or if this is even a requirement).
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Carl Trieloff [mailto:cctrieloff@redhat.com]
Sent: Tue 3/4/2008 1:08 PM
To: qpid-private@incubator.apache.org
Subject: Re: Diversity
Scott Deboy wrote:
> Since there is a significant amount of corporate support in qpid, I'd
> like to see the breakdown of that support in the committership and
> PMC. If this was discussed previously, can you direct me to the thread?
>
> Thanks
>
> Scott Deboy
Scott,
I know from past discussions that some members of Qpid are not allowed
to disclose who they work for. I am sure they will comment. There is no
secret that I work for Red Hat. As I know this is going to come up, to
get through this we might need to let people say there company name or
"not one of the above..."
does that work. The goal is to show one company does not have all the seats.
There is a thread with the broken out, but it does not include company
names.
regards,
Carl.
RE: FW: (qpid) Diversity
Posted by "Noel J. Bergman" <no...@devtech.com>.
Marnie McCormack wrote:
> Several of our project (Qpid) memebers are legally in a difficult position
> disclosing their employer in Apache world. They have signed a legal
> document, in order to be allowed to contribute to Apache, and thus this is
> not a simple preference issue.
Mind you, they are obligated by their CLA to ensure that if a CCLA is
required for them to be able to act in accordance with the claims made by
them when they submit the CLA, that such CCLA is also filed.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: (qpid) Diversity
Posted by Marnie McCormack <ma...@googlemail.com>.
Dirk,
It is the first case that applies here i.e.
2. Having the employer invisible either implies one of two:
a) The employer totally does not enter into this and
the committer is acting a 100% as a private, free
individual; and his work does not pertain or is
associated in any way with his other endeavors.
Marnie
On 3/6/08, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
>
> On Mar 5, 2008, at 7:27 PM, Marnie McCormack wrote:
>
> > Several of our project (Qpid) memebers are legally in a difficult
> > position
> > disclosing their employer in Apache world. They have signed a legal
> > document, in order to be allowed to contribute to Apache, and thus
> > this is
> > not a simple preference issue.
>
>
> Two thoughts:
>
> 1. As to avoid having trust or distrust affecting the community
> (i.e. some rot setting in at a later stage) I would
> completely ignore these people as adding to the 'diversity' and in
> fact advise to assume the 'worst' - and treat them as one block.
>
> I.e. they are _counter_ to the diversity you want to show.
>
> That is the most robust approach. As information leaks and attitude
> shift the situation only gets better and more trust is build.
>
> 2. Having the employer invisible either implies one of two:
>
> a) The employer totally does not enter into this and
> the committer is acting a 100% as a private, free
> individual; and his work does not pertain or is
> associated in any way with his other endeavors.
>
> b) The employer is in fact part of the 'agreement' - and
> hence known to the foundation.
>
> In the last case we, that is the foundation, would need to figure out if
> we can act as such a 'clearing house' - and would allow such provided
> the
> CCLA's are visible to the members.
>
> I personally would be very wary of this though. As ultimately the CCLA
> and software grants carry a lot of sensitive rights - and part of
> standing within our role in the current open source/standards
> ecosystem has been gained by allowing full downstream visibility.
>
> Dw
>
>
Re: (qpid) Diversity
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mar 5, 2008, at 7:27 PM, Marnie McCormack wrote:
> Several of our project (Qpid) memebers are legally in a difficult
> position
> disclosing their employer in Apache world. They have signed a legal
> document, in order to be allowed to contribute to Apache, and thus
> this is
> not a simple preference issue.
Two thoughts:
1. As to avoid having trust or distrust affecting the community
(i.e. some rot setting in at a later stage) I would
completely ignore these people as adding to the 'diversity' and in
fact advise to assume the 'worst' - and treat them as one block.
I.e. they are _counter_ to the diversity you want to show.
That is the most robust approach. As information leaks and attitude
shift the situation only gets better and more trust is build.
2. Having the employer invisible either implies one of two:
a) The employer totally does not enter into this and
the committer is acting a 100% as a private, free
individual; and his work does not pertain or is
associated in any way with his other endeavors.
b) The employer is in fact part of the 'agreement' - and
hence known to the foundation.
In the last case we, that is the foundation, would need to figure out if
we can act as such a 'clearing house' - and would allow such provided
the
CCLA's are visible to the members.
I personally would be very wary of this though. As ultimately the CCLA
and software grants carry a lot of sensitive rights - and part of
standing within our role in the current open source/standards
ecosystem has been gained by allowing full downstream visibility.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Daniel Kulp <dk...@apache.org>.
Another option would be to not consider the people that cannot disclose
their employers when considering the diversity of the project. If
there are 15 people, and 5 cannot disclose their employer, only consider
the diversity of the remaining people.
Kind of the "err on the side of caution" approach. It may make it
harder for a project to be "diverse enough", but I'm not sure if that's
actually a bad thing.
There is probably still an issue if a very large number of people on the
project fall into the "cannot disclose" list. I would hope that isn't
the case though.
Dan
On Wednesday 05 March 2008, sebb wrote:
> On 05/03/2008, Roland Weber <os...@dubioso.net> wrote:
> > Marnie McCormack wrote:
> > > All,
> > >
> > > Several of our project (Qpid) memebers are legally in a difficult
> > > position disclosing their employer in Apache world.
> >
> > Does that mean they are contributing in their private time rather
> > than as part of their jobs? If so, they should be considered as
> > independents. If contributing to the project is part of their job
> > responsibilities, they should be required to disclose the employer.
>
> If the actual employers cannot be disclosed, perhaps it would be
> possible to list the different companies anonymously?
>
> e.g.
> Company 1 employs Adrian, Barbara, Cedric
> Company 2 employs Peter, Quentin, Rick
>
> This might help with determining diversity.
>
> > > They have signed a legal
> > > document, in order to be allowed to contribute to Apache, and
> > > thus this is not a simple preference issue.
> >
> > My own employer's requirements are something like "must not create
> > the impression to act on behalf of the employer". It doesn't say
> > "is not allowed to disclose the employer". A statement like
> > "independent contributor, working for XXX in the day job"
> > would satisfy that.
> > If it's just one or two of that category, I wouldn't care about
> > the employer at all. But previous postings suggest that a lot of
> > people are working for the same employer, and that's something
> > that should be clarified. Maybe it's a club of spare time
> > developers that met at work and are now jointly working on Qpid?
> >
> > cheers,
> >
> > Roland
> >
> >
> >
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Carl Trieloff <cc...@redhat.com>.
sebb wrote:
> On 05/03/2008, Roland Weber <os...@dubioso.net> wrote:
>
>> Marnie McCormack wrote:
>> > All,
>> >
>> > Several of our project (Qpid) memebers are legally in a difficult position
>> > disclosing their employer in Apache world.
>>
>>
>> Does that mean they are contributing in their private time rather
>> than as part of their jobs? If so, they should be considered as
>> independents. If contributing to the project is part of their job
>> responsibilities, they should be required to disclose the employer.
>>
>>
>
> If the actual employers cannot be disclosed, perhaps it would be
> possible to list the different companies anonymously?
>
> e.g.
> Company 1 employs Adrian, Barbara, Cedric
> Company 2 employs Peter, Quentin, Rick
>
> This might help with determining diversity.
This could work,
Carl.
Re: FW: (qpid) Diversity
Posted by sebb <se...@gmail.com>.
On 05/03/2008, Roland Weber <os...@dubioso.net> wrote:
> Marnie McCormack wrote:
> > All,
> >
> > Several of our project (Qpid) memebers are legally in a difficult position
> > disclosing their employer in Apache world.
>
>
> Does that mean they are contributing in their private time rather
> than as part of their jobs? If so, they should be considered as
> independents. If contributing to the project is part of their job
> responsibilities, they should be required to disclose the employer.
>
If the actual employers cannot be disclosed, perhaps it would be
possible to list the different companies anonymously?
e.g.
Company 1 employs Adrian, Barbara, Cedric
Company 2 employs Peter, Quentin, Rick
This might help with determining diversity.
>
> > They have signed a legal
> > document, in order to be allowed to contribute to Apache, and thus this is
> > not a simple preference issue.
>
>
> My own employer's requirements are something like "must not create
> the impression to act on behalf of the employer". It doesn't say
> "is not allowed to disclose the employer". A statement like
> "independent contributor, working for XXX in the day job"
> would satisfy that.
> If it's just one or two of that category, I wouldn't care about
> the employer at all. But previous postings suggest that a lot of
> people are working for the same employer, and that's something
> that should be clarified. Maybe it's a club of spare time developers
> that met at work and are now jointly working on Qpid?
>
> cheers,
>
> Roland
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: FW: (qpid) Diversity
Posted by "Noel J. Bergman" <no...@devtech.com>.
Roland Weber wrote:
> If contributing to the project is part of their job responsibilities,
> they should be required to disclose the employer.
That has not been made a stringent requirement, but see my response to
Melanie for what *is* a requirement.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Roland Weber <os...@dubioso.net>.
Marnie McCormack wrote:
> All,
>
> Several of our project (Qpid) memebers are legally in a difficult position
> disclosing their employer in Apache world.
Does that mean they are contributing in their private time rather
than as part of their jobs? If so, they should be considered as
independents. If contributing to the project is part of their job
responsibilities, they should be required to disclose the employer.
> They have signed a legal
> document, in order to be allowed to contribute to Apache, and thus this is
> not a simple preference issue.
My own employer's requirements are something like "must not create
the impression to act on behalf of the employer". It doesn't say
"is not allowed to disclose the employer". A statement like
"independent contributor, working for XXX in the day job"
would satisfy that.
If it's just one or two of that category, I wouldn't care about
the employer at all. But previous postings suggest that a lot of
people are working for the same employer, and that's something
that should be clarified. Maybe it's a club of spare time developers
that met at work and are now jointly working on Qpid?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Marnie McCormack <ma...@googlemail.com>.
All,
Several of our project (Qpid) memebers are legally in a difficult position
disclosing their employer in Apache world. They have signed a legal
document, in order to be allowed to contribute to Apache, and thus this is
not a simple preference issue.
Regards,
Marnie
On 3/5/08, Carl Trieloff <cc...@redhat.com> wrote:
>
> Davanum Srinivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Carl,
> >
> > Do they *all* have CCLA's?
>
> absolutely.
>
>
Re: FW: (qpid) Diversity
Posted by Carl Trieloff <cc...@redhat.com>.
Davanum Srinivas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Carl,
>
> Do they *all* have CCLA's?
absolutely.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl,
Do they *all* have CCLA's?
- -- dims
Scott Deboy wrote:
| I'm curious what other incubator folks think about qpid's plan for disclosing the organizational diversity of their
committership/PMC (or if this is even a requirement).
|
| Scott Deboy
| COMOTIV SYSTEMS
| 111 SW Columbia Street Ste. 950
| Portland, OR 97201
|
| Telephone: 503.224.7496
| Cell: 503.997.1367
| Fax: 503.222.0185
|
| sdeboy@comotivsystems.com
|
| www.comotivsystems.com
|
|
|
| -----Original Message-----
| From: Carl Trieloff [mailto:cctrieloff@redhat.com]
| Sent: Tue 3/4/2008 1:08 PM
| To: qpid-private@incubator.apache.org
| Subject: Re: Diversity
|
| Scott Deboy wrote:
|> Since there is a significant amount of corporate support in qpid, I'd
|> like to see the breakdown of that support in the committership and
|> PMC. If this was discussed previously, can you direct me to the thread?
|>
|> Thanks
|>
|> Scott Deboy
|
| Scott,
|
| I know from past discussions that some members of Qpid are not allowed
| to disclose who they work for. I am sure they will comment. There is no
| secret that I work for Red Hat. As I know this is going to come up, to
| get through this we might need to let people say there company name or
| "not one of the above..."
|
| does that work. The goal is to show one company does not have all the seats.
|
| There is a thread with the broken out, but it does not include company
| names.
| regards,
| Carl.
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFHzcJQgNg6eWEDv1kRAvR8AJ9BAsR53+2VP3xGJZZjWYcKH4dY7gCfZp2T
Jwreg49mfXARjaUlClfFF3U=
=5Dp7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Where to next...
Posted by ant elder <an...@gmail.com>.
On Fri, Mar 14, 2008 at 3:44 PM, Rajith Attapattu <ra...@gmail.com>
wrote:
> Hi Rob,
>
> On Fri, Mar 14, 2008 at 11:07 AM, Robert Godfrey <ro...@gmail.com>
> wrote:
>
> > Hi Rajith,
> >
> >
> > > Since this is a major area, could you please share your design ideas
> on
> > > the
> > > list?
> > > Like create a JIRA and post a wiki page.
> > > This can start a disscussion where everybody else can
> comment/contribute
> > > in
> > > terms of ideas or code.
> > > This will ensure that the community feels part of the process and the
> > > community share collective responsibility.
> >
> >
> >
> > Not actually sure this is a *major* area :-) It is simply a new
> > implementation of the matching algorithms.
>
>
> Well code wise this maybe a small area, but performance wise the matching
> algorithm does play a critical role.
>
>
> > Are you familiar with DFAs?
>
>
> Very well.
>
> >
> > There isn't really to much more to it than as I described above: it
> builds
> > a
> > DFA machine as you add bindings.
>
>
> Sorry to have picked on this. But we need to lead by example.
> Even if things are dirt simple, perhaps it is important to explain to the
> community why u think it is a good idea. Whether u have explored other
> ideas
> etc..
> This sort of thing will engage the community and people might have ideas
> on
> how to improve it or perhpas better ideas.
> More than anything it helps keep the transparency and improves community
> participation.
>
>
> > I've not finished it yet, but when I have
> > something ready for people to review I'll post it up.
> >
> > Ok, my goal is to eunsure more transparency of,
> a) what we are planning to do
> b) why we are doing it? ex bug fix, feature, improvement etc.. (JIRA is
> best
> to capture this)
> c) how we are planning to do it
> d) and what sort of time frame (Ex M3...)
>
>
> > >
> > > > I would hold off on the DTX stuff until M4. We need to
> significantly
> > > > refactor the Java Broker (another thing I am doing in the background
> > and
> > > > will look to commit after we have M3 out of the way) and also put in
> > > place
> > > > flow-to-disk.
> > > >
> >
> > Rather than doing this only in the background, I think you should throw
> > the
> > > ideas on the list.
> > > We as a community need to give enough time for people to understand,
> > > review
> > > and comment.
> > > You could continue building your prototype in the background, but the
> > qpid
> > > community should provide more visibility on the design process etc..
> > > Also I would appreciate if everybody get a chance to discuss/review
> the
> > > idea/design and code before you actually make a commit.
> >
> >
> >
> > This is something we discussed at the F2F where you were present. All I
> > am
> > doing is trying to see how easy it is to move the broker to the
> > architecture
> > we described there. I believe Rafi took away the pieces of paper with
> > that
> > written on :-)
> >
>
> Lets put this on the wiki. This will help engaging the comunity.
> We didn't have only a few folks attending the F2F.
> This will also give the community ideas about the direction we are
> talking.
>
>
> > I'm not going to commit on trunk - don't worry... Since we settled on
> the
> > design in our F2F I think the major thing to do is to have a chat about
> it
> > when I have a proposal ready...
>
>
> Rob it is not abouting u commiting on the trunk or not. I wouldn't mind u
> commiting this on the trunk provided we have adequate discussions.
> We need to build a community. And we need to capture these
> discussions/ideas
> in the wiki/JIRA or where ever if we want other folks involved.
> People should get more context as to why we are doing something and where
> we
> are heading.
>
>
> >
> > -- Rob
> >
> >
> > Regards,
> > >
> > >
> > > Rajith
> > >
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
+1 to what Rajith is saying, involving the community early on in design
review and discussion is an important part of the consensus building
process.
...ant
Re: Where to next...
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Rob,
On Fri, Mar 14, 2008 at 11:07 AM, Robert Godfrey <ro...@gmail.com>
wrote:
> Hi Rajith,
>
>
> > Since this is a major area, could you please share your design ideas on
> > the
> > list?
> > Like create a JIRA and post a wiki page.
> > This can start a disscussion where everybody else can comment/contribute
> > in
> > terms of ideas or code.
> > This will ensure that the community feels part of the process and the
> > community share collective responsibility.
>
>
>
> Not actually sure this is a *major* area :-) It is simply a new
> implementation of the matching algorithms.
Well code wise this maybe a small area, but performance wise the matching
algorithm does play a critical role.
> Are you familiar with DFAs?
Very well.
>
> There isn't really to much more to it than as I described above: it builds
> a
> DFA machine as you add bindings.
Sorry to have picked on this. But we need to lead by example.
Even if things are dirt simple, perhaps it is important to explain to the
community why u think it is a good idea. Whether u have explored other ideas
etc..
This sort of thing will engage the community and people might have ideas on
how to improve it or perhpas better ideas.
More than anything it helps keep the transparency and improves community
participation.
> I've not finished it yet, but when I have
> something ready for people to review I'll post it up.
>
> Ok, my goal is to eunsure more transparency of,
a) what we are planning to do
b) why we are doing it? ex bug fix, feature, improvement etc.. (JIRA is best
to capture this)
c) how we are planning to do it
d) and what sort of time frame (Ex M3...)
> >
> > > I would hold off on the DTX stuff until M4. We need to significantly
> > > refactor the Java Broker (another thing I am doing in the background
> and
> > > will look to commit after we have M3 out of the way) and also put in
> > place
> > > flow-to-disk.
> > >
>
> Rather than doing this only in the background, I think you should throw
> the
> > ideas on the list.
> > We as a community need to give enough time for people to understand,
> > review
> > and comment.
> > You could continue building your prototype in the background, but the
> qpid
> > community should provide more visibility on the design process etc..
> > Also I would appreciate if everybody get a chance to discuss/review the
> > idea/design and code before you actually make a commit.
>
>
>
> This is something we discussed at the F2F where you were present. All I
> am
> doing is trying to see how easy it is to move the broker to the
> architecture
> we described there. I believe Rafi took away the pieces of paper with
> that
> written on :-)
>
Lets put this on the wiki. This will help engaging the comunity.
We didn't have only a few folks attending the F2F.
This will also give the community ideas about the direction we are talking.
> I'm not going to commit on trunk - don't worry... Since we settled on the
> design in our F2F I think the major thing to do is to have a chat about it
> when I have a proposal ready...
Rob it is not abouting u commiting on the trunk or not. I wouldn't mind u
commiting this on the trunk provided we have adequate discussions.
We need to build a community. And we need to capture these discussions/ideas
in the wiki/JIRA or where ever if we want other folks involved.
People should get more context as to why we are doing something and where we
are heading.
>
> -- Rob
>
>
> Regards,
> >
> >
> > Rajith
> >
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Where to next...
Posted by Robert Godfrey <ro...@gmail.com>.
Hi Rajith,
> Since this is a major area, could you please share your design ideas on
> the
> list?
> Like create a JIRA and post a wiki page.
> This can start a disscussion where everybody else can comment/contribute
> in
> terms of ideas or code.
> This will ensure that the community feels part of the process and the
> community share collective responsibility.
Not actually sure this is a *major* area :-) It is simply a new
implementation of the matching algorithms. Are you familiar with DFAs?
There isn't really to much more to it than as I described above: it builds a
DFA machine as you add bindings. I've not finished it yet, but when I have
something ready for people to review I'll post it up.
>
> > I would hold off on the DTX stuff until M4. We need to significantly
> > refactor the Java Broker (another thing I am doing in the background and
> > will look to commit after we have M3 out of the way) and also put in
> place
> > flow-to-disk.
> >
Rather than doing this only in the background, I think you should throw the
> ideas on the list.
> We as a community need to give enough time for people to understand,
> review
> and comment.
> You could continue building your prototype in the background, but the qpid
> community should provide more visibility on the design process etc..
> Also I would appreciate if everybody get a chance to discuss/review the
> idea/design and code before you actually make a commit.
This is something we discussed at the F2F where you were present. All I am
doing is trying to see how easy it is to move the broker to the architecture
we described there. I believe Rafi took away the pieces of paper with that
written on :-)
I'm not going to commit on trunk - don't worry... Since we settled on the
design in our F2F I think the major thing to do is to have a chat about it
when I have a proposal ready...
-- Rob
Regards,
>
>
> Rajith
>
Re: Where to next...
Posted by Rajith Attapattu <ra...@gmail.com>.
>
> I have been working on new Finite State Automata versions of the Topic and
> Headers exchanges which I can probably finish off in this time. These
> will
> give matching times proportional to the length of the routing key /
> headers
> arguments; independent of the number of bindings to the exchange.
>
Since this is a major area, could you please share your design ideas on the
list?
Like create a JIRA and post a wiki page.
This can start a disscussion where everybody else can comment/contribute in
terms of ideas or code.
This will ensure that the community feels part of the process and the
community share collective responsibility.
>
> I would hold off on the DTX stuff until M4. We need to significantly
> refactor the Java Broker (another thing I am doing in the background and
> will look to commit after we have M3 out of the way) and also put in place
> flow-to-disk.
>
Rather than doing this only in the background, I think you should throw the
ideas on the list.
We as a community need to give enough time for people to understand, review
and comment.
You could continue building your prototype in the background, but the qpid
community should provide more visibility on the design process etc..
Also I would appreciate if everybody get a chance to discuss/review the
idea/design and code before you actually make a commit.
Regards,
Rajith
Re: Where to next...
Posted by Robert Godfrey <ro...@gmail.com>.
On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> Based on some conversations I want to get a thread going on the
> following....
>
> It looks like M2.1 is landing nicely, so it might be time to start a
> thread on M3 scope. M3 work
> has begun as we all know but I think we need to block up what M3 will
> looks like, JIRA it and do the
> scope closing for it.
>
> This is my view of what M3 looks like -- please add, rant, comment etc...
>
> - Land the 'bigmergebranch' between M2.1 and truck
+1
> - Tests, tests and more tests...
+ [image: \aleph_0]
> - Java client M2.1(0-8/9) interop + AMQP 0-10
> - Java broker merged (still talking 0-8/9?)
+1
> - Java broker (what else here??)
I have been working on new Finite State Automata versions of the Topic and
Headers exchanges which I can probably finish off in this time. These will
give matching times proportional to the length of the routing key / headers
arguments; independent of the number of bindings to the exchange.
> - C++ Broker 0-10 (TCP +IB)
> - C++ Broker clustering module
> - C++ Client 0-10
> - Ruby 0-10
> - .NET 0-10 (see rabbit has done WCF layer, do we want pick anything up
> from that as it is ASL, do we also want to support 0-8/9 from the same
> client, updating our client...)
>
All sounds sensible
> Other items:
> - do we want to try have common events between brokers for mgmt?
> - I expect that we will work to get the Java broker both 0-8/9 and 0-10
> for M4
> - Lot of DTX & JTA work has been done for Java how to review/ merge etc
> this?
>
I would hold off on the DTX stuff until M4. We need to significantly
refactor the Java Broker (another thing I am doing in the background and
will look to commit after we have M3 out of the way) and also put in place
flow-to-disk. This, plus the 0-10 work (and getting the broker to being
able to transparently convert messages between 0-8/0-9/0-10) will probably
affect how the DTX stuff will need to be added.
>
> Let's refine the list on mail and then build a JIRA set for M3.
Yes - we should start a JIRA set for M3 and for M4
> Also, do we expect we will need to do a M2.2 - if so what is it?
>
I am not anticipating an M2.2; or any other releases off the M2 branch other
than bug fixes. Anyone else?
-- Rob
Re: Where to next...
Posted by Carl Trieloff <cc...@redhat.com>.
>
>
>> - .NET 0-10 (see rabbit has done WCP layer, do we want pick anything up
>> from that as it is ASL, do we also want to support 0-8/9 from the same
>> client, updating our client...)
>>
>
> I wonder if we want to continue working on our .NET client? I ask that
> as a genuine question rather than a statement of my opinion. I think
> it would be worthwhile understanding the limitations of a WCF approach
> - people will not be surprised given my support of "extended JMS" in
> Java to hear that a WCF (or extended WCF) implementation would to me
> *seem* the best way of supporting our .NET users.
>
> If the Rabbit client looks good then perhaps it makes sense to
> recommend our users adopt it. I know we have struggled to find the
> bandwidth to maintain our existing .NET client.
>
>
Few problems, the Rabbit one is only 0-9, and don't know when they will
do 0-10. also I
am not sure they have bandwidth either. I would say we should work out
the best way to
get to 0-10 and get a community going around the .NET client. At some
point we had lots
of people wanting to work on it. WCF is a fine approach from what I can
tell.
Anyone want to help lead the charge on the 0-10 .NET client?
Carl.
Re: Where to next...
Posted by Carl Trieloff <cc...@redhat.com>.
I think I might take a hack at putting up a release wiki page
Carl.
Marnie McCormack wrote:
> All,
>
> Apologies for the delay. I've been considering what I think about next
> priorities (as well as having a busy time on return).
>
> I too think an M2.2 would be best avoided unless we encounter any major
> issues.
>
> Here's my conclusions about what it looks like, and I agree with Rob about
> quite a bit of the work on the less feature related items:
>
> Java Broker/Client:
>
> Land the 'bigmergebranch' between M2.1 and truck
> Refactor the broker, as discussed at the F2F on the CSDM side particularly
> Flow To Disk - to make us able to scale and *not* get OoM
> Message Priority - proper implementation, requires broker refactor first
> iirc
> Message Federation (Fan out & forward to remote queue)
> Flow control - throttling of overactive producers
> Exception Handling - argh, needs some work esp on client
> Management Console Improvements - get it building better & test moving of
> messages from queues
> Transparent 0.8/0.9/.10 support
>
> I don't think this is miles from anyone else, aside from message priority.
>
> I don't have a view about the C++ stuff, aside from that (gap-y as it is)
> the Java Documentation is more comprehensive that the other implementations
> and it'd be good to see them catch up a little.
>
> Hth,
> Regards,
> Marnie
>
>
Re: Where to next...
Posted by Marnie McCormack <ma...@googlemail.com>.
All,
Apologies for the delay. I've been considering what I think about next
priorities (as well as having a busy time on return).
I too think an M2.2 would be best avoided unless we encounter any major
issues.
Here's my conclusions about what it looks like, and I agree with Rob about
quite a bit of the work on the less feature related items:
Java Broker/Client:
Land the 'bigmergebranch' between M2.1 and truck
Refactor the broker, as discussed at the F2F on the CSDM side particularly
Flow To Disk - to make us able to scale and *not* get OoM
Message Priority - proper implementation, requires broker refactor first
iirc
Message Federation (Fan out & forward to remote queue)
Flow control - throttling of overactive producers
Exception Handling - argh, needs some work esp on client
Management Console Improvements - get it building better & test moving of
messages from queues
Transparent 0.8/0.9/.10 support
I don't think this is miles from anyone else, aside from message priority.
I don't have a view about the C++ stuff, aside from that (gap-y as it is)
the Java Documentation is more comprehensive that the other implementations
and it'd be good to see them catch up a little.
Hth,
Regards,
Marnie
Re: Where to next...
Posted by Alan Conway <ac...@redhat.com>.
Robert Greig wrote:
> On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>> It looks like M2.1 is landing nicely, so it might be time to start a
>> thread on M3 scope. M3 work
>> has begun as we all know but I think we need to block up what M3 will
>> looks like, JIRA it and do the
>> scope closing for it.
>
> This all looks reasonable to me; my comment would be that we should
> not make the scope too wide so that we can deliver a release that
> gives real benefits in a reasonable time line, e.g. build complete by
> June/July timeframe.
>
>> This is my view of what M3 looks like -- please add, rant, comment etc...
>>
>> - Land the 'bigmergebranch' between M2.1 and truck
>> - Tests, tests and more tests...
>> - Java client M2.1(0-8/9) interop + AMQP 0-10
>> - Java broker merged (still talking 0-8/9?)
>> - Java broker (what else here??)
>> - C++ Broker 0-10 (TCP +IB)
>> - C++ Broker clustering module
>
> Is clustering something that is likely to be ready for M3?
I'm aiming for fault-tolerant C++ broker and failover in at least C++, Java and
python clients in that time frame.
Re: Where to next...
Posted by Robert Greig <ro...@gmail.com>.
On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> It looks like M2.1 is landing nicely, so it might be time to start a
> thread on M3 scope. M3 work
> has begun as we all know but I think we need to block up what M3 will
> looks like, JIRA it and do the
> scope closing for it.
This all looks reasonable to me; my comment would be that we should
not make the scope too wide so that we can deliver a release that
gives real benefits in a reasonable time line, e.g. build complete by
June/July timeframe.
> This is my view of what M3 looks like -- please add, rant, comment etc...
>
> - Land the 'bigmergebranch' between M2.1 and truck
> - Tests, tests and more tests...
> - Java client M2.1(0-8/9) interop + AMQP 0-10
> - Java broker merged (still talking 0-8/9?)
> - Java broker (what else here??)
> - C++ Broker 0-10 (TCP +IB)
> - C++ Broker clustering module
Is clustering something that is likely to be ready for M3?
> - C++ Client 0-10
> - Ruby 0-10
Can someone give an update on the state of the Ruby module? Do we have
anyone who has the bandwidth to work on it? Is anyone using the
existing module?
> - .NET 0-10 (see rabbit has done WCP layer, do we want pick anything up
> from that as it is ASL, do we also want to support 0-8/9 from the same
> client, updating our client...)
I wonder if we want to continue working on our .NET client? I ask that
as a genuine question rather than a statement of my opinion. I think
it would be worthwhile understanding the limitations of a WCF approach
- people will not be surprised given my support of "extended JMS" in
Java to hear that a WCF (or extended WCF) implementation would to me
*seem* the best way of supporting our .NET users.
If the Rabbit client looks good then perhaps it makes sense to
recommend our users adopt it. I know we have struggled to find the
bandwidth to maintain our existing .NET client.
> Other items:
> - do we want to try have common events between brokers for mgmt?
As discussed elsewhere I think this would be good although I would not
think it a big issue if it was an M4 task.
> - I expect that we will work to get the Java broker both 0-8/9 and 0-10
> for M4
> Let's refine the list on mail and then build a JIRA set for M3.
In summary I think getting an M3 with the 0-10 protocol (backwards
compatible to 0-9) would be my focus, keeping the scope of the
released focussed on that.
RG
Where to next...
Posted by Carl Trieloff <cc...@redhat.com>.
Based on some conversations I want to get a thread going on the
following....
It looks like M2.1 is landing nicely, so it might be time to start a
thread on M3 scope. M3 work
has begun as we all know but I think we need to block up what M3 will
looks like, JIRA it and do the
scope closing for it.
This is my view of what M3 looks like -- please add, rant, comment etc...
- Land the 'bigmergebranch' between M2.1 and truck
- Tests, tests and more tests...
- Java client M2.1(0-8/9) interop + AMQP 0-10
- Java broker merged (still talking 0-8/9?)
- Java broker (what else here??)
- C++ Broker 0-10 (TCP +IB)
- C++ Broker clustering module
- C++ Client 0-10
- Ruby 0-10
- .NET 0-10 (see rabbit has done WCP layer, do we want pick anything up
from that as it is ASL, do we also want to support 0-8/9 from the same
client, updating our client...)
Other items:
- do we want to try have common events between brokers for mgmt?
- I expect that we will work to get the Java broker both 0-8/9 and 0-10
for M4
- Lot of DTX & JTA work has been done for Java how to review/ merge etc
this?
Let's refine the list on mail and then build a JIRA set for M3.
Also, do we expect we will need to do a M2.2 - if so what is it?
Carl.
Re: FW: (qpid) Diversity
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> On 06/03/2008, Noel J. Bergman <no...@devtech.com> wrote:
>
>> Daniel Kulp write:
>> > a quick svn log on their SVN repo for all commits since Jan 1 [suggests
>> that]
>>
>>
>>> all but 4 commits since Jan 1 can easily be contributed to RedHat
>>>
>> employees.
>>
>>
>>
>>> I think the above should provide enough information about the health and
>>>
>> > diversity of the community that actually working on the code.
>>
>>
>> What is the Qpid community's response to these findings?
>>
>>
>> --- Noel
>>
>
> Ok I have a few comments in response to the findings:
>
> - Firstly not all work is done on trunk so purely looking at trunk is
> not a good metric
>
> - Looking at the last two months especially as that includes the start
> of the year which is typically a quite period also will show poor
> commit numbers.
>
> - We are preparing for an M2.1 release so a lot of effort is being
> expended on that branch.
>
> My take would be to look at the last 6 months, which admittedly
> includes a number of holiday periods so the count of commits may be a
> little low. Since 2007-09 for the commits on the qpid repository
> shows:
>
> aconway 272
> aidan 54
> arnaudsimon 230
> astitcher 16
> cctrieloff 45
> gsim 201
> kpvdr 11
> nsantos 8
> rajith 169
> rgodfrey 99
> rgreig 98
> rhs 151
> ritchiem 593
> rupertlssmith 468
>
> 1103 RedHat
> 1312 Non-Aligned
>
> So Redhat have less than half the commits to Qpid so I don't think
> this is something we should worry about. Keeping an eye on for sure,
> but over analysing the alignment of those people that don't want to or
> are not allowed to say who they work for is not something that Apache
> requires nor would it be beneficial. Saying that we are not diverse
> because a lot of work on trunk has been done by a small set of people
> over a two month period is not helpful to the discussion.
>
> It is also worth noting that volume of commits does not in anyway
> correspond to the quantity of code changed and even looking at lines
> changes cannot say anything for the quality. I think the fact that we
> have an active project that has matured to the point that where we
> feel as though we can self regulate in the Apache Way speaks far more
> to the community of the project than identifying who is paying the
> bills.
>
> The whole project worked very hard to pull together two servers and
> five client libraries for the M2 release all talking AMQP 0-8. We are
> again working as a community to provide a M2.1 release that will inter
> operate at AMQP 0-9 with other AMQP products outside the Apache world.
> I for one am looking forward to our future releases where we can again
> move the entire project on to the wholly different AMQP 0-10.
>
>
What is the next step on this? Does the concern still exist or should we
take the next step.
regards
Carl.
Re: FW: (qpid) Diversity
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 8, 2008 at 7:03 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Friday 07 March 2008 03:04, Daniel Kulp wrote:
> > That all said, I'm NOT on the IPMC. Thus, my thoughts don't really
> > count other than to provide insight based on MY experiences. I don't
> > have a binding vote.
>
> But your view is highly appreciated.
+1
- robert
Re: FW: (qpid) Diversity
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 March 2008 03:04, Daniel Kulp wrote:
> That all said, I'm NOT on the IPMC. Thus, my thoughts don't really
> count other than to provide insight based on MY experiences. I don't
> have a binding vote.
But your view is highly appreciated.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 6, 2008 at 7:04 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday 06 March 2008, Martin Ritchie wrote:
>
<snip>
> > We are
> > again working as a community to provide a M2.1 release that will inter
> > operate at AMQP 0-9 with other AMQP products outside the Apache world.
> > I for one am looking forward to our future releases where we can again
> > move the entire project on to the wholly different AMQP 0-10.
>
> And nothing stops you from doing all of that while still in the incubator
> while working on trying to furthur diversify your community. Working
> with other AMQP products could be a perfect opportunity to find other
> interested people and get them involved with Qpid. Why rush?
+1
> From experience with CXF, after we got 2.0 and 2.0.1 out the door, we
> thought the same way. "Hey, we worked hard to get the TCK passing,
> integrated with Geronimo, and two releases out, we're ready to go!" but
> Jim (one of our mentors) still had concerns about diversity. Thus, we
> stuck with it and worked hard on getting other people more involved.
> It has paid off as we have added several very good folks that have
> brought fresh ideas and perspectives to the project. If we HAD
> graduated, I'm not sure if we would have spent the time/effort on the
> mentoring and such that was required to bring them on board. We've
> learned a lot in the process. In hind sight, Jim was completely
> correct. Part of the "Apache way" you talk about is being concious of
> things like that.
>
IMHO community building is by far the toughest skill in open source. for a
project to be viable in the long run, it needs to learn to recruit and
mentor new developers.
this takes effort but it's rewarding to see other people with fresh ideas
pick up a project and take it forward. it's great to see someone you helped
take the first steps here at apache progress all the way to member.
prefecting this may well take a lifetime but the basics can be learn by some
hard work.
engaging a wider audience and community then inducting them to share in the
development of a project is the major reason why closed source projects
should choose to open up at apache. the IPMC has failed unless we equip
projects with the lessons needed to thrive in an open development
environment. the reason why we examine projects which arrive from a closed
source background more closely is that they have not had the chance to
develop these skills before arrival. these cannot easily to learnt by
reading but only by doing. so we ask projects to learn by doing: go out and
diversify.
- robert
Re: FW: (qpid) Diversity
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 06 March 2008, Martin Ritchie wrote:
> - Firstly not all work is done on trunk so purely looking at trunk is
> not a good metric
That's fair. I forgot about the work on the branches. That's a very
valid point. Updated list with branches added from Jan 1:
Alan Conway RH 84
Aidan Skinner ? 51
Arnaud Simon RH 48
Andrew Stitcher RH
Carl Trieloff RH 6
Gordon Sim RH 40
Jim Meyering ?
John O'Hara JPMC
Marnie McCormack JPMC (maternity)
Martin Ritchie JMPC 42
Kim van der Riet RH
Nuno Santos RH 6
Rafael Schloming RH 56
Rajith Attapattu RH 24
Robert Godfrey JPMC 14
Robert Greig. JPMC
Rupert Smith ? 36
264 RH
143 Non-RH
Back to Nov 1:
Alan Conway RH 167
Aidan Skinner 51
Arnaud Simon RH 105
Andrew Stitcher RH 5
Carl Trieloff RH 22
Gordon Sim RH 107
Jim Meyering
John O'Hara JPMC
Marnie McCormack JPMC (maternity)
Martin Ritchie JMPC 81
Kim van der Riet RH 10
Nuno Santos RH 7
Rafael Schloming RH 60
Rajith Attapattu RH 58
Robert Godfrey JPMC 20
Robert Greig. JPMC
Rupert Smith 63
541 RH
215 Non-RH
> - Looking at the last two months especially as that includes the start
> of the year which is typically a quite period also will show poor
> commit numbers.
Yes, lower numbers, but they should still be relatively proportional as
it should be just as poor for RH folks as for non RH folks, right?
The issue isn't the number of commits, it's who is doing them. Anyway,
I added a 4 months set shown above.
Yes, # of commits is not a "good" metric as different people work
different ways. Example: I tend to commit small things several times a
day. If I find a spelling mistake, it gets committed. Other people
save things up and do larger commits. It's all personal. The thing
that the IPMC needs to know more about are "trends". Is the community
getting better or worse from a diversity standpoint. That IS
subjective to some extent and each IPMC member may interpret the data
differently, but the point is they need the data. Thus, having the 6
month, 4 month, and 2 month numbers is a start.
> - We are preparing for an M2.1 release so a lot of effort is being
> expended on that branch.
Fine. I included the entire trunk + branches dirs.
> My take would be to look at the last 6 months, which admittedly
> includes a number of holiday periods so the count of commits may be a
> little low. Since 2007-09 for the commits on the qpid repository
> shows:
>
> aconway 272
> aidan 54
> arnaudsimon 230
> astitcher 16
> cctrieloff 45
> gsim 201
> kpvdr 11
> nsantos 8
> rajith 169
> rgodfrey 99
> rgreig 98
> rhs 151
> ritchiem 593
> rupertlssmith 468
>
> 1103 RedHat
> 1312 Non-Aligned
>
> So Redhat have less than half the commits to Qpid so I don't think
> this is something we should worry about.
It IS something to worry about if all the "Non-Aligned" folks really are
aligned together under one entity. The questions that each IPMC member
needs to answer for themselves based on all the metrics are:
1) If RedHat decides tomorrow to pull all it's engineers off of qpid,
would the project survive?
2) If the "entity" behind the "non-aligns" gets bought out by another
entity that has no interest in AMQP and pulls the engineers off, will
the project survive?
Those are the things the IPMC must consider (and the board if graduating
top level) as it affects the long term viability of the project.
> Keeping an eye on for sure,
> but over analysing the alignment of those people that don't want to or
> are not allowed to say who they work for is not something that Apache
> requires nor would it be beneficial. Saying that we are not diverse
> because a lot of work on trunk has been done by a small set of people
> over a two month period is not helpful to the discussion.
But it helps provide insite into the above questions, so it is helpful.
Other things that aren't even mentioned in this are things like
participation on the dev list, documentation updates, wiki updates, JIRA
cleanups, etc.... Those are all ALSO important metrics and maybe some
of the folks above are more valuable in areas other than the raw code.
There are lots of roles in a community, the code is just a single metric
amoungst many. For example:
http://markmail.org/search/?q=qpid+type%3Adevelopment+date%3A200709-200803
is another metric.
> It is also worth noting that volume of commits does not in anyway
> correspond to the quantity of code changed and even looking at lines
> changes cannot say anything for the quality. I think the fact that we
> have an active project that has matured to the point that where we
> feel as though we can self regulate in the Apache Way speaks far more
> to the community of the project than identifying who is paying the
> bills.
>
> The whole project worked very hard to pull together two servers and
> five client libraries for the M2 release all talking AMQP 0-8.
And that is all to be commended. It was a good effort.
> We are
> again working as a community to provide a M2.1 release that will inter
> operate at AMQP 0-9 with other AMQP products outside the Apache world.
> I for one am looking forward to our future releases where we can again
> move the entire project on to the wholly different AMQP 0-10.
And nothing stops you from doing all of that while still in the incubator
while working on trying to furthur diversify your community. Working
with other AMQP products could be a perfect opportunity to find other
interested people and get them involved with Qpid. Why rush?
From experience with CXF, after we got 2.0 and 2.0.1 out the door, we
thought the same way. "Hey, we worked hard to get the TCK passing,
integrated with Geronimo, and two releases out, we're ready to go!" but
Jim (one of our mentors) still had concerns about diversity. Thus, we
stuck with it and worked hard on getting other people more involved.
It has paid off as we have added several very good folks that have
brought fresh ideas and perspectives to the project. If we HAD
graduated, I'm not sure if we would have spent the time/effort on the
mentoring and such that was required to bring them on board. We've
learned a lot in the process. In hind sight, Jim was completely
correct. Part of the "Apache way" you talk about is being concious of
things like that.
Another metric I personally like to look at is how well the community has
interacted with the "Apache community as a whole." Aka: have they
worked well with other Apache projects and such. While not a
requirement, this helps to show how well the folks "get it". Looking at
the list of committers, only Rajith is a committer on stuff other than
qpid. When you found bugs in the projects you depend on (like Mina),
did you file patches and stuff to help out those communities or did you
just file a bug and say "fix it"? Did you work with them to try and get
a release incorporating your changes/fixes? Again, not a requirement,
just another metric that is weighed in with everything else. In the
other direction, when other projects wanted to use qpid, did you help
them out? This is an important part of trying to grow your community.
If more people use it, the more likely they will contribute patches and
ideas and potentially become committers. In my experience, the answer
to #2 was "barely". I wanted to add qpid JMS testing to CXF and I WAS
working with qpid folks to help get M2 artifacts publishable/releasable
to maven repos so maven based projects could use it, but a last minute
decision (off list, that's another issue) killed that and I'm still
stuck. Again, that was MY experience. Other folks may have had a
better experience. I know Rajith has done some work with Synapse. Not
sure the extent or result. Again, not "required", just another data
point.
"Is the community ready to graduate?" is a very subjective opinion.
There are a LOT of variables that go into it and each IPMC member will
weigh them differently. Each IPMC member has different past experiences
and different priorities. The community thinking they are ready is
only one small part of it.
That all said, I'm NOT on the IPMC. Thus, my thoughts don't really
count other than to provide insight based on MY experiences. I don't
have a binding vote. The IPMC folks are the ones that will need to
figure out if the diversity of the qpid community is a concern and, if
so, if the qpid community has taken steps to rectify that.
Anyway, that's my inflation adjusted $.02 worth.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> On 06/03/2008, Noel J. Bergman <no...@devtech.com> wrote:
>
>> Daniel Kulp write:
>> > a quick svn log on their SVN repo for all commits since Jan 1 [suggests
>> that]
>>
>>
>>> all but 4 commits since Jan 1 can easily be contributed to RedHat
>>>
>> employees.
>>
>>
>>
>>> I think the above should provide enough information about the health and
>>>
>> > diversity of the community that actually working on the code.
>>
>>
>> What is the Qpid community's response to these findings?
>>
>>
>> --- Noel
>>
>
> Ok I have a few comments in response to the findings:
>
> - Firstly not all work is done on trunk so purely looking at trunk is
> not a good metric
>
> - Looking at the last two months especially as that includes the start
> of the year which is typically a quite period also will show poor
> commit numbers.
>
> - We are preparing for an M2.1 release so a lot of effort is being
> expended on that branch.
>
> My take would be to look at the last 6 months, which admittedly
> includes a number of holiday periods so the count of commits may be a
> little low. Since 2007-09 for the commits on the qpid repository
> shows:
>
> aconway 272
> aidan 54
> arnaudsimon 230
> astitcher 16
> cctrieloff 45
> gsim 201
> kpvdr 11
> nsantos 8
> rajith 169
> rgodfrey 99
> rgreig 98
> rhs 151
> ritchiem 593
> rupertlssmith 468
>
> 1103 RedHat
> 1312 Non-Aligned
>
> So Redhat have less than half the commits to Qpid so I don't think
> this is something we should worry about. Keeping an eye on for sure,
> but over analysing the alignment of those people that don't want to or
> are not allowed to say who they work for is not something that Apache
> requires nor would it be beneficial. Saying that we are not diverse
> because a lot of work on trunk has been done by a small set of people
> over a two month period is not helpful to the discussion.
>
> It is also worth noting that volume of commits does not in anyway
> correspond to the quantity of code changed and even looking at lines
> changes cannot say anything for the quality. I think the fact that we
> have an active project that has matured to the point that where we
> feel as though we can self regulate in the Apache Way speaks far more
> to the community of the project than identifying who is paying the
> bills.
>
> The whole project worked very hard to pull together two servers and
> five client libraries for the M2 release all talking AMQP 0-8. We are
> again working as a community to provide a M2.1 release that will inter
> operate at AMQP 0-9 with other AMQP products outside the Apache world.
> I for one am looking forward to our future releases where we can again
> move the entire project on to the wholly different AMQP 0-10.
>
>
What is the next step on this? Does the concern still exist or should we
take the next step.
regards
Carl.
Re: (qpid) Diversity
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 10 March 2008 15:24, William A. Rowe, Jr. wrote:
> Exactly; not every computer professional to walk in to their boss/client
> and say "hey - I want to invent software for us, and publish it however
> I like". But it's feasible to say "hey - we could accomplish x, y and z
> if I was contributing changes to this code we use to the ASF, but I need
> this agreement signed off since my employment agreement / work for hire
> ownership issues are in my way from doing that".
Yes and No.
We say that ASF requires the CCLA, even for individuals that are in
jurisdictions/situations where it is superflous. THAT is different from the
scenario described above. AFAIK, we don't say; "If you are uncertain of your
rights, please have your employer sign the CCLA for your own protection
against your employer, and the ASF will keep it safe for you.", which seems
to be a more accurate description of reality.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: (qpid) Diversity
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> One more thing; I can't recall seeing that we encourage people to have new
> CCLAs submitted from new employers when they change jobs. My guess is that it
> is commonly forgotten, since it is not spoken much of.
That's why it should be reframed to it's original point; the committer / CLA
signer is responsible for the agreement they sign with the ASF. That's the
very beginning and end of story.
If another contract would void, negate or superscede *their* CLA, they are
solely responsible to fix that. The CCLA helps them do that without having
to navigate complicated work for hire laws, employment laws, and their own
employement agreement or commercial contracts, etc.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: (qpid) Diversity
Posted by Niclas Hedhman <ni...@hedhman.org>.
One more thing; I can't recall seeing that we encourage people to have new
CCLAs submitted from new employers when they change jobs. My guess is that it
is commonly forgotten, since it is not spoken much of.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: (qpid) Diversity
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote:
>> On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
>>> So the CCLA exists for those who's employment agreements would otherwise
>>> cause them to violate their claims made via their CLA contract.
>>
>> Uhhh.... So, are we now saying that heaps of people don't need to get
>> the CCLA
>> from their employer? I thought the CCLA was the "belt and suspenders" to
>> ensure that the employee has the right that he claims. Otherwise, why
>> is the
>> CCLA a matter between the employer and ASF, and not a standard
>> document to be
>> signed between the employer and employee, for the employee to keep.
>
> Because it is more politically correct (easier for the employee) if the paper
> says it is coming from the ASF, it is a lot easier for the employer to
> understand why another corporation would need that permission, and it is
> a lot less likely to be "lost" if it is recorded with a third party.
> The employee can (and should) keep a copy for themselves in their own
> records.
Exactly; not every computer professional to walk in to their boss/client
and say "hey - I want to invent software for us, and publish it however
I like". But it's feasible to say "hey - we could accomplish x, y and z
if I was contributing changes to this code we use to the ASF, but I need
this agreement signed off since my employment agreement / work for hire
ownership issues are in my way from doing that".
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: (qpid) Diversity
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote:
>> On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
>>> So the CCLA exists for those who's employment agreements would otherwise
>>> cause them to violate their claims made via their CLA contract.
>>
>> Uhhh.... So, are we now saying that heaps of people don't need to get
>> the CCLA
>> from their employer? I thought the CCLA was the "belt and suspenders" to
>> ensure that the employee has the right that he claims. Otherwise, why
>> is the
>> CCLA a matter between the employer and ASF, and not a standard
>> document to be
>> signed between the employer and employee, for the employee to keep.
>
> Because it is more politically correct (easier for the employee) if the paper
> says it is coming from the ASF, it is a lot easier for the employer to
> understand why another corporation would need that permission, and it is
> a lot less likely to be "lost" if it is recorded with a third party.
> The employee can (and should) keep a copy for themselves in their own
> records.
Exactly; not every computer professional to walk in to their boss/client
and say "hey - I want to invent software for us, and publish it however
I like". But it's feasible to say "hey - we could accomplish x, y and z
if I was contributing changes to this code we use to the ASF, but I need
this agreement signed off since my employment agreement / work for hire
ownership issues are in my way from doing that".
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: (qpid) Diversity
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote:
> On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
>> So the CCLA exists for those who's employment agreements would
>> otherwise
>> cause them to violate their claims made via their CLA contract.
>
> Uhhh.... So, are we now saying that heaps of people don't need to
> get the CCLA
> from their employer? I thought the CCLA was the "belt and
> suspenders" to
> ensure that the employee has the right that he claims. Otherwise,
> why is the
> CCLA a matter between the employer and ASF, and not a standard
> document to be
> signed between the employer and employee, for the employee to keep.
Because it is more politically correct (easier for the employee) if
the paper
says it is coming from the ASF, it is a lot easier for the employer to
understand why another corporation would need that permission, and it is
a lot less likely to be "lost" if it is recorded with a third party.
The employee can (and should) keep a copy for themselves in their own
records.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: (qpid) Diversity
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote:
> On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
>> So the CCLA exists for those who's employment agreements would
>> otherwise
>> cause them to violate their claims made via their CLA contract.
>
> Uhhh.... So, are we now saying that heaps of people don't need to
> get the CCLA
> from their employer? I thought the CCLA was the "belt and
> suspenders" to
> ensure that the employee has the right that he claims. Otherwise,
> why is the
> CCLA a matter between the employer and ASF, and not a standard
> document to be
> signed between the employer and employee, for the employee to keep.
Because it is more politically correct (easier for the employee) if
the paper
says it is coming from the ASF, it is a lot easier for the employer to
understand why another corporation would need that permission, and it is
a lot less likely to be "lost" if it is recorded with a third party.
The employee can (and should) keep a copy for themselves in their own
records.
....Roy
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: FW: (qpid) Diversity
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
> So the CCLA exists for those who's employment agreements would otherwise
> cause them to violate their claims made via their CLA contract.
Uhhh.... So, are we now saying that heaps of people don't need to get the CCLA
from their employer? I thought the CCLA was the "belt and suspenders" to
ensure that the employee has the right that he claims. Otherwise, why is the
CCLA a matter between the employer and ASF, and not a standard document to be
signed between the employer and employee, for the employee to keep.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: FW: (qpid) Diversity
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
> So the CCLA exists for those who's employment agreements would otherwise
> cause them to violate their claims made via their CLA contract.
Uhhh.... So, are we now saying that heaps of people don't need to get the CCLA
from their employer? I thought the CCLA was the "belt and suspenders" to
ensure that the employee has the right that he claims. Otherwise, why is the
CCLA a matter between the employer and ASF, and not a standard document to be
signed between the employer and employee, for the employee to keep.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Scott Deboy wrote:
> Does ASF need proof that a transfer of intellectual property ownership
> occurred?
In your CLA - you attest that you have that right. If you don't - it's
on you to remedy it. The ASF doesn't broker relationships between
developers and their employers, clients, or spouses :)
So the CCLA exists for those who's employment agreements would otherwise
cause them to violate their claims made via their CLA contract.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: FW: (qpid) Diversity
Posted by Scott Deboy <sd...@comotivsystems.com>.
Does ASF need proof that a transfer of intellectual property ownership
occurred?
Scott Deboy
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Thursday, March 06, 2008 3:10 PM
To: qpid-private@incubator.apache.org; general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity
On 06/03/2008, Scott Deboy <sd...@comotivsystems.com> wrote:
> For the qpid folks who don't want to divulge their employer: are they
> working on the project as part of their employment? If so, it would
> appear we need a CCLA, correct?
I do not believe so since those employees have signed legal documents
with the employer where the employer has transferred the intellectual
property ownership to the employee.
Therefore those committers are effectively working as private
individuals.
RG
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Robert Greig <ro...@gmail.com>.
On 06/03/2008, Scott Deboy <sd...@comotivsystems.com> wrote:
> For the qpid folks who don't want to divulge their employer: are they
> working on the project as part of their employment? If so, it would
> appear we need a CCLA, correct?
I do not believe so since those employees have signed legal documents
with the employer where the employer has transferred the intellectual
property ownership to the employee.
Therefore those committers are effectively working as private individuals.
RG
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: FW: (qpid) Diversity
Posted by Scott Deboy <sd...@comotivsystems.com>.
For the qpid folks who don't want to divulge their employer: are they
working on the project as part of their employment? If so, it would
appear we need a CCLA, correct?
If we don't know the committer's employer (and they're working on the
project as an employee), we can't determine if a CCLA is on file.
>From http://www.apache.org/licenses/
---
For a corporation that has assigned employees to work on an Apache
project, a Corporate CLA (CCLA) is available for contributing
intellectual property via the corporation, that may have been assigned
as part of an employment agreement. Note that a Corporate CLA does not
remove the need for every developer to sign their own CLA as an
individual, to cover any of their contributions which are not owned by
the corporation signing the CCLA.
----
Scott Deboy
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, March 06, 2008 10:48 AM
To: general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity
On Thu, Mar 6, 2008 at 8:23 AM, Martin Ritchie <ri...@apache.org>
wrote:
> On 06/03/2008, Noel J. Bergman <no...@devtech.com> wrote:
> > Daniel Kulp write:
> > > a quick svn log on their SVN repo for all commits since Jan 1
> [suggests
> > that]
> >
> > > all but 4 commits since Jan 1 can easily be contributed to RedHat
> > employees.
> >
> >
> > > I think the above should provide enough information about the
health
> and
> > > diversity of the community that actually working on the code.
> >
> >
> > What is the Qpid community's response to these findings?
> >
> >
> > --- Noel
>
I believe if a committer has signed the required legal documents then
thats
all what matters.
If they are uncomfortable disclosing their employer then perhaps we
should
respect that.
What is important is that these folks are contributing to the project in
a
legal manner.
The last thing we want is to discourage people from contributing.
As martin has pointed out, looking at the last 6 months and just the
trunk
is not a fair evaluation of diversity.
We should also not forget the significant contributions made by the
following folks in the last year or two.
Off the top of my head.
Colin Crist - Hermes JMS integration
Kevin Smith - SSL patch for the java broker.
Steve Vinoski - Maven build system
Tomas Restrepo - .NET client.
There was also a few individuals who made patches for the python client
to
get it interoperating with other open source implementations.
I am very optimistic that our community will continue to grow with more
contributions as we increase our visibility and efforts to integrate
with
other projects like Synapse, Axis2, Tuscany, CXF etc..
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
>
> Ok I have a few comments in response to the findings:
>
> - Firstly not all work is done on trunk so purely looking at trunk is
> not a good metric
>
> - Looking at the last two months especially as that includes the start
> of the year which is typically a quite period also will show poor
> commit numbers.
>
> - We are preparing for an M2.1 release so a lot of effort is being
> expended on that branch.
>
> My take would be to look at the last 6 months, which admittedly
> includes a number of holiday periods so the count of commits may be a
> little low. Since 2007-09 for the commits on the qpid repository
> shows:
>
> aconway 272
> aidan 54
> arnaudsimon 230
> astitcher 16
> cctrieloff 45
> gsim 201
> kpvdr 11
> nsantos 8
> rajith 169
> rgodfrey 99
> rgreig 98
> rhs 151
> ritchiem 593
> rupertlssmith 468
>
> 1103 RedHat
> 1312 Non-Aligned
>
> So Redhat have less than half the commits to Qpid so I don't think
> this is something we should worry about. Keeping an eye on for sure,
> but over analysing the alignment of those people that don't want to or
> are not allowed to say who they work for is not something that Apache
> requires nor would it be beneficial. Saying that we are not diverse
> because a lot of work on trunk has been done by a small set of people
> over a two month period is not helpful to the discussion.
>
> It is also worth noting that volume of commits does not in anyway
> correspond to the quantity of code changed and even looking at lines
> changes cannot say anything for the quality. I think the fact that we
> have an active project that has matured to the point that where we
> feel as though we can self regulate in the Apache Way speaks far more
> to the community of the project than identifying who is paying the
> bills.
>
> The whole project worked very hard to pull together two servers and
> five client libraries for the M2 release all talking AMQP 0-8. We are
> again working as a community to provide a M2.1 release that will inter
> operate at AMQP 0-9 with other AMQP products outside the Apache world.
> I for one am looking forward to our future releases where we can again
> move the entire project on to the wholly different AMQP 0-10.
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Mar 6, 2008 at 8:23 AM, Martin Ritchie <ri...@apache.org> wrote:
> On 06/03/2008, Noel J. Bergman <no...@devtech.com> wrote:
> > Daniel Kulp write:
> > > a quick svn log on their SVN repo for all commits since Jan 1
> [suggests
> > that]
> >
> > > all but 4 commits since Jan 1 can easily be contributed to RedHat
> > employees.
> >
> >
> > > I think the above should provide enough information about the health
> and
> > > diversity of the community that actually working on the code.
> >
> >
> > What is the Qpid community's response to these findings?
> >
> >
> > --- Noel
>
I believe if a committer has signed the required legal documents then thats
all what matters.
If they are uncomfortable disclosing their employer then perhaps we should
respect that.
What is important is that these folks are contributing to the project in a
legal manner.
The last thing we want is to discourage people from contributing.
As martin has pointed out, looking at the last 6 months and just the trunk
is not a fair evaluation of diversity.
We should also not forget the significant contributions made by the
following folks in the last year or two.
Off the top of my head.
Colin Crist - Hermes JMS integration
Kevin Smith - SSL patch for the java broker.
Steve Vinoski - Maven build system
Tomas Restrepo - .NET client.
There was also a few individuals who made patches for the python client to
get it interoperating with other open source implementations.
I am very optimistic that our community will continue to grow with more
contributions as we increase our visibility and efforts to integrate with
other projects like Synapse, Axis2, Tuscany, CXF etc..
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
>
> Ok I have a few comments in response to the findings:
>
> - Firstly not all work is done on trunk so purely looking at trunk is
> not a good metric
>
> - Looking at the last two months especially as that includes the start
> of the year which is typically a quite period also will show poor
> commit numbers.
>
> - We are preparing for an M2.1 release so a lot of effort is being
> expended on that branch.
>
> My take would be to look at the last 6 months, which admittedly
> includes a number of holiday periods so the count of commits may be a
> little low. Since 2007-09 for the commits on the qpid repository
> shows:
>
> aconway 272
> aidan 54
> arnaudsimon 230
> astitcher 16
> cctrieloff 45
> gsim 201
> kpvdr 11
> nsantos 8
> rajith 169
> rgodfrey 99
> rgreig 98
> rhs 151
> ritchiem 593
> rupertlssmith 468
>
> 1103 RedHat
> 1312 Non-Aligned
>
> So Redhat have less than half the commits to Qpid so I don't think
> this is something we should worry about. Keeping an eye on for sure,
> but over analysing the alignment of those people that don't want to or
> are not allowed to say who they work for is not something that Apache
> requires nor would it be beneficial. Saying that we are not diverse
> because a lot of work on trunk has been done by a small set of people
> over a two month period is not helpful to the discussion.
>
> It is also worth noting that volume of commits does not in anyway
> correspond to the quantity of code changed and even looking at lines
> changes cannot say anything for the quality. I think the fact that we
> have an active project that has matured to the point that where we
> feel as though we can self regulate in the Apache Way speaks far more
> to the community of the project than identifying who is paying the
> bills.
>
> The whole project worked very hard to pull together two servers and
> five client libraries for the M2 release all talking AMQP 0-8. We are
> again working as a community to provide a M2.1 release that will inter
> operate at AMQP 0-9 with other AMQP products outside the Apache world.
> I for one am looking forward to our future releases where we can again
> move the entire project on to the wholly different AMQP 0-10.
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: FW: (qpid) Diversity
Posted by Martin Ritchie <ri...@apache.org>.
On 06/03/2008, Noel J. Bergman <no...@devtech.com> wrote:
> Daniel Kulp write:
> > a quick svn log on their SVN repo for all commits since Jan 1 [suggests
> that]
>
> > all but 4 commits since Jan 1 can easily be contributed to RedHat
> employees.
>
>
> > I think the above should provide enough information about the health and
> > diversity of the community that actually working on the code.
>
>
> What is the Qpid community's response to these findings?
>
>
> --- Noel
Ok I have a few comments in response to the findings:
- Firstly not all work is done on trunk so purely looking at trunk is
not a good metric
- Looking at the last two months especially as that includes the start
of the year which is typically a quite period also will show poor
commit numbers.
- We are preparing for an M2.1 release so a lot of effort is being
expended on that branch.
My take would be to look at the last 6 months, which admittedly
includes a number of holiday periods so the count of commits may be a
little low. Since 2007-09 for the commits on the qpid repository
shows:
aconway 272
aidan 54
arnaudsimon 230
astitcher 16
cctrieloff 45
gsim 201
kpvdr 11
nsantos 8
rajith 169
rgodfrey 99
rgreig 98
rhs 151
ritchiem 593
rupertlssmith 468
1103 RedHat
1312 Non-Aligned
So Redhat have less than half the commits to Qpid so I don't think
this is something we should worry about. Keeping an eye on for sure,
but over analysing the alignment of those people that don't want to or
are not allowed to say who they work for is not something that Apache
requires nor would it be beneficial. Saying that we are not diverse
because a lot of work on trunk has been done by a small set of people
over a two month period is not helpful to the discussion.
It is also worth noting that volume of commits does not in anyway
correspond to the quantity of code changed and even looking at lines
changes cannot say anything for the quality. I think the fact that we
have an active project that has matured to the point that where we
feel as though we can self regulate in the Apache Way speaks far more
to the community of the project than identifying who is paying the
bills.
The whole project worked very hard to pull together two servers and
five client libraries for the M2 release all talking AMQP 0-8. We are
again working as a community to provide a M2.1 release that will inter
operate at AMQP 0-9 with other AMQP products outside the Apache world.
I for one am looking forward to our future releases where we can again
move the entire project on to the wholly different AMQP 0-10.
--
Martin Ritchie
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: FW: (qpid) Diversity
Posted by "Noel J. Bergman" <no...@devtech.com>.
Daniel Kulp write:
> a quick svn log on their SVN repo for all commits since Jan 1 [suggests
that]
> all but 4 commits since Jan 1 can easily be contributed to RedHat
employees.
> I think the above should provide enough information about the health and
> diversity of the community that actually working on the code.
What is the Qpid community's response to these findings?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: FW: (qpid) Diversity
Posted by Daniel Kulp <dk...@apache.org>.
Well, a quick svn log on their SVN repo for all commits since Jan 1 and
some google/"linked in" searches yields: (disclaimer: I could be wrong
on some of these, it was a quick search, people may no longer be with
these companies, etc...)
Committer Company #Commits
Aidan Skinner 2
Alan Conway RH 84
Arnaud Simon RH 48
Andrew Stitcher RH
Carl Trieloff RH 5
Gordon Sim RH 38
Jim Meyering
John O'Hara JPMC
Marnie McCormack JPMC
Martin Ritchie JMPC 2
Kim van der Riet RH
Nuno Santos RH 6
Rafael Schloming RH 56
Rajith Attapattu RH 24
Robert Godfrey JPMC
Robert Greig. JPMC
Rupert Smith
Mentors:
Paul Fremantle
Yoav Shapira
Thus, all but 4 commits since Jan 1 can easily be contributed to RedHat
employees. I couldn't quickly find company affiliations for 3 of the
folks, but I think the above should provide enough information about the
health and diversity of the community that actually working on the code.
I didn't look at the dev list or wiki changes or anything so there could
be additional contributions there.
Dan
On Tuesday 04 March 2008, Scott Deboy wrote:
> I'm curious what other incubator folks think about qpid's plan for
> disclosing the organizational diversity of their committership/PMC (or
> if this is even a requirement).
>
> Scott Deboy
> COMOTIV SYSTEMS
> 111 SW Columbia Street Ste. 950
> Portland, OR 97201
>
> Telephone: 503.224.7496
> Cell: 503.997.1367
> Fax: 503.222.0185
>
> sdeboy@comotivsystems.com
>
> www.comotivsystems.com
>
>
>
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
> Sent: Tue 3/4/2008 1:08 PM
> To: qpid-private@incubator.apache.org
> Subject: Re: Diversity
>
> Scott Deboy wrote:
> > Since there is a significant amount of corporate support in qpid,
> > I'd like to see the breakdown of that support in the committership
> > and PMC. If this was discussed previously, can you direct me to the
> > thread?
> >
> > Thanks
> >
> > Scott Deboy
>
> Scott,
>
> I know from past discussions that some members of Qpid are not allowed
> to disclose who they work for. I am sure they will comment. There is
> no secret that I work for Red Hat. As I know this is going to come up,
> to get through this we might need to let people say there company name
> or "not one of the above..."
>
> does that work. The goal is to show one company does not have all the
> seats.
>
> There is a thread with the broken out, but it does not include company
> names.
> regards,
> Carl.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org