You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2003/01/30 22:11:13 UTC
[VOTE] Release plan
While we are making changes, why not vote on the release plan?
Please vote on the following release plans as follows:
+1 = In favor
0 = Don't care
-1 = Against it
Feel free to comment on why you voted as you did.
****************************************************
Plan 1:
Go forward with a 1.2 release as follows:
- Beta release with bugfixes on February 15.
- Testing happens from here on out; we elicit help on this via an
announcement through the new ws.apache.org site.
- No date for stable release as we don't know how many bugs we will
hear about.
- We will need to decide on milestones for beta and final.
****************************************************
Plan 2:
Go forward with a 1.2 release as follows:
- No concrete dates yet.
- Same as above otherwise
****************************************************
Plan 3:
Scrap the 1.2 release and go full steam for 2.0
- Should spend some time organizing milestones for the 2.0 release instead.
I offer to take the lead on whichever we pick, but will need input and
help from you all as well. Also I will defer to more senior developers
if any of you wants to take the lead on the release plan.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [VOTE] Release plan
Posted by John Wilson <tu...@wilson.co.uk>.
+1 Plan 1
It's been too long since the last release. Users are being directed to the
CVS version too often (and too often the don't have the knowledge to make
use of the CVS version).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
----- Original Message -----
From: "Ryan Hoegg" <rh...@isisnetworks.net>
To: <rp...@xml.apache.org>
Sent: Thursday, January 30, 2003 9:11 PM
Subject: [VOTE] Release plan
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
>
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
>
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
instead.
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
>
>
Re: [VOTE] Release plan
Posted by Martin Poeschl <mp...@marmot.at>.
Ryan Hoegg wrote:
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1
the 1.2 codebase is very stable and i use it in production .. a release
would be good
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-0 i don't have time to do the 1.2 release, so i can't vote -1 here
1.2 should be released as soon as possible
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
> instead.
-1
see plan 1 ;-)
martin
>
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well.
+1
> Also I will defer to more senior developers if any of you wants to
> take the lead on the release plan.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
Re: [VOTE] Release plan
Posted by Andrew Evers <an...@redwood.com>.
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1. I'm in favour of getting something out of the door. We're committed
to using something after 1.2 now anyway. I figure the sooner 1.2 is out,
the sooner the next release comes ;)
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-1. Reason as for Plan 1.
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
instead.
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
0. I'm not entirely against this idea, I would like to see what other
peoples
ideas for 2.0 are. Mine mainly revolve around embedding XML-RPC into
other applications at various levels, transports and packaging.
Andrew.
Re: [VOTE] Release plan
Posted by Martin Poeschl <mp...@marmot.at>.
Ryan Hoegg wrote:
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1
the 1.2 codebase is very stable and i use it in production .. a release
would be good
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-0 i don't have time to do the 1.2 release, so i can't vote -1 here
1.2 should be released as soon as possible
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
> instead.
-1
see plan 1 ;-)
martin
>
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well.
+1
> Also I will defer to more senior developers if any of you wants to
> take the lead on the release plan.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
Re: [VOTE] Release plan
Posted by Andrew Evers <an...@redwood.com>.
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1. I'm in favour of getting something out of the door. We're committed
to using something after 1.2 now anyway. I figure the sooner 1.2 is out,
the sooner the next release comes ;)
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-1. Reason as for Plan 1.
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
instead.
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
0. I'm not entirely against this idea, I would like to see what other
peoples
ideas for 2.0 are. Mine mainly revolve around embedding XML-RPC into
other applications at various levels, transports and packaging.
Andrew.
Re: [VOTE] Release plan
Posted by John Wilson <tu...@wilson.co.uk>.
+1 Plan 1
It's been too long since the last release. Users are being directed to the
CVS version too often (and too often the don't have the knowledge to make
use of the CVS version).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
----- Original Message -----
From: "Ryan Hoegg" <rh...@isisnetworks.net>
To: <rp...@xml.apache.org>
Sent: Thursday, January 30, 2003 9:11 PM
Subject: [VOTE] Release plan
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
>
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
>
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release
instead.
>
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
>
>
Re: [VOTE] Release plan
Posted by Martin Redington <m....@ucl.ac.uk>.
On Thursday, January 30, 2003, at 09:47 PM, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
>> p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>>
>
> Not yet. I think the issue is basically closed except for some
> uncertainty on performance with large inputs.
There's a new comment added to that bug, to the effect that
Base64.decode is broken. I may have a fix for that, and a considerable
encode speedup coming later today --- I'll post them to buzilla. I also
think that a trailing newline should be added to encoded data (the perl
Base64 module does this). I'll include this in the patch as well.
> I was going to get around to making a test for that this weekend. I
> found a tasty Project Gutenberg text for it :)
My tests with large inputs showed consistently better performance for
the patched code (by up to 50%), which should be pretty robust --- it
might not be worth cluttering up the tests with another test.
I've got some code I can send you (that reads the large text from a
file), that I used for my speed tests, in case you still want to add it.
> Also, I think our changes should go upstream to Codec, and we should
> change the package name on Base64.java to org.apache.commons.codec.
> You're a committer on Codec, so you could make it happen.
*yes*, the Base64 code definitely wants to be consolidated.
Re: [VOTE] Release plan
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Is it the 1.2 branch which needs the base-64 fixes backported into it? I'm
>all for improving the performance, but I wouldn't hold up a release on
>account of it.
>
Agreed, we need to put what we have into the 1.2 branch (once the voting
is officially over).
>I will port the fixes to Codec. However, the XML-RPC JAR should not contain
>any classes in the org.apache.commons.codec package -- experience has shown
>me that this can lead to horribly difficult to debug class loading problem,
>and often result in LinkageErrors when one application includes multiple
>versions of the same class in its classpath. I have already experienced
>enough of this horror with XML-RPC's inclusion of the SAX API. The only way
>I've successfully debugged this problem is by dumping a list of all the
>classes in my app, looking for duplicates, and comparing their bytecode
>sizes. Software like Tomcat which uses multiple class loaders increases the
>difficulty of this sort of debugging exponentially.
>
>- Dan
>
Point taken. Do you suggest introducing another explicit dependency at
runtime? Or do we keep a copy of Base64.java in our o.a.x.util package
(amounting to an implicit dependency). The problem with keeping a copy
is that it easily gets out of sync.
Anyone know what Turbine does about their dependency on xmlrpc? I know
Slide keeps an out-of-sync copy of the Jakarta HttpClient in their
codebase, and I think they are looking at changing that.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [VOTE] Release plan
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Is it the 1.2 branch which needs the base-64 fixes backported into it? I'm
>all for improving the performance, but I wouldn't hold up a release on
>account of it.
>
Agreed, we need to put what we have into the 1.2 branch (once the voting
is officially over).
>I will port the fixes to Codec. However, the XML-RPC JAR should not contain
>any classes in the org.apache.commons.codec package -- experience has shown
>me that this can lead to horribly difficult to debug class loading problem,
>and often result in LinkageErrors when one application includes multiple
>versions of the same class in its classpath. I have already experienced
>enough of this horror with XML-RPC's inclusion of the SAX API. The only way
>I've successfully debugged this problem is by dumping a list of all the
>classes in my app, looking for duplicates, and comparing their bytecode
>sizes. Software like Tomcat which uses multiple class loaders increases the
>difficulty of this sort of debugging exponentially.
>
>- Dan
>
Point taken. Do you suggest introducing another explicit dependency at
runtime? Or do we keep a copy of Base64.java in our o.a.x.util package
(amounting to an implicit dependency). The problem with keeping a copy
is that it easily gets out of sync.
Anyone know what Turbine does about their dependency on xmlrpc? I know
Slide keeps an out-of-sync copy of the Jakarta HttpClient in their
codebase, and I think they are looking at changing that.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [VOTE] Release plan
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 30 Jan 2003, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
> >p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>
> Not yet. I think the issue is basically closed except for some
> uncertainty on performance with large inputs. I was going to get around
> to making a test for that this weekend. I found a tasty Project
> Gutenberg text for it :)
Is it the 1.2 branch which needs the base-64 fixes backported into it? I'm
all for improving the performance, but I wouldn't hold up a release on
account of it.
> Also, I think our changes should go upstream to Codec, and we should
> change the package name on Base64.java to org.apache.commons.codec.
> You're a committer on Codec, so you could make it happen.
I will port the fixes to Codec. However, the XML-RPC JAR should not contain
any classes in the org.apache.commons.codec package -- experience has shown
me that this can lead to horribly difficult to debug class loading problem,
and often result in LinkageErrors when one application includes multiple
versions of the same class in its classpath. I have already experienced
enough of this horror with XML-RPC's inclusion of the SAX API. The only way
I've successfully debugged this problem is by dumping a list of all the
classes in my app, looking for duplicates, and comparing their bytecode
sizes. Software like Tomcat which uses multiple class loaders increases the
difficulty of this sort of debugging exponentially.
- Dan
Re: [VOTE] Release plan
Posted by Martin Redington <m....@ucl.ac.uk>.
On Thursday, January 30, 2003, at 09:47 PM, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
>> p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>>
>
> Not yet. I think the issue is basically closed except for some
> uncertainty on performance with large inputs.
There's a new comment added to that bug, to the effect that
Base64.decode is broken. I may have a fix for that, and a considerable
encode speedup coming later today --- I'll post them to buzilla. I also
think that a trailing newline should be added to encoded data (the perl
Base64 module does this). I'll include this in the patch as well.
> I was going to get around to making a test for that this weekend. I
> found a tasty Project Gutenberg text for it :)
My tests with large inputs showed consistently better performance for
the patched code (by up to 50%), which should be pretty robust --- it
might not be worth cluttering up the tests with another test.
I've got some code I can send you (that reads the large text from a
file), that I used for my speed tests, in case you still want to add it.
> Also, I think our changes should go upstream to Codec, and we should
> change the package name on Base64.java to org.apache.commons.codec.
> You're a committer on Codec, so you could make it happen.
*yes*, the Base64 code definitely wants to be consolidated.
Re: [VOTE] Release plan
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 30 Jan 2003, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
> >p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>
> Not yet. I think the issue is basically closed except for some
> uncertainty on performance with large inputs. I was going to get around
> to making a test for that this weekend. I found a tasty Project
> Gutenberg text for it :)
Is it the 1.2 branch which needs the base-64 fixes backported into it? I'm
all for improving the performance, but I wouldn't hold up a release on
account of it.
> Also, I think our changes should go upstream to Codec, and we should
> change the package name on Base64.java to org.apache.commons.codec.
> You're a committer on Codec, so you could make it happen.
I will port the fixes to Codec. However, the XML-RPC JAR should not contain
any classes in the org.apache.commons.codec package -- experience has shown
me that this can lead to horribly difficult to debug class loading problem,
and often result in LinkageErrors when one application includes multiple
versions of the same class in its classpath. I have already experienced
enough of this horror with XML-RPC's inclusion of the SAX API. The only way
I've successfully debugged this problem is by dumping a list of all the
classes in my app, looking for duplicates, and comparing their bytecode
sizes. Software like Tomcat which uses multiple class loaders increases the
difficulty of this sort of debugging exponentially.
- Dan
Re: [VOTE] Release plan
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>
Not yet. I think the issue is basically closed except for some
uncertainty on performance with large inputs. I was going to get around
to making a test for that this weekend. I found a tasty Project
Gutenberg text for it :)
Also, I think our changes should go upstream to Codec, and we should
change the package name on Base64.java to org.apache.commons.codec.
You're a committer on Codec, so you could make it happen.
Re: [VOTE] Release plan
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
>
Not yet. I think the issue is basically closed except for some
uncertainty on performance with large inputs. I was going to get around
to making a test for that this weekend. I found a tasty Project
Gutenberg text for it :)
Also, I think our changes should go upstream to Codec, and we should
change the package name on Base64.java to org.apache.commons.codec.
You're a committer on Codec, so you could make it happen.
Re: [VOTE] Release plan
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 30 Jan 2003, Ryan Hoegg wrote:
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
Any -1 votes must be accompanied by an explanation. Explainations of your
+1 are appreciated.
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1. The 1.2 branch of the library feels stable, and IMHO has already been
through its (long) beta period. Tag the repository as XMLRPC_1_2_0, cut a
1.2 release, and simply tack on any bug fixes as 1.2.1, 1.2.2, 1.2.N, and so
on. Post release, I see the 1.2 branch as in maintainence mode only. It
will receive no new features (only bug fixes), and all development resources
should be concentrated on the trunk (what I think we all see as XML-RPC
2.0).
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-0
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release instead.
-1. 1.2 has been marinating for long enough, and is definitely worthy of a
release. If we don't have enough resources to maintain it (and I doubt
we'll find enough serious bugs for this to be problematic), we can always
suggest the 2.0 release as an upgrade/bug fix path.
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
Assign me any issues (within reason ;) you deem necessary to make the 1.2
release happen. Feel especially free to file new issues for me related to
the release management XML-RPC 1.2.
Thanks to everyone for your hard work!
- Dan
p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
Re: [VOTE] Release plan
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 30 Jan 2003, Ryan Hoegg wrote:
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
Any -1 votes must be accompanied by an explanation. Explainations of your
+1 are appreciated.
> ****************************************************
> Plan 1:
>
> Go forward with a 1.2 release as follows:
> - Beta release with bugfixes on February 15.
> - Testing happens from here on out; we elicit help on this via an
> announcement through the new ws.apache.org site.
> - No date for stable release as we don't know how many bugs we will
> hear about.
> - We will need to decide on milestones for beta and final.
+1. The 1.2 branch of the library feels stable, and IMHO has already been
through its (long) beta period. Tag the repository as XMLRPC_1_2_0, cut a
1.2 release, and simply tack on any bug fixes as 1.2.1, 1.2.2, 1.2.N, and so
on. Post release, I see the 1.2 branch as in maintainence mode only. It
will receive no new features (only bug fixes), and all development resources
should be concentrated on the trunk (what I think we all see as XML-RPC
2.0).
> ****************************************************
> Plan 2:
> Go forward with a 1.2 release as follows:
> - No concrete dates yet.
> - Same as above otherwise
-0
> ****************************************************
> Plan 3:
> Scrap the 1.2 release and go full steam for 2.0
> - Should spend some time organizing milestones for the 2.0 release instead.
-1. 1.2 has been marinating for long enough, and is definitely worthy of a
release. If we don't have enough resources to maintain it (and I doubt
we'll find enough serious bugs for this to be problematic), we can always
suggest the 2.0 release as an upgrade/bug fix path.
> I offer to take the lead on whichever we pick, but will need input and
> help from you all as well. Also I will defer to more senior developers
> if any of you wants to take the lead on the release plan.
Assign me any issues (within reason ;) you deem necessary to make the 1.2
release happen. Feel especially free to file new issues for me related to
the release management XML-RPC 1.2.
Thanks to everyone for your hard work!
- Dan
p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?