date:20050809




On Tue, 9 Aug 2005, Martin Cooper wrote:


On 8/9/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:

On 8/8/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:

On 8/8/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:


IMO the proposal can be finished off pretty quickly but i'm unsure about
the best way to handle the name issue. didn't seem to be any sort of a
consensus. opinions?




Is there any interest in resolving the name issue as mentioned below?
I think everyone's perception of the methodology used is key to a
swift resolution, so it'd be nice to flesh out what the method should
be.


Yes. We need to pick a name ASAP so that we can get the new subproject
off the ground with its own mailing lists, SVN repo, etc.

The problem is that the list of candidate names, as it is now, is
rather long, which could make for a somewhat messy vote. Therefore,
I'd like to propose removing some of those candidate names prior to a
vote:

* Remove anything that has "potential conflict". Let's just not go there.
* Remove League, Confederation and Bloc. I honestly don't think those
are serious names.
* I would also recommend removing Weblets, since this suggests a
uniformity of structure that simply won't be there.

That would still leave us with quite a few options to choose among.


+1.

Let's leave Jakarta out of the names. It's assumed. So in the acronym 
example from Frank, it would be Apache Jakarta WP4J and not JWP4J.


The only real problem is with Frank's suggestion of Web Parts and 
confusion over whether we'd be able to use the name; so let's get that 
cleared up before having a vote.


Firstly, don't worry about the committership part Frank. I'm certain that 
if you had a decently sized lump of code accepted, and wanted to continue 
to maintain and enhance it and the code around, that we'll quickly 
nominate committership and get it passed etc. There's doubt in that people 
are involved etc, but I've never seen the community refuse to let someone 
in who is actively doing work and wanting in.


I went through the same situation Frank is heading into a few years back. 
I had a large lump of code, some good, some crap that I wanted to donate 
into various Commons projects. Some was accepted, some was not. I'm pretty 
certain that not all of javawebparts.sf.net will end up in Jakarta . 
Some of it will be code that you like Frank.


This means that you'll hit a point where Jakarta  will have some of 
your best code, and the rest will be sitting in javawebparts and you'll 
have to decide what to do with it. Do you keep copies of the Jakarta 
 stuff (problematic)? Do you keep javawebparts as an addition to the 
Jakarta  stuff (see http://www.osjava.org/genjava/)?


In either case, the name javawebparts will be confusing when compared to 
Jakarta  if  = Web Parts. So you've three options I reckon:


1) Drop the code that doesn't make it in.
2) Have a different project name for the code that doesn't make it in.
3) Vote for something else :)

1+2 both involve deprecating the javawebparts stuff.

Hopefully none of that sounds too aggressive or anything; just trying to 
make this nice and simple so Frank can make his decision and we can 
include or not include Web Parts and WP4J as potential names.


Let's give Frank a couple of days, then call the vote depending on his 
answer. (Lack of answer means they can't be in the options).


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project

> +1.
>
> Let's leave Jakarta out of the names. It's assumed. So in the acronym
> example from Frank, it would be Apache Jakarta WP4J and not JWP4J.

Makes sense.

> Firstly, don't worry about the committership part Frank. I'm certain that
> if you had a decently sized lump of code accepted, and wanted to continue
> to maintain and enhance it and the code around, that we'll quickly
> nominate committership and get it passed etc. There's doubt in that people
> are involved etc, but I've never seen the community refuse to let someone
> in who is actively doing work and wanting in.

That is definitely one of my concerns... I absolutely want to continue to
evolve what I started and build upon it, and now I have others getting
involved too so I have even more of a concern than when it was just me
because they are affected too.

> I went through the same situation Frank is heading into a few years back.
> I had a large lump of code, some good, some crap that I wanted to donate
> into various Commons projects. Some was accepted, some was not. I'm pretty
> certain that not all of javawebparts.sf.net will end up in Jakarta .
> Some of it will be code that you like Frank.

I can live with that, but of course it matters how much is deemed "crap"
:)  If 80% of it wound up being accepted, and assuming that 80% included
some of the more interesting stuff (AjaxTags for instance), then I'd be OK
with that.  I don't know what percentage winds up making me happy or
unhappy either, I just pulled 80% out of my a** :)

