CLA for Brian Stansberry
Hi, Brian posted in his CLA around 1st of July (that's > 5 weeks ago). Is there any sign of it? I've emailed Jim directly but got no response. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
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. -Rahul > While it > would be nice, I doubt this is going to be unanimous. Unless there are > other suggestions, or someone else beats me to it, I will call a vote > in 24 hours. I plan to keep it simple, mark X before the name that > appeals most to you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLA for Brian Stansberry
Not rec'd. On Aug 9, 2005, at 6:16 AM, Simon Kitching wrote: Hi, Brian posted in his CLA around 1st of July (that's > 5 weeks ago). Is there any sign of it? I've emailed Jim directly but got no response. Thanks, Simon - 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
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. -- Martin Cooper > -Rahul > > > While it > > would be nice, I doubt this is going to be unanimous. Unless there are > > other suggestions, or someone else beats me to it, I will call a vote > > in 24 hours. I plan to keep it simple, mark X before the name that > > appeals most to you. > > > - > 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
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
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
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
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] - 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
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
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
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
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
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
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
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
On Tue, 9 Aug 2005, Phil Steitz wrote: 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. Major problems I see: * Commons Sandbox needs an improvement in policies to deal with the build up of flotsam. Other sandboxes probably do too, they just don't know it. Idea would be to handle all these with a single blow. * Bit below the belt; but promoting Sandbox could give the PMC better oversight. It tends to hide under Commons I think. * Jakarta, as a community, is not very ambitious anymore on bringing new code ideas to the table. James Carman's Syringe project that he wanted to sandbox somehow (it was outside the Commons scope); the numerous projects that many of us quite happily start outside of Jakarta (I'll point to my own stuff at osjava.org as an example there). As an umbrella, we have an interesting position on new projects. Our existing subcommunities will spawn off new subcommunities (Hivemind, JCS, HttpClient, Standard Taglib), but our TLP as a whole has no easy way to create new SLPs from scratch, unless it be by importing them (Tapestry, Agila). Noel will quite rightly point out that the Incubator is for creating new ASF communities, but the creation of a Jakarta subcommunity is not (imo) the creation of a new community, it is the result of activity of an existing community. My gut is still convincing me as to why I like the idea of having a larger scoped Sandbox. I feel it'll get us a bit more active, more entwined with each other, but haven't managed to think it through yet. I'm waffling, but I think that once we've shed all of our large TLPs, the remainder of Jakarta needs to become more of a unified community and less of a series of subcommunities; sharing a Sandbox seems like a strategic stepping stone. Just a proto-opinion :) - I think you've got a very, very good point though. If it is simply promoted up, it'll fall through the cracks between the subcommunities. 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. An easy one to answer; according to /etc/group there are 457 people in Jakarta. It's a bit harder to get a number from CVS/SVN, but they also have a rather inflated view of the committers on each project. It's a mess that needs cleaning. +1 to Brett's optimisation suggestion. Should be easy to script. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta - Cleaning house
On Tue, 2005-08-09 at 17:53 -0400, Henri Yandell wrote: > 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: > > > Move Turbine JCS to SLP (might just be a mail list change now) Should be done by now. On http://jakarta.apache.org/jcs/mail-lists.html they also mention "old mailing list" and the current lists are jcs-dev and jcs-users @jakarta. > Create a 'Graveyard' for dead projects :-) > Finish SVN migrations (Turbine-3, POI, JMeter, Cactus) Turbine-3 should go from CVS to the graveyard. No detour through SVN please. > 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. +1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta - Cleaning house
On Tue, 2005-08-09 at 18:58 -0400, Henri Yandell wrote: > Something to represent things that are not expected to have any form of > activity in the future: > > Alexandria > Commons Messenger > Commons Graph (1, 2) jakarta-turbine-3/ jakarta-turbine-jyve/ jakarta-turbine-orgami/ jakarta-turbine-tdk/ (from CVS) turbine/stratum (from SVN) should go to the "stable" site at some point. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLA for Brian Stansberry
Thanks Jim. It would appear that the US Postal service have lost the letter then. Hmm.. I'll ask Brian to post another one. Regards, Simon On Tue, 2005-08-09 at 10:46 -0400, Jim Jagielski wrote: > Not rec'd. > > On Aug 9, 2005, at 6:16 AM, Simon Kitching wrote: > > > Hi, > > > > Brian posted in his CLA around 1st of July (that's > 5 weeks ago). Is > > there any sign of it? > > > > I've emailed Jim directly but got no response. > > > > Thanks, > > > > Simon > > > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta - Cleaning house
Finish SVN migrations (Turbine-3, POI, JMeter, Cactus) Turbine-3 should go from CVS to the graveyard. No detour through SVN please. AFAIU (not totally sure) all projects need to migrated to CVS by the end of the year because CVS is meant to go away. If we want it to be still available we need to migrate it, too. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
List moderation
Hi, I've been a moderator for the bcel-dev@jakarta.apache.org and bcel-user@jakarta.apache.org for a few months now. In that time there have been 2 valid emails from people who weren't subscribed, and a few thousand spam mails. I'm rather tired of being a human spam filter for the mailing list. As the ratio of bad to good emails is so high, I suggest that all mails from unsubscribed users simply be discarded making moderation unnecessary. What's the general opinion about this? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta - Cleaning house
Hi, (... to SVN...) Yep. But I intentionally didn't migrate the dead projects into the jakarta/turbine name space because this would be bound to lead to confusion and to users seeing this and starting to ask what these trees were. Once we agreed on a name, we should have repos/asf/ and the migrate directly from the CVS there. No, I don't want to call it "mumble". ;-) Regards Henning On Wed, 2005-08-10 at 08:33 +0200, Torsten Curdt wrote: > >> Finish SVN migrations (Turbine-3, POI, JMeter, Cactus) > >> > > > > Turbine-3 should go from CVS to the graveyard. No detour through SVN > > please. > > AFAIU (not totally sure) all projects need to migrated to CVS > by the end of the year because CVS is meant to go away. If we > want it to be still available we need to migrate it, too. > > cheers > -- > Torsten > -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]