Missing PGP keys
I am now back in business on the signing of PGP keys etc. So I get to irritate by pointing out that we have 26 unsigned files in our distribution: http://people.apache.org/~henkp/checker/sig.html#unsig-jakarta felipeal taylor (jetspeed - need to kick this out of our dist(?)) rwaldhoff dirkv ggregory sanders glens Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing PGP keys
El lun, 06-03-2006 a las 03:07 -0500, Henri Yandell escribió: I am now back in business on the signing of PGP keys etc. So I get to irritate by pointing out that we have 26 unsigned files in our distribution: http://people.apache.org/~henkp/checker/sig.html#unsig-jakarta felipeal taylor (jetspeed - need to kick this out of our dist(?)) jetspeed-1.5 is the last release kept under jakarta. There is a 1.6 under portals. David, can Hen delete it or should we just move it over to portals? or even you sign it in place? Regards Santiago rwaldhoff dirkv ggregory sanders glens Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Representing project inactivity on the site
Just zap alexandria (we just zapped the mailinglist too). We can look at it as being promoted to TLP anyway (gump). ORO and Regexp ar kind of finished I thought, we should mark it stable or something like that. Don't know about ECS though. Mvgr, Martin Henri Yandell wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. 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: Jakarta Web Components
On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? * FileUpload (active, martinc should confirm interest in moving to JWC) Seems like the classic web component to me ;) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. Yoav -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On Mon, 6 Mar 2006, Yoav Shapira wrote: Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? * FileUpload (active, martinc should confirm interest in moving to JWC) Seems like the classic web component to me ;) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. +1 - with an aggressive application of dormant/inactive/whatever-label. Most of them are pretty much dead - some architectually, and some just in terms of community. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). snip/ Thanks for the update. I was aware of that, I sometimes read tc-dev when things of interest pop up. In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? snap/ Seems like a decision for the Tomcat PMC. I understand there is some interest in keeping 2.1 EL in the TC repository, and maybe potentially having its own release cycle. But thats hearsay, please update us when a decision is made. * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. snip/ Sounds good, I was waiting for someone else to nudge me on this. So, *all* taglibs will be moved, with a suitable application of Hen's disclaimer. -Rahul Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On Mon, 6 Mar 2006, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Seems bogged down in between states at the moment. * Latka (dormant) This should be in Jakarta Sandbox I think. * FeedParser (possibly? dormant) Jakarta Sandbox again. From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. Taglibs Sandbox should just fold in with the Commons Sandbox into a single sandbox for all of the Jakarta bits. Released stuff... back to the old question on what to do with that. Move it to JWC but then identify it as dead? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Henri Yandell wrote: On Mon, 6 Mar 2006, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Seems bogged down in between states at the moment. There is a prelimiary new site at: http://people.apache.org/~olegk/httpcomponents/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Hello, Martin et al There's already plenty of code to look at in SVN. We are gradually moving toward releasing our first official ALPHA. The preview of the HJC web site can be found here: http://people.apache.org/~olegk/httpcomponents/ May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC Cheers, Oleg * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul 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: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Hello, Martin et al There's already plenty of code to look at in SVN. We are gradually moving toward releasing our first official ALPHA. The preview of the HJC web site can be found here: http://people.apache.org/~olegk/httpcomponents/ May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? Cheers, Oleg * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? It's not important how something is implemented, what is important is what it does. Our end users (programmers) don't care that lib Foo used lib Bar. They just care what it does. When categorizing this stuff pretend you are an end user. A lib's existence is justified by how it helps it's users get work done. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Sandy McArthur wrote: As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur This may be true, but it shouldn't influence how the communities around the code are organised. This is more a matter of communication and branding. -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
In message [EMAIL PROTECTED], Henri Yandell writes: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I'm okay with both suggestions because it maps directly to how I thought things were supposed to work (i.e., all committers in a project are on PMC, only PMC members have binding votes for releases, PMC should be monitoring all releases, and so on). But I got out of the business of trying to understand how things are supposed to work at Apache a couple of years ago :) daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
In message [EMAIL PROTECTED], Yoav Shapira writes: I do care, a lot, as a user. Active means bugs are getting fixed, the mailing lists are a reasonable source for help, and if new standards I think that's a reason why perhaps a finer gradation than inactive and active may be in order. For example, if any new/real bug is reported to ORO, it will get fixed in short order. If any enhancement that includes a patch is submitted, it will be reviewed and applied or rejected with a critique in short order. However, if an enhancement request is made with no willingness on the part of the submitter to help implement the enhancement, my guess is it will not be implemented unless it's not particularly time-consuming. I see the spectrum more as Active, Maintenance Mode, and Inactive, with subprojects like ORO and Regexp being in Maintenance Mode. But if the difference boils down to semantic perception, then as long as the meaning of Active vs. Inactive is explained to the site visitor, I'm not going to quibble because a project like ORO definitely falls into the category of no new features are planned for this product. daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On Mon, 6 Mar 2006, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Henri Yandell writes: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I'm okay with both suggestions because it maps directly to how I thought things were supposed to work (i.e., all committers in a project are on PMC, only PMC members have binding votes for releases, PMC should be monitoring all releases, and so on). But I got out of the business of trying to understand how things are supposed to work at Apache a couple of years ago :) You understand it right. We've been using semantics for a few years to avoid sweeping changes. ie) PMC monitoring all releases = At least 3 PMC members voting for it, and a RESULT email to the PMC. Obeys the rules and the Jakarta spirit, though not the ASF spirit I suspect. I also suspect that I'll need to post this to every -dev list. Given that there is no Jakarta community, I doubt everyone listens to this list. I was expecting an explosion from POI at the least :) [due to their legal worries over commit rights]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Mon, 6 Mar 2006, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Yoav Shapira writes: I do care, a lot, as a user. Active means bugs are getting fixed, the mailing lists are a reasonable source for help, and if new standards I think that's a reason why perhaps a finer gradation than inactive and active may be in order. For example, if any new/real bug is reported to ORO, it will get fixed in short order. If any enhancement that includes a patch is submitted, it will be reviewed and applied or rejected with a critique in short order. However, if an enhancement request is made with no willingness on the part of the submitter to help implement the enhancement, my guess is it will not be implemented unless it's not particularly time-consuming. I see the spectrum more as Active, Maintenance Mode, and Inactive, with subprojects like ORO and Regexp being in Maintenance Mode. But if the difference boils down to semantic perception, then as long as the meaning of Active vs. Inactive is explained to the site visitor, I'm not going to quibble because a project like ORO definitely falls into the category of no new features are planned for this product. Active Development Maintenance Mode Unsupported ?? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
In message [EMAIL PROTECTED], Henri Yandell writes: Active Development Maintenance Mode Unsupported I think you nailed it. Active, Supported, and Unsupported. Or Active, Inactive (Supported), and Inactive (Unsupported). Anyway, whatever the specific names end up being, that's the gist of it. daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Hola, In message [EMAIL PROTECTED], Henri Yandell writes: Active Development Maintenance Mode Unsupported +1. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: ... Active Development Maintenance Mode Unsupported ?? Purely from a semantics perspective, unsupported seems to imply you can count on some sort of support while the project is being maintained. Although there is support, it is definitely not something you can count on. (at least that is the general rule of thumb I understand with open source) Maybe Unmaintained would be better?
Re: Representing project inactivity on the site
On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Active Development Maintenance Mode Unsupported My preference would be: Active Development: not really named though, the implied default Hibernating: not active but will wake up as needed Dormant: no future activity is expected -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/6/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Active Development Maintenance Mode Unsupported My preference would be: Active Development: not really named though, the implied default Hibernating: not active but will wake up as needed Dormant: no future activity is expected i'm not sure that Hibernating works as well as Maintenance Mode, largely because i think the community is more important than the code in these situations. If the -dev list is quiet but the -user list is continually active, i don't think it fits to describe the project as hibernating. i like the Active Development, Maintenance Mode, and Unmaintained options. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Mon, 6 Mar 2006, Scot Hale wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: ... Active Development Maintenance Mode Unsupported ?? Purely from a semantics perspective, unsupported seems to imply you can count on some sort of support while the project is being maintained. Although there is support, it is definitely not something you can count on. (at least that is the general rule of thumb I understand with open source) Maybe Unmaintained would be better? +1 - good idea. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Sandbox?
Over on Commons-Dev, Stephen has suggested that we split some of the components out to form a Jakarta Language Components group. Consensus is in favour of the idea, so I'm sure we'll see a vote on that and some movement soon. Commons ID (and Commons CSV perhaps) are two elements in the Commons Sandbox which would potentially go to JLC, but there are (wisely) no plans for a separare JLC Sandbox. Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). That has a Sandbox as well. Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - which technically lost access to its sandbox - though I suspect it's been a long time since it used it. To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Forgot something. Stephen pointed out on Commons that this may mean a need for a [EMAIL PROTECTED] mailing list. We could try to use general@, but dev@ probably makes more sense. So +1 to that. Hen On Mon, 6 Mar 2006, Henri Yandell wrote: Over on Commons-Dev, Stephen has suggested that we split some of the components out to form a Jakarta Language Components group. Consensus is in favour of the idea, so I'm sure we'll see a vote on that and some movement soon. Commons ID (and Commons CSV perhaps) are two elements in the Commons Sandbox which would potentially go to JLC, but there are (wisely) no plans for a separare JLC Sandbox. Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). That has a Sandbox as well. Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - which technically lost access to its sandbox - though I suspect it's been a long time since it used it. To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? 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: Jakarta Sandbox?
On Mon, 2006-03-06 at 22:42 -0500, Henri Yandell wrote: Over on Commons-Dev, Stephen has suggested that we split some of the components out to form a Jakarta Language Components group. Consensus is in favour of the idea, so I'm sure we'll see a vote on that and some movement soon. Commons ID (and Commons CSV perhaps) are two elements in the Commons Sandbox which would potentially go to JLC, but there are (wisely) no plans for a separare JLC Sandbox. Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). That has a Sandbox as well. Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - which technically lost access to its sandbox - though I suspect it's been a long time since it used it. To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? I presume that a commons committer would have commit access to both old commons and Language Components? Having a separate commit list would set the barrier to high for movement between the groups. Actually, the proposed jakarta-wide commit access would be even better. Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a sandbox exactly? In general, though, the split-off of Jakarta Language Components seems wise. Commons email traffic is a pretty hefty burden, so halving it for people only interested in one of the two new commons pieces is good. I believe there are enough people interested in each community to allow the separate pieces to thrive. Of course people should be encouraged to subscribe to both where possible - and general always! Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Simon Kitching wrote: On Mon, 2006-03-06 at 22:42 -0500, Henri Yandell wrote: To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? I presume that a commons committer would have commit access to both old commons and Language Components? Having a separate commit list would set the barrier to high for movement between the groups. Actually, the proposed jakarta-wide commit access would be even better. I'm assuming the latter, yeah. I'm presuming we need to have a vote on the SVN one soon, there's not really been a lot discussion-wise there other than +1 and -1s. We're seen as a bit vote-happy - if there's consensus on something just do it, don't worry about the vote; but I don't think well get unaminous consensus on any of these issues. Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a sandbox exactly? The sandbox is somewhere where existing Jakarta committers can start up new components - and any ASF committer can then join in. How it would work depends on which direction we go. I'd like to see us consider Jakarta a large bag of components with groupings to ease communication - but not form a subhierarchy. Components would either be in one grouping only, or many groupings - depending on whether we wanted to try the more interesting yet trickier latter option. In that case, the sandbox is quite simple - the same thing it is for Commons. Once something leaves the sandbox its groupings and communication lines would be determined. Commit emails would goto the [EMAIL PROTECTED] list. Another option is to use groupings as the new subprojects. In that case the sandbox becomes a bit more of an incubator, maybe with commit emails going back to the subprojects - or we lessen it so that the new subproject groupings can start things up internally and they would come to the sandbox when they wanted to engender cross-Jakarta activity, with commit emails going to [EMAIL PROTECTED] probably. I'm obviously not much of a salesman for the latter. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/6/06, Simon Kitching [EMAIL PROTECTED] wrote: snip/ Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a sandbox exactly? snap/ IMO, this is a good point. Its like going to grad school, if you expect to graduate, at some point you must declare a major (sorry about the analogy, I'm aware they rarely work ;-). So unclear how this will play out in a Jakarta sandbox. Concretely speaking, if we mix the Commons and Taglibs sandboxes today, and assume that the groupings mentioned in this thread already exist -- some commits need to go the JWC, some to JLC and some to Commons - JLC (whatever that is). In general, though, the split-off of Jakarta Language Components seems wise. Commons email traffic is a pretty hefty burden, so halving it for people only interested in one of the two new commons pieces is good. I believe there are enough people interested in each community to allow the separate pieces to thrive. Of course people should be encouraged to subscribe to both where possible - and general always! snip/ +1 -- its time to establish that there are two equally useful pieces here, with differing API styles, differing thresholds for involvement and therefore, potentially attracting differing audiences (at the user and developer level). The more shared developers we can retain the better, ofcourse its understood that individual interests will trump utopian views in this regard. -Rahul Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Mon, 6 Mar 2006, Rahul Akolkar wrote: +1 -- its time to establish that there are two equally useful pieces here, with differing API styles, differing thresholds for involvement and therefore, potentially attracting differing audiences (at the user and developer level). The more shared developers we can retain the better, ofcourse its understood that individual interests will trump utopian views in this regard. I think this goes a bit too far. There aren't two pieces, there are thirty four. Stephen's proposal pulls a quarter of those out into a somewhat cohesive bundle based on the J2SE and a tendency to have XxxUtils classes. We (the Jakarta community - ie: this list), presuming we decide to go with the JLC proposal, still have to deal with the rest of Commons, and how the rest of Jakarta fits into this. ORO/Regexp/BCEL seem like possibles for JLC, ECS for JWC, Jelly+BSF+EL for some other place? Will ask Stephen to repost the proposal here. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