> This means that you'll hit a point where Jakarta  will have some of
> your best code, and the rest will be sitting in javawebparts and you'll
> have to decide what to do with it. Do you keep copies of the Jakarta
>  stuff (problematic)? Do you keep javawebparts as an addition to the
> Jakarta  stuff (see http://www.osjava.org/genjava/)?

An addition seems reasonable... and who knows, even the stuff that doesn't
get accepted initially could wind up building a community on its own and
get added later, so that doesn't bother me.

> In either case, the name javawebparts will be confusing when compared to
> Jakarta  if  = Web Parts. So you've three options I reckon:

Agreed.

> 1) Drop the code that doesn't make it in.
> 2) Have a different project name for the code that doesn't make it in.
> 3) Vote for something else :)
>
> 1+2 both involve deprecating the javawebparts stuff.

Well, 1 involves that... 2 just involves a name change, which I'd be OK
with if I was involved with the Apache project on an ongoing basis.  Heck,
I could even call it "WP4J Jr." :)

> Hopefully none of that sounds too aggressive or anything; just trying to
> make this nice and simple so Frank can make his decision and we can
> include or not include Web Parts and WP4J as potential names.

No, not aggressive at all, I very much appreciate the discussion and
consideration!  :)

I'm in a bit of a tough position (which you have gone through, so I know
you understand) because I really do want to be involved with this project,
but there are things that would make the decision very easy if they could
be known up-front, but of course they can't be... What code will actually
be accepted and will I be invited to join as a committer chief among them.

I think you understand the conundrum for me... Java Web Parts is beginning
to build a community, albeit slowly, and I have full control over it (for
the time being anyway)... There are definite benefits to it being subsumed
by an Apache project and being involved with that instead, but I also give
up a fair amount potentially and if I didn't wind up becoming a committer
and having a good chunk of my work accepted, those benefits might not be
worth the trade-off.

I hope I'm not coming across like I'm trying to worm my way into anything
either... I just don't want to lose more than I gain :)

> Let's give Frank a couple of days, then call the vote depending on his
> answer. (Lack of answer means they can't be in the options).

I understand wanting to clear it up before calling a vote, but it might be
better to do the vote sooner than later... at the end of the day, Web
Parts might not win the vote anyway... if it doesn't, than all of this
discussion is moot... I can still contribute my stuff later if I want, but
the project can move forward either way.

> Hen

Frank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project




On Tue, 9 Aug 2005, Frank W. Zammetti wrote:


+1.

Let's leave Jakarta out of the names. It's assumed. So in the acronym
example from Frank, it would be Apache Jakarta WP4J and not JWP4J.


Makes sense.


Firstly, don't worry about the committership part Frank. I'm certain that
if you had a decently sized lump of code accepted, and wanted to continue
to maintain and enhance it and the code around, that we'll quickly
nominate committership and get it passed etc. There's doubt in that people
are involved etc, but I've never seen the community refuse to let someone
in who is actively doing work and wanting in.


That is definitely one of my concerns... I absolutely want to continue to
evolve what I started and build upon it,


Yep, that's a decision we all make in contributing to the ASF communities. 
Are you happy to go with the commuhnity view, or want to keep things 
closer to your chest.


and now I have others getting involved too so I have even more of a 
concern than when it was just me because they are affected too.


Or rather, you are getting involved with others. I suspect that the 
process would begin by restructuring the Jakarta bits, and then pulling in 
the external code.



I went through the same situation Frank is heading into a few years back.
I had a large lump of code, some good, some crap that I wanted to donate
into various Commons projects. Some was accepted, some was not. I'm pretty
certain that not all of javawebparts.sf.net will end up in Jakarta .
Some of it will be code that you like Frank.


I can live with that, but of course it matters how much is deemed "crap"
:)  If 80% of it wound up being accepted, and assuming that 80% included
some of the more interesting stuff (AjaxTags for instance), then I'd be OK
with that.  I don't know what percentage winds up making me happy or
unhappy either, I just pulled 80% out of my a** :)


