Re: Benefits of Apache Commons

[Greg Stein <gs...@lyra.org>]

On Tue, Nov 11, 2003 at 05:24:59AM -0800, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, Greg Stein wrote:
>...
> > Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You don't
> > have to. But some others do, and it appears that some J-C components will
> > move. Why is that so threatening?
> 
> On the contrary, I think apache-commons has several things going for it,
> and I'd very much like to see the project, or more generally, its mission
> of creating reusable library code under the ASL, succeed.  Frankly, I'm a
> bit insulted you'd characterize this interest as feeling "threatened" by
> the possibility, and I'm disappointed that you'd respond to any difference
> of opinion about how to best accomplish that mission by with comments
> along the lines of "and if you disagree, then go away".

I don't want you guys to "go away". Quite the contrary. I'd prefer if you
offered constructive criticism, assistance, and insight. But to be honest,
a lot of what I have seen is "but why? J-C does this already. let's just
promote that instead." or "why should they give up their community?" or
"svn creates barriers" or ...

There has been very little, "this is how J-C operates, and to make them
feel at home in A-C, we should do X."

To be honest, Rodney: yes, I may have lumped you in unfairly with Geir,
whose positions are very much more "J-C does this right. why should anyone
bother with A-C?" But my response was built from an overall impression,
which is that I'm not seeing "we can fix things <this> way".

To me, I read the resistance to A-C and some of the responses as feeling
threatened by a loss of community, self-rule, etc. So... that's how I read
it; if that doesn't represent your thinking, then I apologize, and will
blame email as an imperfect medium. What may simply be "devil's advocate"
discussion or similar can easily be construed as reading a position or
belief, which can be quite incorrect. And, of course, the easiest way to
correct it is to call out the issue as you did :-)

> Not to put to fine a point on it, but if I were "threatened" by the
> possibility of jakarta-commons components moving to apache-commons, then I
> probably wouldn't be offering suggestions about how best to encourage j-c
> components to move to a-c, as you see me doing at
> <http://article.gmane.org/gmane.comp.apache.commons.general/151> and
> <http://article.gmane.org/gmane.comp.apache.commons.general/158>, to name
> two examples.

And re-reading those two posts also leads me to say, "hunh. there *have*
been nuggets of 'here is info about J-C'". Mebbe too thick-headed to see
them :-).  I might suggest that the answer is to simply start asking J-C
components if they want to move. If they say "yes", then fine. If they say
"no", then we ask "why?". That provides very concrete info rather than
continual discussion and theorizing...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Benefits of Apache Commons

[robert burrell donkin <rd...@apache.org>]

On 12 Nov 2003, at 12:46, Geir Magnusson Jr. wrote:
> On Wednesday, November 12, 2003, at 06:36 AM, Greg Stein wrote:

<snip>

>> To me, I read the resistance to A-C and some of the responses as  
>> feeling
>> threatened by a loss of community, self-rule, etc. So... that's how I  
>> read
>> it; if that doesn't represent your thinking, then I apologize, and  
>> will
>> blame email as an imperfect medium. What may simply be "devil's  
>> advocate"
>> discussion or similar can easily be construed as reading a position or
>> belief, which can be quite incorrect. And, of course, the easiest way  
>> to
>> correct it is to call out the issue as you did :-)
>
> I think that 'loss of community' isn't a threat - it's a mistake, but  
> that's just my opinion.  And 'self-rule' wouldn't change - the people  
> that should be in charge, the committers, will probably be in charge  
> in A-C.   So no real change from those perspectives.
>
> I think I'm just confused.  There is a 'Jakarta must die' flavor to  
> all of this. (That's a quote, btw).  Call it paranoia on my part, but  
> when I see Robert, who is usually very factual and correct, on the J-C  
> list saying things like :
>
> "commons-maths will still be part of jakarta-commons :)
>
> it'll only be managed by the apache-commons pmc.
>
> best of both worlds :)"
>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=106841721301207&w=2

as i understood it, this is what the flatteners (such as stephano) were  
proposing: projects can be part of the jakarta community - manifest by  
links from the main jakarta web site - without having to be managed by  
the jakarta pmc at least from the perspective of users. from the  
perspective of committers (of course) the product would be part of  
another project.

> I'm just simply baffled by what's going on.  How could it be that a  
> J-C project is managed by A-C's PMC?  Is that something the board has  
> mandated?  That A-C will managed codebases in other Apache projects?

as i understood it, flattening was the official way forward.

if flattening is to progress further then IMHO either jakarta will have  
to start throwing sub-projects out or the kind of vision outlined by  
stephano (and the other flatteners) whereby products can be in jakarta  
from the perspective of the user but in another project from the  
perspective of the ASF is needed.

jakarta has a good reputation in the java community and is probably now  
better known that apache within that community. losing the benefit of  
that reputation is something that many sub-projects seems to fear.

- robert

Re: Benefits of Apache Commons

["Geir Magnusson Jr." <ge...@optonline.net>]

On Wednesday, November 12, 2003, at 06:36 AM, Greg Stein wrote:

