On Thu, Jun 10, 2010 at 4:39 PM, Marnie McCormack
<marnie.mccorm...@googlemail.com> wrote:
> Hi Rajith,
>
> On the wiki - it has been suggested on this thread that the wiki be retired
> and/or updates not reflected on the new website.

The old documentation will not be deleted.
There will be a link from the website to the wiki.

> Most of the java devs are very busy working on the 0-10 broker
> implementation which is a major effort. Does anyone out there have the
> bandwidth to convert/rewrite the Java content on the wiki ?

I think Jonathan has already converted the existing docs in the wiki
into the doc book format.
However if you are adding anything new, please add it to the svn docs.
It's unfair to expect him to continue to sync the svn docs with any
new additions to the wiki.
We as a community took this decision and it requires support from
everybody to ensure we provide good documentation for end users.

> My team have the knowledge, but not the time just now.

> For the .Net, is there a reason why you want to delete the 0-8 code,
> given we still have users ?

But there is nobody apart Aidan who has made any effort to answer any
user queries related to these clients on the user list.
I don't understand why we need to keep the old 0-8, 0-10 .NET clients
on trunk when there is no active development or anybody willing to
champion it ?

I really don't think anybody is interested in maintaining this code.
Many have pointed that they will not be comfortable with releasing
these clients again as they are buggy and unsupported.

> When we have something better I'd think that's
> the right thing, but imho better to keep the code we have out there on trunk
> until we can gracefully retire it.

We already have a better solution in WCF and a .NET binding, all
though they are targeted at 0-10.
With 1.0 coming out I don't think any new users will really care about 0-8.
And we as a community needs to ensure we steer them clear off these
unmaintained and unsupported clients.

> I didn't think it was causing any issues
> where it is ?

There is a serious issue.
Every we do a release we are effectively releasing (via the source
release) unmaintained buggy code that no one is willing to support !
That is an automatic -1 from me come the next release cycle.

Also every time anybody does a checkout we are effectively downloading
dead code.
We shouldn't be keeping unmaintained code in trunk. There has been
several discussions on the list about this already.

Several users have downloaded the old clients from the website and
have run into issues and there is nobody to answer their questions.
That is why I suggested to remove those clients from our download page.

> Regards,
> Marnie
>
> On Thu, Jun 10, 2010 at 5:46 PM, Rajith Attapattu <rajit...@gmail.com>wrote:
>
>> On Thu, Jun 10, 2010 at 11:58 AM, Marnie McCormack
>> <marnie.mccorm...@googlemail.com> wrote:
>> > All,
>> >
>> > Sorry to chip in a little late - I've been on vacation.
>> >
>> > So, the wiki should definitely stay ! A lot of the Java docs are linked
>> from
>> > end user stuff I use and I'd be very unhappy to see those docs disappear
>> > (and you really won't like me when I'm angry) including the java FAQs
>> drawn
>> > from support questions etc. I promote all docs I write to Apache and link
>> > from there so the wiki links are in use.
>>
>> Nobody is going to remove anything in the wiki !
>> However any new documentation should be in the svn docs directory.
>> As agreed by the community the docs will be maintained in svn and will
>> be released along with the code.
>> At some point we need to convert the FAQ's into the docbook format as
>> well, since the content could change according to the release.
>> I believe it will ensure the FAQ is current at least for each release.
>>
>> > On the .Net, I have no interest in the 0-10 version but the 0-8 version
>> > should stay (docs, code the lot) as it matters and is in production use,
>> at
>> > least until we have a 0-10 Java broker and an alternative .Net client to
>> > interop with it.
>>
>> In ASF code is never deleted.
>> However I strongly feel we should remove links to the old 0-8 and 0-10
>> .NET clients from the download page.
>> Also we should remove the old .NET client code from the *trunk* as it
>> is dead code that is not going to be maintained.
>> If anybody needs them, we have release tags that corresponds to each
>> release.
>> We could also tag the current trunk version before we remove it from the
>> tree.
>>
>> > Bye for now,
>> > Marnie
>> >
>> > On Wed, Jun 9, 2010 at 5:32 PM, Rajith Attapattu <rajit...@gmail.com>
>> wrote:
>> >
>> >> I would also remove the links to the old .NET clients from the download
>> >> page.
>> >> These clients are buggy and unsupported.
>> >> It's best we not provide anything at all, rather then providing
>> >> something that is known to be buggy and unsupported.
>> >>
>> >> This is not to disrespect the individuals who have put a lot of effort
>> >> into these clients, but rather being pragmatic about what we are able
>> >> to do as a community.
>> >> With the WCF client and the new .NET binding (over c++) it is unlikely
>> >> that the old clients will receive any TLC.
>> >> So lets get rid of them from the download pages and the code tree (You
>> >> could always get it from the svn history if needed).
>> >>
>> >> Rajith
>> >>
>> >> On Tue, Jun 8, 2010 at 10:41 AM, Jonathan Robie
>> >> <jonathan.ro...@redhat.com> wrote:
>> >>  > On Tue, 2010-06-08 at 14:27 +0100, Robbie Gemmell wrote:
>> >> >> On the same page, the link to the wiki should point to
>> >> >> http://cwiki.apache.org/confluence/display/qpid
>> >> >>
>> >> >> Overall looks good, I echo Gordon's thoughts, lets get this live ASAP
>> >> >> and improve as we go rather than spending too much time polishing it
>> >> >> beforehand: anythings better than what we have now and everything is
>> >> >> still reachable as long as we link to the wiki.
>> >> >>
>> >> >> One minor nit, the bullet pointed feature box things on the front
>> page
>> >> >> dont display in the right place in IE6 and IE7 (or 8 in compatibility
>> >> >> mode), the entire containing div drops down the page to where the
>> menu
>> >> >> stops. I imagine its just a margin/padding+float CSS bug, ill try to
>> >> >> take a look tonight if I get a chance, they are still around 1/3rd of
>> >> >> all used browsers afterall..now, back to Firefox ;)
>> >> >
>> >> > Nice catch - and there's a CSS validation error for feature_box in
>> >> > the .css stylesheet. I fixed that, I'm asking #asfinfra to refresh
>> (it's
>> >> > not yet set up for me to do that automagically).
>> >> >
>> >> > We'll see if that fixes the problem ...
>> >> >
>> >> > Jonathan
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > Apache Qpid - AMQP Messaging Implementation
>> >> > Project:      http://qpid.apache.org
>> >> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >>
>> >> Rajith Attapattu
>> >> Red Hat
>> >> http://rajith.2rlabs.com/
>> >>
>> >> ---------------------------------------------------------------------
>> >>  Apache Qpid - AMQP Messaging Implementation
>> >> Project:      http://qpid.apache.org
>> >> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>>  Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

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

Reply via email to