I've not looked at your code, but the numbers my arse suggests based on 
how much of my code got in would be 20% straight in, 20% with 
modifications and 60% not in. Of that 60% not in, I killed half because 
someone else had put bits in, especially in Collections, but that's less 
likely to happen here I suspect.


I also killed some code because I agreed with the points of view for 
rejecting it.



1) Drop the code that doesn't make it in.
2) Have a different project name for the code that doesn't make it in.
3) Vote for something else :)

1+2 both involve deprecating the javawebparts stuff.


Well, 1 involves that... 2 just involves a name change, which I'd be OK
with if I was involved with the Apache project on an ongoing basis.  Heck,
I could even call it "WP4J Jr." :)


Probably not; it'd be a trademark issue at that point. One of those "If we 
don't defend the trademark against WP4J Jr, we can't depend it against 
Evil Company's WP4J product".



Hopefully none of that sounds too aggressive or anything; just trying to
make this nice and simple so Frank can make his decision and we can
include or not include Web Parts and WP4J as potential names.


No, not aggressive at all, I very much appreciate the discussion and
consideration!  :)

I think you understand the conundrum for me... Java Web Parts is beginning
to build a community, albeit slowly, and I have full control over it (for
the time being anyway)... There are definite benefits to it being subsumed

(snip)
I understand wanting to clear it up before calling a vote, but it might 
be better to do the vote sooner than later... at the end of the day, Web 
Parts might not win the vote anyway... if it doesn't, than all of this 
discussion is moot... I can still contribute my stuff later if I want, 
but the project can move forward either way.


Let's do that. The suggested name of Web Parts does cause us to jump the 
gun a lot in terms of assumptions, so I'll go ahead and call a vote with 
Web Parts included but with a big note that it affects how we go ahead 
with the subproject.


My gut feel is that there's a high chance you won't be happy with the way 
things would play out; ie) everyone could agree that AJAX components were 
outside scope or something.


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project

2005-08-09 Thread Curt Arnold



On Aug 9, 2005, at 2:02 PM, Henri Yandell wrote:


I went through the same situation Frank is heading into a few years  
back. I had a large lump of code, some good, some crap that I  
wanted to donate into various Commons projects. Some was accepted,  
some was not. I'm pretty certain that not all of  
javawebparts.sf.net will end up in Jakarta . Some of it will  
be code that you like Frank.


Has there been any discussion with the Incubator PMC whether this  
contribution needs to come through them?  Or does this somehow not  
fit into their purview?


I took a quick look at the javawebparts.sf.net site which currently  
looks essentially like Frank Zammetti's personal site, nothing in the  
CVS, only one committer, etc, so the legal issues are likely simpler  
than other SF projects that have migrated into Apache.  I don't know  
how much of the initial load of the Web Components/Common project is  
expected to come from javawebparts.sf.net.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WebXxxx Naming Was: Web Components/Common project



Prior to calling a vote tomorrow, am I missing any potential names. This 
is all I dredged out of the previous mail thread. 'webapp' was mentioned 
instead of 'web'; but didn't seem to get any traction.



web bricks
web components
web parts   (NOTE-1)
web commons (NOTE-2)


All would be describable (assuming no clashes) as:

Apache Jakarta Web Components
Apache Web Components

There's the option of doing W*4J or something, but we can discuss that 
later I think as it's just an altered presentation of the chosen name.


NOTE-1
==
Web parts would clash with javawebparts.sf.net name-wise and while the 
owner of this loose trademark is interested in being involved, we wouldn't 
really know until the code was looked at etc.


Also Web parts appears to be a Microsoft term (google for it); which will 
definitely cause problems if our definition of Web Parts is different to 
theirs.


NOTE-2
==
Despite the suitability of this name, we are hesitant to duplicate the 
Commons brand and confuse the user.



Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project




On Tue, 9 Aug 2005, Curt Arnold wrote:



On Aug 9, 2005, at 2:02 PM, Henri Yandell wrote:


I went through the same situation Frank is heading into a few years back. I 
had a large lump of code, some good, some crap that I wanted to donate into 
various Commons projects. Some was accepted, some was not. I'm pretty 
certain that not all of javawebparts.sf.net will end up in Jakarta . 
Some of it will be code that you like Frank.


