You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jonathan Robie <jo...@redhat.com> on 2009/01/29 17:24:49 UTC
Web site triage
A bunch of us have been working on the web pages - Carl, Gordon, and I
have been among the contributors - with the immediate goal of making it
easier to get a quick overview and get up and running with the distribution.
How are we doing? I think the following pages are particularly
important, and have been improved:
http://qpid.apache.org/
http://qpid.apache.org/download.html
http://qpid.apache.org/getting-started.html
http://qpid.apache.org/documentation.html
http://qpid.apache.org/docs/api/cpp/html/index.html
http://qpid.apache.org/docs/api/python/html/index.html
http://qpid.apache.org/faq.html
These pages need work, and are probably the next priority:
http://qpid.apache.org/building.html
http://qpid.apache.org/developer-pages.html
.NET materials (not yet available)
These pages haven't changed much lately, but they look good to me as is:
http://qpid.apache.org/mailing-lists.html
http://issues.apache.org/jira/browse/qpid
http://qpid.apache.org/source-repository.html
Feedback is welcome!
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Jonathan Robie <jo...@redhat.com>.
Marnie McCormack wrote:
> Reading the FAQ, it needs more Java details and performance figures, which
> I'll add too.
>
Excellent!
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Marnie McCormack <ma...@googlemail.com>.
Reading the FAQ, it needs more Java details and performance figures, which
I'll add too.
Marnie
On Thu, Jan 29, 2009 at 4:51 PM, Marnie McCormack <
marnie.mccormack@googlemail.com> wrote:
> Hi Jonathan,
>
> Thanks for all this ! The C++ docs are looking good (so much more
> comprehensive). Overall the site has come on loads, and it's great to see it
> looking so much more rounded.
>
> I've updated a few of these pages to add details on the Java side, and
> separate some of the details out a little by broker (as per the
> conversations on Users). I have also pulled some of the important Java
> documentation up to the top as it has gotten a little buried in some of the
> re-orgs.
>
> I'd prefer not to be separating components from the same release out by
> AMQP version as I think it sends the wrong signal and is not how we actually
> make releases i.e. we released M4 not AMQP 0-10.
>
> Some of the information is becoming a little low level i.e on the download
> page we have pre-built Linux packlages with instructions but there's no info
> on what these actually are and some are rhm messaging instructions ? I think
> this stuff should probably be shipped onto the C++ pages or headlined more
> clearly.
> Regards,
> Marnie
> On Thu, Jan 29, 2009 at 4:24 PM, Jonathan Robie <
> jonathan.robie@redhat.com> wrote:
>
>> A bunch of us have been working on the web pages - Carl, Gordon, and I
>> have been among the contributors - with the immediate goal of making it
>> easier to get a quick overview and get up and running with the distribution.
>>
>> How are we doing? I think the following pages are particularly important,
>> and have been improved:
>>
>> http://qpid.apache.org/
>> http://qpid.apache.org/download.html
>> http://qpid.apache.org/getting-started.html
>> http://qpid.apache.org/documentation.html
>> http://qpid.apache.org/docs/api/cpp/html/index.html
>> http://qpid.apache.org/docs/api/python/html/index.html
>> http://qpid.apache.org/faq.html
>>
>> These pages need work, and are probably the next priority:
>>
>> http://qpid.apache.org/building.html
>> http://qpid.apache.org/developer-pages.html
>> .NET materials (not yet available)
>>
>> These pages haven't changed much lately, but they look good to me as is:
>>
>> http://qpid.apache.org/mailing-lists.html
>> http://issues.apache.org/jira/browse/qpid
>> http://qpid.apache.org/source-repository.html
>>
>> Feedback is welcome!
>>
>> Jonathan
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
Re: Web site triage
Posted by Jonathan Robie <jo...@redhat.com>.
Marnie McCormack wrote:
> Hi Jonathan,
>
> Thanks for all this ! The C++ docs are looking good (so much more
> comprehensive). Overall the site has come on loads, and it's great to see it
> looking so much more rounded.
>
Thanks!
> I've updated a few of these pages to add details on the Java side, and
> separate some of the details out a little by broker (as per the
> conversations on Users). I have also pulled some of the important Java
> documentation up to the top as it has gotten a little buried in some of the
> re-orgs.
>
Excellent!
> I'd prefer not to be separating components from the same release out by AMQP
> version as I think it sends the wrong signal and is not how we actually make
> releases i.e. we released M4 not AMQP 0-10.
>
Hmmm, I think I disagree. The two servers support different protocols,
various parts of our M4 release are incompatible with each other, and
that's a big surprise for the user if they don't know what to expect. In
an ideal world, everything in one release is compatible with everything
else. That's why I like being very clear about this.
For instance, suppose a user just follows the instruction on the Getting
Started page. They get a broker (pick one of 2), get a client, run the
examples, and it doesn't work. Ooops. If we want to make it easier for
the user to get started, we want to make sure they see this coming and
know how to get compatible pieces.
I'd rather just be able to tell our users that everything in a given
release is compatible with everything else in the same release, but
that's not realistic this time around.
> Some of the information is becoming a little low level i.e on the download
> page we have pre-built Linux packlages with instructions but there's no info
> on what these actually are and some are rhm messaging instructions ? I think
> this stuff should probably be shipped onto the C++ pages or headlined more
> clearly
This section is for the binaries available for free on Fedora. How would
you suggest headlining them more clearly?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Carl Trieloff <cc...@redhat.com>.
Marnie McCormack wrote:
> I think our download page should be just that !
>
> There's a release compatibility matrix which shows which bits currently work
> together - so I don't think the download page is the place to try and convey
> this info. The python client (as the Java client) appears to be the same
> package on both tables.
>
> The current download page needs changed - it could be taken to imply to a
> user that the java client and broker do not interop. Some info about interop
> could be added, to explain that the C++ broker is not backwards compatible.
I can take a hack at trying to improve that, and then everyone can beat
it up again. After a few itterations I
am sure we can get it better.
I'll mail the list once I have done an update, to try resolve the
concerns raised.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Marnie McCormack <ma...@googlemail.com>.
I'll try to explain better, with the caveat that what we do on Apache Qpid
is not terribly well documented for this stuff, so I'd imagine we all have
slightly differing assumptions here ....
On Mon, Feb 2, 2009 at 11:28 PM, Rafael Schloming <ra...@redhat.com>wrote:
> I'm not sure I fully understand what you're saying. My assertion is quite
>> simple. The Mx releases don't promise any sort of interoperability between
>> Mx and Mx+/-1. This makes QA for these releases comparatively easy since we
>> only need to test that we have a self consistent and working snapshot in
>> order to release.
>
>
The Java broker & client are tested with previous releases, I do this for
each release as part of an extensive set of testing - targetted at our
existing user community. So, one person's QA here isn't anothers I guess. I
also used ti test the .Net and the C++ client - but this is not now
possible, sadly. I do still test against builds of these clients I know
users are interop-ing with the Java Broker. (These users currently have no
migration path btw, but that's a whole other topic.)
>
>> As soon as we start introducing the notion of point releases, whether it's
>> something like 1.5, 1.6, or whether it's M4.0.1, there is an implied promise
>> of interoperability that most people will expect given the chosen release
>> numbering convention, and it's something that we don't currently test for at
>> all. In fact as far as I'm aware most qpid developers pretty freely make
>> code changes without worrying about backwards compatibility at all.
>
>
I'm definitely ambivalent on the numbering stuff (swerve) but
interoperability is tested, and does matter to the Java developers I work
most closely with. We should care very much about backwards compatibility,
and I know some of us do :-)
>
>> If what you are suggesting is that we need to start thinking about when
>> and how to provide higher levels of interoperability, then I do agree that
>> this is something that we need to address at some point and will certainly
>> need some careful thought, however I would still assert that this implies
>> more testing and therefore more work, so I'm confused at the idea that
>> introducing this sort of point release would make anything easier.
>
>
Don't have too much of a view on point releases per se, but we (I) do
already do interop testing and release compatibility testing on each & every
release. It takes time, but our users need it.
>
>> On the other hand if you're suggesting there is a specific piece of work
>> you'd like to fast-track to a released state (e.g. 0-10 support in the Java
>> broker), then I'd say we should discuss that concretely and figure out the
>> best way to handle it. For that case specifically I could certainly see
>> doing a component level release assuming we were clear up front about
>> exactly what interop testing we were/weren't doing, and we named the release
>> accordingly.
>
>
Yes, this is really the case I care about (see the Eclipse Management
Console release thread from 08). But I can also see that there is a real
case for smaller, simpler releases on a component schedule basis. I don't
think this should be a major problem.
Seems to me we need to make some statements about what we (as a team) do for
testing etc even if we're not doing it on Apache infra ? Maybe that'd help
us to have a common perspective. I'll pull some info together.
Regards,
Marnie
>
>
Re: Web site triage
Posted by Rafael Schloming <ra...@redhat.com>.
Marnie McCormack wrote:
> I'd put the opposite view forward - we are currently unable to avoid doing
> releases with non-interop-ing components and are also duty bound to test
> against old broker/client releases (we do this for each release).
>
> Thus I think component releases should not present a problem - we could, of
> course, introduce a quality gateway that the release manager would own i.e.
> version blah of this component has been tested against versions 1,2,3 of
> other components A,B,C.
>
> For example, if the 0-10 work on the Java broker got committed tomorrow we'd
> be mad not to release it asap.
>
> It's probably unreasonable to force all the components, with widely
> differing roadmpas, to conform to one release schedule.
>
> It'd surely (please god) be simpler to get our releases out with a single or
> smaller set of component parts.
I'm not sure I fully understand what you're saying. My assertion is
quite simple. The Mx releases don't promise any sort of interoperability
between Mx and Mx+/-1. This makes QA for these releases comparatively
easy since we only need to test that we have a self consistent and
working snapshot in order to release.
As soon as we start introducing the notion of point releases, whether
it's something like 1.5, 1.6, or whether it's M4.0.1, there is an
implied promise of interoperability that most people will expect given
the chosen release numbering convention, and it's something that we
don't currently test for at all. In fact as far as I'm aware most qpid
developers pretty freely make code changes without worrying about
backwards compatibility at all.
If what you are suggesting is that we need to start thinking about when
and how to provide higher levels of interoperability, then I do agree
that this is something that we need to address at some point and will
certainly need some careful thought, however I would still assert that
this implies more testing and therefore more work, so I'm confused at
the idea that introducing this sort of point release would make anything
easier.
On the other hand if you're suggesting there is a specific piece of work
you'd like to fast-track to a released state (e.g. 0-10 support in the
Java broker), then I'd say we should discuss that concretely and figure
out the best way to handle it. For that case specifically I could
certainly see doing a component level release assuming we were clear up
front about exactly what interop testing we were/weren't doing, and we
named the release accordingly.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Marnie McCormack <ma...@googlemail.com>.
I'd put the opposite view forward - we are currently unable to avoid doing
releases with non-interop-ing components and are also duty bound to test
against old broker/client releases (we do this for each release).
Thus I think component releases should not present a problem - we could, of
course, introduce a quality gateway that the release manager would own i.e.
version blah of this component has been tested against versions 1,2,3 of
other components A,B,C.
For example, if the 0-10 work on the Java broker got committed tomorrow we'd
be mad not to release it asap.
It's probably unreasonable to force all the components, with widely
differing roadmpas, to conform to one release schedule.
It'd surely (please god) be simpler to get our releases out with a single or
smaller set of component parts.
Bfn,
Marnie
On Fri, Jan 30, 2009 at 1:12 PM, Rafael Schloming <ra...@redhat.com>wrote:
> Martin Ritchie wrote:
>
>> I thought we agreed at the end of last year that we were going to move
>> to release by components rather than language. e.g.
>> Brokers
>> qpid-c++-broker
>> qpid-java-broker
>>
>> Clients
>> qpid-c++-client
>> qpid-dotnet-client
>> qpid-java-client
>> qpid-ruby-client
>> qpid-python-client
>>
>> Management
>> qpid-management-cli
>> qpid-management-eclipse
>> qpid-management-qman
>> ...
>>
>> That way if a user only wants to have the C++ broker and Java client
>> they only need download those components. It also makes it way easier
>> to say. Hey new version of component X now available.That said, We
>> should still have a full release of version X.0.0 with all components
>> but then allow each component to do point releases as is needed for
>> bug fixes, small enhancements, but fully compatible.
>>
>
> I'm fine with doing *packages* by component, but assuming I'm remembering
> the correct thread, I don't think we agreed to doing *releases* by
> component. There are significant problems with doing point releases of a
> component. In particular, any change to a broker would require retesting
> against each minor version of all the clients, and similarly a change to one
> of the clients would require retesting interop against each minor version of
> all the other clients. This very quickly leads to combinatorial explosions
> of testing, and would be more work than simply doing a full release where we
> don't need to (or at least we don't usually) worry about breaking
> compatibility with deployed clients from older releases.
>
>
> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Web site triage
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> I thought we agreed at the end of last year that we were going to move
> to release by components rather than language. e.g.
> Brokers
> qpid-c++-broker
> qpid-java-broker
>
> Clients
> qpid-c++-client
> qpid-dotnet-client
> qpid-java-client
> qpid-ruby-client
> qpid-python-client
>
> Management
> qpid-management-cli
> qpid-management-eclipse
> qpid-management-qman
> ...
>
> That way if a user only wants to have the C++ broker and Java client
> they only need download those components. It also makes it way easier
> to say. Hey new version of component X now available.That said, We
> should still have a full release of version X.0.0 with all components
> but then allow each component to do point releases as is needed for
> bug fixes, small enhancements, but fully compatible.
I'm fine with doing *packages* by component, but assuming I'm
remembering the correct thread, I don't think we agreed to doing
*releases* by component. There are significant problems with doing point
releases of a component. In particular, any change to a broker would
require retesting against each minor version of all the clients, and
similarly a change to one of the clients would require retesting interop
against each minor version of all the other clients. This very quickly
leads to combinatorial explosions of testing, and would be more work
than simply doing a full release where we don't need to (or at least we
don't usually) worry about breaking compatibility with deployed clients
from older releases.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Martin Ritchie <ri...@apache.org>.
2009/1/30 Rafael Schloming <ra...@redhat.com>:
> Martin Ritchie wrote:
>>
>> 2009/1/30 Marnie McCormack <ma...@googlemail.com>:
>>>
>>> I think our download page should be just that !
>>>
>>> There's a release compatibility matrix which shows which bits currently
>>> work
>>> together - so I don't think the download page is the place to try and
>>> convey
>>> this info. The python client (as the Java client) appears to be the same
>>> package on both tables.
>>>
>>> The current download page needs changed - it could be taken to imply to a
>>> user that the java client and broker do not interop. Some info about
>>> interop
>>> could be added, to explain that the C++ broker is not backwards
>>> compatible.
>>>
>>> Marnie
>>>
>>> Some of this discussion is really about interop and backwards
>>> compatibility.
>>> D
>>> On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie
>>> <jo...@redhat.com>wrote:
>>>
>>>> Carl Trieloff wrote:
>>>>
>>>>>
>>>>>> I'd prefer not to be separating components from the same release out
>>>>>> by
>>>>>> AMQP
>>>>>> version as I think it sends the wrong signal and is not how we
>>>>>> actually
>>>>>> make
>>>>>> releases i.e. we released M4 not AMQP 0-10.
>>>>>>
>>>>>>
>>>>> that was me, to try make it really easy to know what works with what,
>>>>> based on some questions on
>>>>> the user list. Is it not clear that it is not all part of M4? ideas to
>>>>> make it better...
>>>>>
>>>> I liked the way we had it, but I'm happy with any approach that makes it
>>>> very clear which pieces are compatible.
>>>>
>>>> I really don't want people to download incompatible bits, shrug, and
>>>> move
>>>> on to some other implementation.
>>>>
>>>> Jonathan
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>
>> But are the C++ client and the Ruby client not the only two that don't
>> work with the Java Broker?
>>
>> Java, Python and .Net all work with 0-8/9 and 0-10?
>>
>> As there are more clients that are compatible than are not I'd say we
>> should put a caveat on the two incompatible clients, if the
>> compatibility matrix is not enough.
>>
>> Splitting the download page by AMQP version suggests that the Java
>> broker is not as functional because it doesn't support the latest
>> protocol version when in reality only two clients don't work. If we
>> hadn't deleted the 0-9 C++ client then we would still have a C++
>> client for the Java Broker and so compatibility issues wouldn't need
>> to be mentioned. Was the old Ruby client that supported 0-8/9
>> discarded when the 0-10 work was done, I'd say we should bring it back
>> in a similar way to the .net unless we plan on putting multi-protocol
>> support in to the current Ruby client. Was that not the only AMQP
>> 0-8/9 Ruby client?
>
> Actually the 0-8/9 ruby client is still there and should still work. I think
> the bigger issue is that other than JMS, the client APIs are different for
> 0-8/9 and 0-10, so it's still possible to get confused and think that there
> is no interop even though there is.
>
> As an aside, speaking of JMS, we should probably put JMS somewhere near the
> Java client entries on that page in order to make it clear that our Java
> client is actually a JMS impl.
>
>> It is a matter of presentation to users, the fact that the 0-10 has
>> twice as many items as the 0-8/9 suggests that it is in some way
>> better, when the 0-8/9 items are duplicates from the 0-10 section.
>> When we get to M5 and release individual packages for all components
>> (not just .Net) then I think things will be easier but for that to
>> occur I think the download page should be grouped Brokers and Clients.
>> I think this will work just now and be clearer to the end user.
>
> What do you mean by release individual packages for all components?
I thought we agreed at the end of last year that we were going to move
to release by components rather than language. e.g.
Brokers
qpid-c++-broker
qpid-java-broker
Clients
qpid-c++-client
qpid-dotnet-client
qpid-java-client
qpid-ruby-client
qpid-python-client
Management
qpid-management-cli
qpid-management-eclipse
qpid-management-qman
...
That way if a user only wants to have the C++ broker and Java client
they only need download those components. It also makes it way easier
to say. Hey new version of component X now available.That said, We
should still have a full release of version X.0.0 with all components
but then allow each component to do point releases as is needed for
bug fixes, small enhancements, but fully compatible.
Martin
> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> 2009/1/30 Marnie McCormack <ma...@googlemail.com>:
>> I think our download page should be just that !
>>
>> There's a release compatibility matrix which shows which bits currently work
>> together - so I don't think the download page is the place to try and convey
>> this info. The python client (as the Java client) appears to be the same
>> package on both tables.
>>
>> The current download page needs changed - it could be taken to imply to a
>> user that the java client and broker do not interop. Some info about interop
>> could be added, to explain that the C++ broker is not backwards compatible.
>>
>> Marnie
>>
>> Some of this discussion is really about interop and backwards compatibility.
>> D
>> On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie
>> <jo...@redhat.com>wrote:
>>
>>> Carl Trieloff wrote:
>>>
>>>>
>>>>> I'd prefer not to be separating components from the same release out by
>>>>> AMQP
>>>>> version as I think it sends the wrong signal and is not how we actually
>>>>> make
>>>>> releases i.e. we released M4 not AMQP 0-10.
>>>>>
>>>>>
>>>> that was me, to try make it really easy to know what works with what,
>>>> based on some questions on
>>>> the user list. Is it not clear that it is not all part of M4? ideas to
>>>> make it better...
>>>>
>>> I liked the way we had it, but I'm happy with any approach that makes it
>>> very clear which pieces are compatible.
>>>
>>> I really don't want people to download incompatible bits, shrug, and move
>>> on to some other implementation.
>>>
>>> Jonathan
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>
> But are the C++ client and the Ruby client not the only two that don't
> work with the Java Broker?
>
> Java, Python and .Net all work with 0-8/9 and 0-10?
>
> As there are more clients that are compatible than are not I'd say we
> should put a caveat on the two incompatible clients, if the
> compatibility matrix is not enough.
>
> Splitting the download page by AMQP version suggests that the Java
> broker is not as functional because it doesn't support the latest
> protocol version when in reality only two clients don't work. If we
> hadn't deleted the 0-9 C++ client then we would still have a C++
> client for the Java Broker and so compatibility issues wouldn't need
> to be mentioned. Was the old Ruby client that supported 0-8/9
> discarded when the 0-10 work was done, I'd say we should bring it back
> in a similar way to the .net unless we plan on putting multi-protocol
> support in to the current Ruby client. Was that not the only AMQP
> 0-8/9 Ruby client?
Actually the 0-8/9 ruby client is still there and should still work. I
think the bigger issue is that other than JMS, the client APIs are
different for 0-8/9 and 0-10, so it's still possible to get confused and
think that there is no interop even though there is.
As an aside, speaking of JMS, we should probably put JMS somewhere near
the Java client entries on that page in order to make it clear that our
Java client is actually a JMS impl.
> It is a matter of presentation to users, the fact that the 0-10 has
> twice as many items as the 0-8/9 suggests that it is in some way
> better, when the 0-8/9 items are duplicates from the 0-10 section.
> When we get to M5 and release individual packages for all components
> (not just .Net) then I think things will be easier but for that to
> occur I think the download page should be grouped Brokers and Clients.
> I think this will work just now and be clearer to the end user.
What do you mean by release individual packages for all components?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Martin Ritchie <ri...@apache.org>.
2009/1/30 Marnie McCormack <ma...@googlemail.com>:
> I think our download page should be just that !
>
> There's a release compatibility matrix which shows which bits currently work
> together - so I don't think the download page is the place to try and convey
> this info. The python client (as the Java client) appears to be the same
> package on both tables.
>
> The current download page needs changed - it could be taken to imply to a
> user that the java client and broker do not interop. Some info about interop
> could be added, to explain that the C++ broker is not backwards compatible.
>
> Marnie
>
> Some of this discussion is really about interop and backwards compatibility.
> D
> On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie
> <jo...@redhat.com>wrote:
>
>> Carl Trieloff wrote:
>>
>>>
>>>
>>>> I'd prefer not to be separating components from the same release out by
>>>> AMQP
>>>> version as I think it sends the wrong signal and is not how we actually
>>>> make
>>>> releases i.e. we released M4 not AMQP 0-10.
>>>>
>>>>
>>>
>>> that was me, to try make it really easy to know what works with what,
>>> based on some questions on
>>> the user list. Is it not clear that it is not all part of M4? ideas to
>>> make it better...
>>>
>>
>> I liked the way we had it, but I'm happy with any approach that makes it
>> very clear which pieces are compatible.
>>
>> I really don't want people to download incompatible bits, shrug, and move
>> on to some other implementation.
>>
>> Jonathan
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
But are the C++ client and the Ruby client not the only two that don't
work with the Java Broker?
Java, Python and .Net all work with 0-8/9 and 0-10?
As there are more clients that are compatible than are not I'd say we
should put a caveat on the two incompatible clients, if the
compatibility matrix is not enough.
Splitting the download page by AMQP version suggests that the Java
broker is not as functional because it doesn't support the latest
protocol version when in reality only two clients don't work. If we
hadn't deleted the 0-9 C++ client then we would still have a C++
client for the Java Broker and so compatibility issues wouldn't need
to be mentioned. Was the old Ruby client that supported 0-8/9
discarded when the 0-10 work was done, I'd say we should bring it back
in a similar way to the .net unless we plan on putting multi-protocol
support in to the current Ruby client. Was that not the only AMQP
0-8/9 Ruby client?
It is a matter of presentation to users, the fact that the 0-10 has
twice as many items as the 0-8/9 suggests that it is in some way
better, when the 0-8/9 items are duplicates from the 0-10 section.
When we get to M5 and release individual packages for all components
(not just .Net) then I think things will be easier but for that to
occur I think the download page should be grouped Brokers and Clients.
I think this will work just now and be clearer to the end user.
Just my two cents on a Friday morning.
Martin
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Marnie McCormack <ma...@googlemail.com>.
I think our download page should be just that !
There's a release compatibility matrix which shows which bits currently work
together - so I don't think the download page is the place to try and convey
this info. The python client (as the Java client) appears to be the same
package on both tables.
The current download page needs changed - it could be taken to imply to a
user that the java client and broker do not interop. Some info about interop
could be added, to explain that the C++ broker is not backwards compatible.
Marnie
Some of this discussion is really about interop and backwards compatibility.
D
On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie
<jo...@redhat.com>wrote:
> Carl Trieloff wrote:
>
>>
>>
>>> I'd prefer not to be separating components from the same release out by
>>> AMQP
>>> version as I think it sends the wrong signal and is not how we actually
>>> make
>>> releases i.e. we released M4 not AMQP 0-10.
>>>
>>>
>>
>> that was me, to try make it really easy to know what works with what,
>> based on some questions on
>> the user list. Is it not clear that it is not all part of M4? ideas to
>> make it better...
>>
>
> I liked the way we had it, but I'm happy with any approach that makes it
> very clear which pieces are compatible.
>
> I really don't want people to download incompatible bits, shrug, and move
> on to some other implementation.
>
> Jonathan
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Web site triage
Posted by Jonathan Robie <jo...@redhat.com>.
Carl Trieloff wrote:
>
>>
>> I'd prefer not to be separating components from the same release out
>> by AMQP
>> version as I think it sends the wrong signal and is not how we
>> actually make
>> releases i.e. we released M4 not AMQP 0-10.
>>
>
> that was me, to try make it really easy to know what works with what,
> based on some questions on
> the user list. Is it not clear that it is not all part of M4? ideas to
> make it better...
I liked the way we had it, but I'm happy with any approach that makes it
very clear which pieces are compatible.
I really don't want people to download incompatible bits, shrug, and
move on to some other implementation.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Carl Trieloff <cc...@redhat.com>.
>
> I'd prefer not to be separating components from the same release out by AMQP
> version as I think it sends the wrong signal and is not how we actually make
> releases i.e. we released M4 not AMQP 0-10.
>
that was me, to try make it really easy to know what works with what,
based on some questions on
the user list. Is it not clear that it is not all part of M4? ideas to
make it better...
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Web site triage
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Jonathan,
Thanks for all this ! The C++ docs are looking good (so much more
comprehensive). Overall the site has come on loads, and it's great to see it
looking so much more rounded.
I've updated a few of these pages to add details on the Java side, and
separate some of the details out a little by broker (as per the
conversations on Users). I have also pulled some of the important Java
documentation up to the top as it has gotten a little buried in some of the
re-orgs.
I'd prefer not to be separating components from the same release out by AMQP
version as I think it sends the wrong signal and is not how we actually make
releases i.e. we released M4 not AMQP 0-10.
Some of the information is becoming a little low level i.e on the download
page we have pre-built Linux packlages with instructions but there's no info
on what these actually are and some are rhm messaging instructions ? I think
this stuff should probably be shipped onto the C++ pages or headlined more
clearly.
Regards,
Marnie
On Thu, Jan 29, 2009 at 4:24 PM, Jonathan Robie
<jo...@redhat.com>wrote:
> A bunch of us have been working on the web pages - Carl, Gordon, and I have
> been among the contributors - with the immediate goal of making it easier to
> get a quick overview and get up and running with the distribution.
>
> How are we doing? I think the following pages are particularly important,
> and have been improved:
>
> http://qpid.apache.org/
> http://qpid.apache.org/download.html
> http://qpid.apache.org/getting-started.html
> http://qpid.apache.org/documentation.html
> http://qpid.apache.org/docs/api/cpp/html/index.html
> http://qpid.apache.org/docs/api/python/html/index.html
> http://qpid.apache.org/faq.html
>
> These pages need work, and are probably the next priority:
>
> http://qpid.apache.org/building.html
> http://qpid.apache.org/developer-pages.html
> .NET materials (not yet available)
>
> These pages haven't changed much lately, but they look good to me as is:
>
> http://qpid.apache.org/mailing-lists.html
> http://issues.apache.org/jira/browse/qpid
> http://qpid.apache.org/source-repository.html
>
> Feedback is welcome!
>
> Jonathan
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>