Re: VOTE: Rick Rineholt as committer

[Glen Daniels <gd...@macromedia.com>]

Guys, I'm going to -1 this for right now; Rick, I hope you won't take
offense.  Here's my reasoning:

1) I think Axis is getting past the point where we were skipping the usual
"discussion, submit/patch code, stick around" cycle for nominating
committers due to lack of activity.  I want to get over this precedent, and
start actually evaluating people based on the quality and consistency of
their contribution to the project.  We already have a bunch of "stealth"
committers who haven't done any work on the code in ages, if ever.... :)

2) Rick's original nomination was based on the SEOM/WSTK code which Russell
integrated.  As we're not going to be using this code in its current form,
it's not quite so relevant, and in any case we haven't yet fully evaluated
it in an integrated context.  (I was also a bit dismayed to find an almost
complete lack of comments in the code)

Hence, my problem with this nomination is mostly that I don't see a reason
for it yet, and I'd rather not make new committers at this point unless
they're doing demonstrably good/relevant stuff and hopefully going to stick
around.  Now, I've heard rumors that Rick is working on certain other
extremely dangerous portions of the project - portions which have eaten
several of our other committers alive, leaving no trace of them. :)  If that
turns out to be true, and some code and discussion comes out of it, this
will certainly change.

I have nothing at all against Rick, and will gladly +1 a vote for him as a
committer once there's a little more data.

Hope that all made sense...

--Glen

Re: VOTE: Rick Rineholt as committer

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

Glen Daniels writes:
> Guys, I'm going to -1 this for right now; Rick, I hope you won't take
> offense.  Here's my reasoning:
>
> 1) I think Axis is getting past the point where we were skipping the usual
> "discussion, submit/patch code, stick around" cycle for nominating
> committers due to lack of activity.  I want to get over this precedent,
and
> start actually evaluating people based on the quality and consistency of

I'd like to +1 Glen's -1 (no, that doesn't make the total 0). I too
have been um, quite disturbed, by the randomness of committers appearing
(and disappearing).

Rick, absolutely nothing against you please.

> their contribution to the project.  We already have a bunch of "stealth"
> committers who haven't done any work on the code in ages, if ever.... :)

Oh oh, I'm one of those "if ever" ones .. so you're welcome to ignore
my +1 of Glen's -1.

> 2) Rick's original nomination was based on the SEOM/WSTK code which
Russell
> integrated.  As we're not going to be using this code in its current form,
> it's not quite so relevant, and in any case we haven't yet fully evaluated
> it in an integrated context.  (I was also a bit dismayed to find an almost
> complete lack of comments in the code)
>
> Hence, my problem with this nomination is mostly that I don't see a reason
> for it yet, and I'd rather not make new committers at this point unless
> they're doing demonstrably good/relevant stuff and hopefully going to
stick
> around.  Now, I've heard rumors that Rick is working on certain other
> extremely dangerous portions of the project - portions which have eaten
> several of our other committers alive, leaving no trace of them. :)  If
that
> turns out to be true, and some code and discussion comes out of it, this
> will certainly change.

I am personally of the opinion that this project is losing focus on
the number one priority: getting a completed SOAP implementation done
that busts the crap out of Apache SOAP in terms of performance and
usability etc. etc. and competes with the best of them out there. Yes,
WSDL generation / stub generation all that is useful and important,
but if the underlying SOAP engine ain't done, who cares? Apache SOAP
never had integrated stub gen stuff (there was only the WSDL Toolkit
via alphaWorks AFAIK), but that didn't prevent it from being used for
some useful (and certainly some useless) things. To me the priority
is getting SOAP v1.1 suppport and SOAP with Attachments support
completed ASAP in the form of a quality v1.0 distribution of Apache
Axis. None of this alpha/beta/gamma crap - its time to buckle down
and get the basics completed.

Flame away ..

In a related note, I think I'm going to advocate doing an Apache
SOAP v2.3 before the end of the year to make the various small
functional and interop fixes that have gone into Apache SOAP come
into a stable release. The time 2.2 was done in May, the idea was
that Axis would be done in the summer and that 2.2 was it. Its now
October and Axis is still in alpha2 with no visible progress on
the attachments stuff (which IMO is a performance killer). So I
think its justified in putting out (hopefully) one final, final
version of Apache SOAP.

I am not in *any way* wavering in my support of Apache Axis. We need
a SAX-based SOAP engine out there - the DOM based one simply doens't
cut it for heavy use .. plus Axis has many other cool features that
will make it much more usable than v2 is.

Sanjiva.