Has there been any discussion with the Incubator PMC whether this 
contribution needs to come through them?  Or does this somehow not fit into 
their purview?


I took a quick look at the javawebparts.sf.net site which currently looks 
essentially like Frank Zammetti's personal site, nothing in the CVS, only one 
committer, etc, so the legal issues are likely simpler than other SF projects 
that have migrated into Apache.  I don't know how much of the initial load of 
the Web Components/Common project is expected to come from 
javawebparts.sf.net.


The initial load would be rearrangement of existing Jakarta codebase; some 
Commons components and Taglibs.


I can't see Frank's codebase being wanted without Frank himself being 
wanted, so a committers CLA would take care of it when we get to that step 
(unless other committers are added to javawebparts etc).


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project


> Yep, that's a decision we all make in contributing to the ASF communities.
> Are you happy to go with the commuhnity view, or want to keep things
> closer to your chest.

I think too that it's maybe a little easier to go with the community view
when its a project you didn't yourself give birth to :)

> Or rather, you are getting involved with others. I suspect that the
> process would begin by restructuring the Jakarta bits, and then pulling in
> the external code.

I think your point is a good one... there is enough already within the
foundation to get this project off the ground, and nothing says I can't
come back a few months down the road and offer up my stuff at that point. 
Might even be easier at that point to see if the fit is truly right.

> I've not looked at your code, but the numbers my arse suggests based on
> how much of my code got in would be 20% straight in, 20% with
> modifications and 60% not in. Of that 60% not in, I killed half because
> someone else had put bits in, especially in Collections, but that's less
> likely to happen here I suspect.

Yeah, those are the kinds of percentages I can't imagine being happy
with... the two 20's are fine, but that 60 stands out in a negative way
for me.  Of course I know you nor anyone else can say right now what it
would really wind up being, but your experience is a good general guide
for me.

> Probably not; it'd be a trademark issue at that point. One of those "If we
> don't defend the trademark against WP4J Jr, we can't depend it against
> Evil Company's WP4J product".

I kind of thought so as I was typing that :)

> Let's do that. The suggested name of Web Parts does cause us to jump the
> gun a lot in terms of assumptions, so I'll go ahead and call a vote with
> Web Parts included but with a big note that it affects how we go ahead
> with the subproject.

I think that's the best plan.  If everyone winds up really strongly being
in favor of Web Parts then there can be some discussion on how to make
that work.  But no sense going down that road if the consensus is for
something else anyway.

> My gut feel is that there's a high chance you won't be happy with the way
> things would play out; ie) everyone could agree that AJAX components were
> outside scope or something.

Yes, I suspect your right.  There are certain decisions I could live with
without much trouble at all, but there are some that I'm not sure I could
go along with.  If I get involved later and I don't like the decisions, I
can just bail and no one is hurt, but if I agree to certain things now and
then find I don't like how its going I'm locked-in to an extent and it
becomes painful, so better to avoid that up-front.

> Hen

Frank

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project

2005-08-09 Thread Martin Cooper

On 8/9/05, Henri Yandell <[EMAIL PROTECTED]> wrote:
> 
> Prior to calling a vote tomorrow, am I missing any potential names. This
> is all I dredged out of the previous mail thread. 'webapp' was mentioned
> instead of 'web'; but didn't seem to get any traction.
> 
> 
> web bricks
> web components
> web parts   (NOTE-1)
> web commons (NOTE-2)
> 

Some other names were added to the wiki page:

http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents

That would probably add:

- web libs
- web tools

to your list above. (I'm not sure how appropriate 'web libs' would be
though, since I'm not sure I'd refer to, say, a compression filter as
a 'library'.)

--
Martin Cooper


> All would be describable (assuming no clashes) as:
> 
> Apache Jakarta Web Components
> Apache Web Components
> 
> There's the option of doing W*4J or something, but we can discuss that
> later I think as it's just an altered presentation of the chosen name.
> 
> NOTE-1
> ==
> Web parts would clash with javawebparts.sf.net name-wise and while the
> owner of this loose trademark is interested in being involved, we wouldn't
> really know until the code was looked at etc.
> 
> Also Web parts appears to be a Microsoft term (google for it); which will
> definitely cause problems if our definition of Web Parts is different to
> theirs.
> 
> NOTE-2
> ==
> Despite the suitability of this name, we are hesitant to duplicate the
> Commons brand and confuse the user.
> 
> 
> Hen
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project

