Qpid working with AMQP Working Group

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

When the project was proposed, one concern that was raised on the 
incubator general list was (quoting board report) "Making sure we are 
comfortable with the working relationship between Qpid and the AMQP 
Working Group." This concern has been posted on every board report so far.

Looking back through the posts when Qpid was accepted into incubator, it 
seems clear the AMQP Working group is no more restrictive than most 
other specification groups from which other Apache projects are 
implementing. Cliff summarized this in one of these early posts. 
{http://www.mail-archive.com/general@incubator.apache.org/msg09394.html} 
>From that mail:

(1) Licensing of the specification.

Quote from Cliff's mail "* The bad news on this is that the spec license 
appears only to grant copy, display, and implement rights, not distribution.
* The good news is that I asked Carl about this today, and he says he's 
surprised at that as well and expects it is only an administrative 
hassle to get it fixed, but that it will happen.
 * The ugly news is that the SCA spec that Tuscany is based upon seems 
to have the same problem."

-->This has been addressed by an update the the license, "distribute" 
has been added and M1 was released with this update.

(2) Application of the non-public specification drafts.

Quote from Cliff's mail " If a project is chartered to implement a 
specification (whether in a standards body or not), I don't ever want to 
see code committed to its /trunk that is fulfilling the implementation 
of a private version of a specification."

--> This has been taken off the table by the working group since by 
voting to make all the development public, more on this later.

(3) Openness of participation in the specification.

This is a long section in cliff mail and the thread that resulted is 
even longer.... To best sum up the issue I quote from Cliff's mail again 
"If an Apache project is based on a specification that is driven by a 
closed set of authors, including some, but not all committers, how can 
the technical decisions of the project truly be based on an open 
meritocracy?"

--> the Working Group has seen individuals join the group and provide 
very good feedback to the specification, so far no-one has requested 
that we proceed or require/work any of the options suggested by Cliff. 
If needed I can outline them.

It thus seems that the underlying question that was open at time of 
acceptance into incubator was "Are those contributing to Qpid able to 
interact with and view/influence information from the AMQP Working 
Group?" Refreshing my memory, I have searched the Qpid lists and could 
not find any issues between the Qpid project and the Working Group. I 
expect that this is mainly due to the transparency of specification 
process of the Working Group and the fact that all its mailing lists & 
wiki pages for the specification development are public (this was not 
the case when the group started). I believe that this has eliminated 
most of the concerns.

As we have been working on the Qpid code base for quite some time now, I 
would like to get feedback from others on Qpid regarding the ability to 
get the specification and work-in-process. If those on the list are 
comfortable with this issue I would like to remove it from our next 
board report or address any outstanding problems.

regards,
Carl.

Re: Qpid working with AMQP Working Group

[Marnie McCormack <ma...@googlemail.com>]

Hi Carl,

I think this is a very useful discussion, what with 0.10 coming up and the
various 0.9 WIP debates.

My tuppence follows ..... hth !

I think the changes made to the way in which the AMQP spec changes are
progressed have made it far easier to keep track of the protocol i.e. JIRAs
etc and also eased contribution to the protocol discussions (though it does
require significant bandwidth).

However, I do think that from a Qpid perspective we should attempt to define
how we track the protocol in our roadmap. I know roadmap(s) for Qpid are
currently virtual, but we should (imho) attempt to capture our plans for
Qpid features alongside the work we need/plan to do to keep in step with the
protocol. I'd always imagined we'd have JIRA refs in Qpid JIRAs to work
defined in AMQP JIRAs, or similar, to capture the work needed or protocol
enablers requested for Qpid features etc.

AMQP 0.10 will introduce a) work Qpid must do and b) work Qpid can now do (
i.e. enablers for such things are dead letter queue config options etc).
This work will be significant in terms of developer effort, and also in
terms of its impact on Qpid in release/graduation terms I guess. We should
try to capture it in a collated form and estimate it to make the picture
clearer, imho ?

I'm not currently in a great position to move things forward from a
practical perspective, but thought I'd send my thoughts just the same :-)

Hope this finds you well,
Regards,
Marnie


