Re: Web site triage
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 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
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-subscr...@qpid.apache.org
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
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 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-subscr...@qpid.apache.org > >
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
2009/1/30 Rafael Schloming : > Martin Ritchie wrote: >> >> 2009/1/30 Marnie McCormack : >>> >>> 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 >>> 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-subscr...@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-subscr...@qpid.apache.org > > -- Martin Ritchie - Apache Qpid - AMQP Messag
Re: Web site triage
Martin Ritchie wrote: 2009/1/30 Marnie McCormack : 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 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-subscr...@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-subscr...@qpid.apache.org
Re: Web site triage
2009/1/30 Marnie McCormack : > 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 > 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-subscr...@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-subscr...@qpid.apache.org
Re: Web site triage
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 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-subscr...@qpid.apache.org > >
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
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-subscr...@qpid.apache.org
Re: Web site triage
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 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-subscr...@qpid.apache.org > >
Re: Web site triage
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.mccorm...@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.ro...@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-subscr...@qpid.apache.org >> >> >
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-subscr...@qpid.apache.org