javawebparts.sf.net is my projects' page, nothing to do with this Apache
project... not sure why the code doesn't show up in the CVS stats, but if
you browse the repository you'll see it, and of course there are I think 8
file releases to date, some activity in the forums, mailing list activity,
and in the neighborhood of 10 contributors to date (one, aside from me,
ongoing, who will likely be made a committer shortly).

There are currently no plans for *any* content to come in to this new
Apache project from JWP, whether it has to go through the Incubator (I
assume it would have to) or not... that's what the last few messages in
this thread have been about :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Tue, August 9, 2005 4:26 pm, Curt Arnold said:
>
> On Aug 9, 2005, at 2:02 PM, Henri Yandell wrote:
>>
>> I went through the same situation Frank is heading into a few years
>> back. I had a large lump of code, some good, some crap that I
>> wanted to donate into various Commons projects. Some was accepted,
>> some was not. I'm pretty certain that not all of
>> javawebparts.sf.net will end up in Jakarta . Some of it will
>> be code that you like Frank.
>
> Has there been any discussion with the Incubator PMC whether this
> contribution needs to come through them?  Or does this somehow not
> fit into their purview?
>
> I took a quick look at the javawebparts.sf.net site which currently
> looks essentially like Frank Zammetti's personal site, nothing in the
> CVS, only one committer, etc, so the legal issues are likely simpler
> than other SF projects that have migrated into Apache.  I don't know
> how much of the initial load of the Web Components/Common project is
> expected to come from javawebparts.sf.net.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project

2005-08-09 Thread robert burrell donkin

On Tue, 2005-08-09 at 16:27 -0400, Henri Yandell wrote:



> NOTE-2
> ==
> Despite the suitability of this name, we are hesitant to duplicate the 
> Commons brand and confuse the user.

even though Apache WC would definitely tickled many brits...

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Web Components/Common project

To correct myself, the correct way for the code to come in is via the PMC
and the following form:

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/public/trunk/site-author/projects/ip-clearance-template.html

Happened to be doing this for the Commons CSV submission. With the case
below it looks like I'm pretty close to what would happen.

Hen

On Tue, 9 Aug 2005, Henri Yandell wrote:

On Tue, 9 Aug 2005, Curt Arnold wrote:

On Aug 9, 2005, at 2:02 PM, Henri Yandell wrote:

I went through the same situation Frank is heading into a few years back.
I had a large lump of code, some good, some crap that I wanted to donate
into various Commons projects. Some was accepted, some was not. I'm pretty
certain that not all of javawebparts.sf.net will end up in Jakarta .
Some of it will be code that you like Frank.

Has there been any discussion with the Incubator PMC whether this
contribution needs to come through them? Or does this somehow not fit into
their purview?

I took a quick look at the javawebparts.sf.net site which currently looks
essentially like Frank Zammetti's personal site, nothing in the CVS, only
one committer, etc, so the legal issues are likely simpler than other SF
projects that have migrated into Apache. I don't know how much of the
initial load of the Web Components/Common project is expected to come from
javawebparts.sf.net.

The initial load would be rearrangement of existing Jakarta codebase; some
Commons components and Taglibs.

I can't see Frank's codebase being wanted without Frank himself being wanted,
so a committers CLA would take care of it when we get to that step (unless
other committers are added to javawebparts etc).

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jakarta - Cleaning house



We're getting in a bit of a half-finished state with regards to location 
of things etc. Here's my list of things that it seems we need to get 
done. Nice and aggressive to cause consternation:



Finish moving Tomcat to TLP
Propose Slide to TLP
Move Commons HttpClient to SLP
Move Turbine JCS to SLP (might just be a mail list change now)
Move Taglibs Standard to SLP
Create WebXxx (name to be voted on)
Create a 'Graveyard' for dead projects
Create a 'Freezer' for stable projects
Kill Taglibs in favour of WebXxx
Aggressively clean Commons Sandbox
Finish SVN migrations (Turbine-3, POI, JMeter, Cactus)
Graveyarding of Alexandria
Freezing of ECS, ORO, Regexp.
BCEL/BSF challenged to show they shouldn't be considered frozen.
Work on policies for how to spot freezing/graveyard targets; BUT don't
  wait on this to create them

Additionally I'd like to propose:

Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
+  All Jakarta committers given access, central management of the sandbox 
+  concepts as opposed to individual SLP sandboxes (Taglibs, Commons, 
+  Turbine probably has things which could have gone in a sandbox).


Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
+  Clean up the very large lists of committers we have in each SLP.
+  Later the jakarta unix group can be sync'd to the SVN jakarta list.
+  Should spur a large-scale nomination of new PMC members.


Any thoughts?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta - Cleaning house

2005-08-09 Thread Yoav Shapira

Hola,
It'd be nice to have a "state of jakarta" wiki page with all this stuff: I
think much of it is already captured on other pages like the SVN migration
wiki.

> Finish moving Tomcat to TLP

Remy is on vacation for another 10 days or so, and I will be on vacation
between August 18th and 28th.  Unless the other Tomcat committers feel very
energetic while we're gone, I think we'll do the TLP migration early in
September.

> Create a 'Graveyard' for dead projects

We should start assembling a list of those.

> Create a 'Freezer' for stable projects

What goes in this category?  Assuming no product is every perfect and
improvement always possible, and that we are always open to people rejuvenating
old projects, why not combine the Freezer and the Graveyard into one?

> Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
> +  All Jakarta committers given access, central management of the sandbox 
> +  concepts as opposed to individual SLP sandboxes (Taglibs, Commons, 
> +  Turbine probably has things which could have gone in a sandbox).

+1.

> Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
> +  Clean up the very large lists of committers we have in each SLP.
> +  Later the jakarta unix group can be sync'd to the SVN jakarta list.
> +  Should spur a large-scale nomination of new PMC members.

Interesting idea.  I'm not sure it would lead to a lot of PMC nominations
versus just a lot of requests for karma restoration, but I'm not opposed to it.
 It'll be an interesting social experiment.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta - Cleaning house




On Tue, 9 Aug 2005, Yoav Shapira wrote:


Hola,
It'd be nice to have a "state of jakarta" wiki page with all this stuff: I
think much of it is already captured on other pages like the SVN migration
wiki.


Create a 'Graveyard' for dead projects


We should start assembling a list of those.


SLPs are easy. Alexandria's the only one.

Then you get Commons components, Turbine modules, Taglibs and probably the 
occasional other bit to add.



Create a 'Freezer' for stable projects


What goes in this category?  Assuming no product is every perfect and
improvement always possible, and that we are always open to people rejuvenating
old projects, why not combine the Freezer and the Graveyard into one?


In my proposal the Graveyard is for dead projects. No official stable 
release, no users, nothing. All communication would be directed to the 
[EMAIL PROTECTED] mailing list.


The Freezer is for inactive projects. Would have had releases, probably 
been very active at one point in time. The most important thing is that 
they would still have a user-base. [EMAIL PROTECTED] would still 
exist but the dev mailing list would be shutdown in favour of 
[EMAIL PROTECTED] ECS, ORO, Regexp leap to mind. BSF and BCEL 
too if their recent activity quietens down too much. Many parts of 
Taglibs/Commons too.


As you should all be reading my mind, I can't see why you didn't all know 
this already :)


Being able to freeze/unfreeze needs to be a pretty easy step. Like maybe 
we would just ask that emails to ecs-dev get automatically forwarded to 
general or something, instead of killing the list.



Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
+  Clean up the very large lists of committers we have in each SLP.
+  Later the jakarta unix group can be sync'd to the SVN jakarta list.
+  Should spur a large-scale nomination of new PMC members.


Interesting idea.  I'm not sure it would lead to a lot of PMC 
nominations versus just a lot of requests for karma restoration, but I'm 
not opposed to it.


Well, the idea is that once we get all the noise out of the way, it'll be 
very easy to see who is not on the pmc. In fact I'll probably arrange the 
subversion authorization groups to make that very obvious.