On 5/25/07, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> Tomas
>
> Thanks, this is helpful. The JIRA should be viewable, I will get that
> followed up. With regard to the schedule that is currently a much
> debated topic to what the next release 0-11 will focus on ( 0-10 is
> about done). I agree that it would be good to have that information for
> planning purposes. At this point the thoughts are to Security and
> Management but the Working Group has not completed that debate started
> at the F2F they had in NYC.
>
> I will post your issue found on the amqp.org site to the AMQP Working
> Group.
>
> regards
> Carl.
>
>
>
> Tomas Restrepo wrote:
> > Hi Carl,
> >
> >
> >> (3) Openness of participation in the specification.
> >>
> >> This is a long section in cliff mail and the thread that resulted is
> >> even longer.... To best sum up the issue I quote from Cliff's mail
> >> again
> >> "If an Apache project is based on a specification that is driven by a
> >> closed set of authors, including some, but not all committers, how can
> >> the technical decisions of the project truly be based on an open
> >> meritocracy?"
> >>
> >> --> the Working Group has seen individuals join the group and provide
> >> very good feedback to the specification, so far no-one has requested
> >> that we proceed or require/work any of the options suggested by Cliff.
> >> If needed I can outline them.
> >>
> >> It thus seems that the underlying question that was open at time of
> >> acceptance into incubator was "Are those contributing to Qpid able to
> >> interact with and view/influence information from the AMQP Working
> >> Group?" Refreshing my memory, I have searched the Qpid lists and could
> >> not find any issues between the Qpid project and the Working Group.
> >>
> >
> > I'm not sure what all the fuzz is about, however, fwiw, here's a couple
> of
> > comments:
> >
> > 1- I check on the protocol mailing lists every now on then, and it can
> > certainly be very enlightening and it's very useful to see those
> discussions
> > out in the open; I think it's very valuable for all people involved. Not
> all
> > information seems to be public though, and that can hinder sometimes the
> > process (for example, last I checked the jira for the working group was
> > private and seeing as how many of the posts on the mailing lists
> archives
> > reference issues there, it's sometimes hard to really understand what's
> > being said).
> >
> > 2- As for interaction with the working group; well, I know several of
> the
> > qpid project members are involved in the working group, and that's a
> good
> > thing. I once tried to get access to provide feedback on the
> specifications
> > (following the process outlined in
> > http://www.amqp.org/tikiwiki/tiki-index.php?page=AMQP_User) but didn't
> have
> > much success there; so I'm not quite sure what the process should be.
> >
> > Even though I personally have some concerns about portions of the
> protocol
> > specs and the direction it is headed, there's not really a good way to
> > provide feedback on that at this point and I've preferred to keep my
> > comments on the spec itself off the qpid lists, as I don't want to
> clutter
> > the project's list with other stuff.
> >
> > So given that, my opinion is that the current mechanism isn't really all
> > wide open. It's good that it's transparent, but seems to be pretty much
> > read-only from where I stand (not that there's anything intrinsically
> wrong
> > with that).
> >
> > Also, fwiw, I do think the lack of a clearer schedule from the working
> group
> > on the specification process hinders a bit planning for the qpid
> project, as
> > evidenced a bit by the recent discussions on what to implement and when
> and
> > 0.8 vs. 0.9 vs. 0.10., but that's a different matter altogether.
> >
> > Just my $0.00000000002 cents worth :)
> >
> >
> > Tomas Restrepo
> > http://www.winterdom.com/weblog/
> >
> >
> >
> >
>
>

Re: Qpid working with AMQP Working Group

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

Tomas

Thanks, this is helpful. The JIRA should be viewable, I will get that 
followed up. With regard to the schedule that is currently a much 
debated topic to what the next release 0-11 will focus on ( 0-10 is 
about done). I agree that it would be good to have that information for 
planning purposes. At this point the thoughts are to Security and 
Management but the Working Group has not completed that debate started 
at the F2F they had in NYC.

I will post your issue found on the amqp.org site to the AMQP Working Group.

regards
Carl.