> On Tue, Nov 11, 2003 at 05:24:59AM -0800, Rodney Waldhoff wrote:
>> On Mon, 10 Nov 2003, Greg Stein wrote:
>> ...
>>> Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You  
>>> don't
>>> have to. But some others do, and it appears that some J-C components  
>>> will
>>> move. Why is that so threatening?
>>
>> On the contrary, I think apache-commons has several things going for  
>> it,
>> and I'd very much like to see the project, or more generally, its  
>> mission
>> of creating reusable library code under the ASL, succeed.  Frankly,  
>> I'm a
>> bit insulted you'd characterize this interest as feeling "threatened"  
>> by
>> the possibility, and I'm disappointed that you'd respond to any  
>> difference
>> of opinion about how to best accomplish that mission by with comments
>> along the lines of "and if you disagree, then go away".
>
> I don't want you guys to "go away". Quite the contrary. I'd prefer if  
> you
> offered constructive criticism, assistance, and insight. But to be  
> honest,
> a lot of what I have seen is "but why? J-C does this already. let's  
> just
> promote that instead." or "why should they give up their community?" or
> "svn creates barriers" or ...
>
> There has been very little, "this is how J-C operates, and to make them
> feel at home in A-C, we should do X."
>
> To be honest, Rodney: yes, I may have lumped you in unfairly with Geir,
> whose positions are very much more "J-C does this right. why should  
> anyone
> bother with A-C?" But my response was built from an overall impression,
> which is that I'm not seeing "we can fix things <this> way".

I guess my problem is that I don't yet buy into A-C as a forgone  
conclusion as the solution to J-Cs problems, when there's incredible  
potential to fix what is deemed wrong with J-C.  I do see value in the  
language specific community of J-C, given the richness of interaction  
due to binary interoperability.  Also, I obviously think that the  
'commons' notion is a good idea.  Math *is* a good example of a  
candidate to move to A-C is there's interest in doing math in some  
other language for speed, and then the j-c math would use JNI to get to  
the fast libraries in A-C.  But there's a few ways to skin that cat too.

It appears to me that A-C is being bootstrapped from top down rather  
than bottom up.  J-C was a bottom-up bootstrap put together by a bunch  
of us in jakarta who noticed a problem (lots of duplicated utility code  
in the jakarta sub-projects) and went about solving it.  It was a  
community solution - many, many jakarta members debated [seemingly  
endlessly] about our charter, proposed it to the PMC of Jakarta, and  
got it going.  It's been a runaway success. (Which is the problem - you  
have a previous post where you point out the obvious problems, like the  
single mail list, etc)

And please don't misrepresent my positions - I don't wonder why anyone  
should "bother" with A-C - I just don't see anyone naturally doing it  
besides you and Justin w/ surf.  It sounds like A-C is the proper  
solution for serf if it didn't fit in httpd, but wonder why there  
hasn't been any natural migration of other code from Apache projects.

In a way, A-C is what I hoped DB could be, language-neutral (or  
any-language) tools and utilities, just w/o the db focus.  And to that  
end, I'm surprised too that there wasn't more that moved into db.  I  
thought that there would be a bunch of ETL-ish things in languages  
other than Java that would want to find a home there, but there hasn't  
been any interest.  I guess either because of poor advertising, or  
established projects don't see the value of moving.

>
> To me, I read the resistance to A-C and some of the responses as  
> feeling
> threatened by a loss of community, self-rule, etc. So... that's how I  
> read
> it; if that doesn't represent your thinking, then I apologize, and will
> blame email as an imperfect medium. What may simply be "devil's  
> advocate"
> discussion or similar can easily be construed as reading a position or
> belief, which can be quite incorrect. And, of course, the easiest way  
> to
> correct it is to call out the issue as you did :-)

I think that 'loss of community' isn't a threat - it's a mistake, but  
that's just my opinion.  And 'self-rule' wouldn't change - the people  
that should be in charge, the committers, will probably be in charge in  
A-C.   So no real change from those perspectives.

I think I'm just confused.  There is a 'Jakarta must die' flavor to all  
of this. (That's a quote, btw).  Call it paranoia on my part, but when  
I see Robert, who is usually very factual and correct, on the J-C list  
saying things like :

"commons-maths will still be part of jakarta-commons :)

it'll only be managed by the apache-commons pmc.

best of both worlds :)"

http://marc.theaimsgroup.com/?l=jakarta-commons- 
dev&m=106841721301207&w=2

I'm just simply baffled by what's going on.  How could it be that a J-C  
project is managed by A-C's PMC?  Is that something the board has  
mandated?  That A-C will managed codebases in other Apache projects?

>
>> Not to put to fine a point on it, but if I were "threatened" by the
>> possibility of jakarta-commons components moving to apache-commons,  
>> then I
>> probably wouldn't be offering suggestions about how best to encourage  
>> j-c
>> components to move to a-c, as you see me doing at
>> <http://article.gmane.org/gmane.comp.apache.commons.general/151> and
>> <http://article.gmane.org/gmane.comp.apache.commons.general/158>, to  
>> name
>> two examples.
>
> And re-reading those two posts also leads me to say, "hunh. there  
> *have*
> been nuggets of 'here is info about J-C'". Mebbe too thick-headed to  
> see
> them :-).  I might suggest that the answer is to simply start asking  
> J-C
> components if they want to move. If they say "yes", then fine. If they  
> say
> "no", then we ask "why?". That provides very concrete info rather than
> continual discussion and theorizing...

The math component is doing that, and there are some interesting  
possibilities.

>
> Cheers,
> -g
>
> -- 
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geirm@optonline.net