On karma requests, I'm volunteering to take the hit there. I figure it'll 
mean a week of getting lots of email to my private address, and then it 
would quieten down.


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta - Cleaning house

2005-08-09 Thread Brett Porter

On 8/10/05, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
> +  All Jakarta committers given access, central management of the sandbox
> +  concepts as opposed to individual SLP sandboxes (Taglibs, Commons,
> +  Turbine probably has things which could have gone in a sandbox).

I'd be interested to know how this works - I'm not sure unification
brings much to each of them, but it would allow a bit more oversight
by Jakarta as a whole as to each things health.

> Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
> +  Clean up the very large lists of committers we have in each SLP.
> +  Later the jakarta unix group can be sync'd to the SVN jakarta list.
> +  Should spur a large-scale nomination of new PMC members.

To save a bit of hassle I think you'll want to start by re-adding
anyone who committed to that project in the last 90 days, otherwise
that's a lot of requests :)

This all sounds pretty good though!

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Jakarta - Cleaning house

> Create a 'Graveyard' for dead projects

Absolutely not.  There is no such thing.  I might agree to an Apache
"museum", which has marginally more acceptable semantics.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Jakarta - Cleaning house




On Tue, 9 Aug 2005, Noel J. Bergman wrote:


Create a 'Graveyard' for dead projects


Absolutely not.  There is no such thing.  I might agree to an Apache
"museum", which has marginally more acceptable semantics.


I'm not tied to any particular names.

Something to represent things that are not expected to have any form of 
activity in the future:


Alexandria
Commons Messenger
Commons Graph (1, 2)

and are not believed to have any form of users.

Jakarta Scrapheap; whatever :)

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project

2005-08-09 Thread Felipe Leme


Martin Cooper wrote:


Some other names were added to the wiki page:

http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents


I forgot to add some names to that page:

Webbies(has the same idea of weblets, but causing less confusion)
Jakartlets (someone suggested we use a name without "Web" - it would be 
cool to be derived from Jakarta then, as Jakarta is tied to server side 
Java)





That would probably add:

- web libs
- web tools

to your list above. (I'm not sure how appropriate 'web libs' would be
though, since I'm not sure I'd refer to, say, a compression filter as
a 'library'.)


Web Tools can be a problem too, as it conflicts with the Eclipse Web 
Tools Platform.


-- Felipe

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WebXxxx Naming Was: Web Components/Common project

> Also Web parts appears to be a Microsoft term

I have a shirt around here someone regarding "Parts for Java", which was a
product from ParcPlace.

Apache WebParts would be OK with me, but I care more about the content of
the project than the name.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Web Components/Common project

> Has there been any discussion with the Incubator PMC whether this
> contribution needs to come through them?  Or does this somehow not
> fit into their purview?

All external codebases brought into the ASF need to come through the
Incubator.  Sometimes, as Henri noted, that only requires the IP clearance
to be filed.  We put some guidelines into that document for when it might be
appropriate.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WebXxxx Naming Was: Web Components/Common project

2005-08-09 Thread Yoav Shapira

Hey,
How about Apache Spider Web? ;)  Sorts of like it traps things, double-entendre
on the meaning of web, etc..  Just thought I'd throw it out there ;) 

Yoav

--- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote:

> > Also Web parts appears to be a Microsoft term
> 
> I have a shirt around here someone regarding "Parts for Java", which was a
> product from ParcPlace.
> 
> Apache WebParts would be OK with me, but I care more about the content of
> the project than the name.
> 
>   --- Noel
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WebXxxx Naming Was: Web Components/Common project

> How about Apache Spider Web?

No, but you just gave me an idea:

  Apache Silk

Silk is what webs are made of.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Wiki] Update of "CreatingCommonsForWebComponents" by NoelBergman

2005-08-09 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
change notification.

The following page has been changed by NoelBergman:
http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents

--
 * Confederation
 * Bloc - "The Web Bloc"
   * What about something less definite and more "code word"?  What about not 