Tomas Restrepo wrote:
> Hi Carl,
>
>   
>> (3) Openness of participation in the specification.
>>
>> This is a long section in cliff mail and the thread that resulted is
>> even longer.... To best sum up the issue I quote from Cliff's mail
>> again
>> "If an Apache project is based on a specification that is driven by a
>> closed set of authors, including some, but not all committers, how can
>> the technical decisions of the project truly be based on an open
>> meritocracy?"
>>
>> --> the Working Group has seen individuals join the group and provide
>> very good feedback to the specification, so far no-one has requested
>> that we proceed or require/work any of the options suggested by Cliff.
>> If needed I can outline them.
>>
>> It thus seems that the underlying question that was open at time of
>> acceptance into incubator was "Are those contributing to Qpid able to
>> interact with and view/influence information from the AMQP Working
>> Group?" Refreshing my memory, I have searched the Qpid lists and could
>> not find any issues between the Qpid project and the Working Group. 
>>     
>
> I'm not sure what all the fuzz is about, however, fwiw, here's a couple of
> comments:
>
> 1- I check on the protocol mailing lists every now on then, and it can
> certainly be very enlightening and it's very useful to see those discussions
> out in the open; I think it's very valuable for all people involved. Not all
> information seems to be public though, and that can hinder sometimes the
> process (for example, last I checked the jira for the working group was
> private and seeing as how many of the posts on the mailing lists archives
> reference issues there, it's sometimes hard to really understand what's
> being said).
>
> 2- As for interaction with the working group; well, I know several of the
> qpid project members are involved in the working group, and that's a good
> thing. I once tried to get access to provide feedback on the specifications
> (following the process outlined in
> http://www.amqp.org/tikiwiki/tiki-index.php?page=AMQP_User) but didn't have
> much success there; so I'm not quite sure what the process should be. 
>
> Even though I personally have some concerns about portions of the protocol
> specs and the direction it is headed, there's not really a good way to
> provide feedback on that at this point and I've preferred to keep my
> comments on the spec itself off the qpid lists, as I don't want to clutter
> the project's list with other stuff.
>
> So given that, my opinion is that the current mechanism isn't really all
> wide open. It's good that it's transparent, but seems to be pretty much
> read-only from where I stand (not that there's anything intrinsically wrong
> with that).
>
> Also, fwiw, I do think the lack of a clearer schedule from the working group
> on the specification process hinders a bit planning for the qpid project, as
> evidenced a bit by the recent discussions on what to implement and when and
> 0.8 vs. 0.9 vs. 0.10., but that's a different matter altogether.
>
> Just my $0.00000000002 cents worth :)
>
>
> Tomas Restrepo
> http://www.winterdom.com/weblog/
>
>
>
>   

RE: Qpid working with AMQP Working Group

[Tomas Restrepo <to...@devdeo.com>]

Hi Carl,

> (3) Openness of participation in the specification.
> 
> This is a long section in cliff mail and the thread that resulted is
> even longer.... To best sum up the issue I quote from Cliff's mail
> again
> "If an Apache project is based on a specification that is driven by a
> closed set of authors, including some, but not all committers, how can
> the technical decisions of the project truly be based on an open
> meritocracy?"
> 
> --> the Working Group has seen individuals join the group and provide
> very good feedback to the specification, so far no-one has requested
> that we proceed or require/work any of the options suggested by Cliff.
> If needed I can outline them.
> 
> It thus seems that the underlying question that was open at time of
> acceptance into incubator was "Are those contributing to Qpid able to
> interact with and view/influence information from the AMQP Working
> Group?" Refreshing my memory, I have searched the Qpid lists and could
> not find any issues between the Qpid project and the Working Group. 

I'm not sure what all the fuzz is about, however, fwiw, here's a couple of
comments:

1- I check on the protocol mailing lists every now on then, and it can
certainly be very enlightening and it's very useful to see those discussions
out in the open; I think it's very valuable for all people involved. Not all
information seems to be public though, and that can hinder sometimes the
process (for example, last I checked the jira for the working group was
private and seeing as how many of the posts on the mailing lists archives
reference issues there, it's sometimes hard to really understand what's
being said).

2- As for interaction with the working group; well, I know several of the
qpid project members are involved in the working group, and that's a good
thing. I once tried to get access to provide feedback on the specifications
(following the process outlined in
http://www.amqp.org/tikiwiki/tiki-index.php?page=AMQP_User) but didn't have
much success there; so I'm not quite sure what the process should be. 

Even though I personally have some concerns about portions of the protocol
specs and the direction it is headed, there's not really a good way to
provide feedback on that at this point and I've preferred to keep my
comments on the spec itself off the qpid lists, as I don't want to clutter
the project's list with other stuff.

So given that, my opinion is that the current mechanism isn't really all
wide open. It's good that it's transparent, but seems to be pretty much
read-only from where I stand (not that there's anything intrinsically wrong
with that).

Also, fwiw, I do think the lack of a clearer schedule from the working group
on the specification process hinders a bit planning for the qpid project, as
evidenced a bit by the recent discussions on what to implement and when and
0.8 vs. 0.9 vs. 0.10., but that's a different matter altogether.

Just my $0.00000000002 cents worth :)


Tomas Restrepo
http://www.winterdom.com/weblog/