having the word "web"? "Arctic" or "Telsa" or something completely meaningless 
but catchier than "Web .*$"
- 
+  * Apache Silk (silk is what webs are made from)
  
  This will probably need to be settled on the list. 
WebCommonsNameRequestForComments (create as needed).
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project

For what it's worth, I actually like Silk a great deal... in fact, I'd 
go ahead and give it my non-binding +1... I was the one that put the 
idea on the Wiki of a more codeword-ish name, and I think Silk is perfect.


Frank

Noel J. Bergman wrote:

How about Apache Spider Web?



No, but you just gave me an idea:

  Apache Silk

Silk is what webs are made of.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project

2005-08-09 Thread Rahul Akolkar

On 8/9/05, Henri Yandell <[EMAIL PROTECTED]> wrote:

> All would be describable (assuming no clashes) as:
> 
> Apache Jakarta Web Components
> Apache Web Components
> 
> There's the option of doing W*4J or something, but we can discuss that
> later I think as it's just an altered presentation of the chosen name.

Agreed, plus I'm not too keen to see a Java tie-in with the name,
given the current scope of the sub-project. We have other programming
models even in the starter set.

On 8/9/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> For what it's worth, I actually like Silk a great deal... in fact, I'd
> go ahead and give it my non-binding +1...  

If there is a connection to be drawn, I think many probably won't ;-)

I'd refrain from voting until a formal thread appears on the subject.
I know its hard ;-) but voting now will make it tougher to tally
opinions from multiple threads. Hen has taken the lead to call a vote
[ http://marc.theaimsgroup.com/?l=jakarta-general&m=112361926416536&w=2
], shouldn't be too long a wait.

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebXxxx Naming Was: Web Components/Common project


Rahul Akolkar wrote:

If there is a connection to be drawn, I think many probably won't ;-)


Always the risk with names that don't spell out precisely what name. 
You can easily be *too* clever, this could be one of those cases.



I'd refrain from voting until a formal thread appears on the subject.
I know its hard ;-) but voting now will make it tougher to tally
opinions from multiple threads. Hen has taken the lead to call a vote
[ http://marc.theaimsgroup.com/?l=jakarta-general&m=112361926416536&w=2
], shouldn't be too long a wait.


Yeah, I got a bit excited because I really do like the name :)  I'll 
throw my vote in the official thread when it starts... knowing me I'll 
probably change my mind 10 times by then anyway :)


Frank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta - Cleaning house

2005-08-09 Thread Phil Steitz


Brett Porter wrote:

On 8/10/05, Henri Yandell <[EMAIL PROTECTED]> wrote:


Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'.
+  All Jakarta committers given access, central management of the sandbox
+  concepts as opposed to individual SLP sandboxes (Taglibs, Commons,
+  Turbine probably has things which could have gone in a sandbox).



I'd be interested to know how this works - I'm not sure unification
brings much to each of them, but it would allow a bit more oversight
by Jakarta as a whole as to each things health.


I am -0 on this, meaning I need to understand more what exactly it will 
accomplish and I have a couple of concerns. First I am worried that for 
j-c-s in particular, separation from j-c will make it harder for j-c-s 
projects to gain critical mass and "graduate" to commons proper.


Second, removed from a "parent" SLC, a sandbox becomes a tricky thing to 
provide effective overight for. The mentor and ppmc roles in the 
Incubator are there for a reason. I would actually be more concerned 
about oversight in an "aggregated" sandbox.


If we can implement the "cleanup" policies that we have been discussing 
on commons-dev, I think the j-c sandbox should continue to work fine as 
it is and in fact be a model for the other SLPs, each overseeing its own 
if desired.  As I said, I need to understand better what problem we are 
trying to solve here.




Deletion of all CVS/SVN karma (and subsequent re-addition upon request).
+  Clean up the very large lists of committers we have in each SLP.
+  Later the jakarta unix group can be sync'd to the SVN jakarta list.
+  Should spur a large-scale nomination of new PMC members.



To save a bit of hassle I think you'll want to start by re-adding
anyone who committed to that project in the last 90 days, otherwise
that's a lot of requests :)


Yes, definitely.  Here again, not sure exactly what problem we are 
trying to solve.


Phil


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta - Cleaning house