Re: Representing project inactivity on the site
On Mon, 2006-03-06 at 16:53 +0100, Martin van den Bemt wrote: 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. ECS is pretty much complete. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Henri Yandell wrote: * ECS, ORO, Regexp to be moved to a label of Inactive. Think of Regexp as of low maintenance project. There are several issues reported against it, and some of those can be (relatively) easy fixed and new release can be pushed out. It would be disappointing if such labeling makes it harder to maintain project or forces users to look elsewhere. 'Mature' seems to better reflect current state of the project. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: 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: 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]
Re: Representing project inactivity on the site
Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] 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] -- 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: Representing project inactivity on the site
Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Or does Dormant/Inactive imply Mature/Stable? S. On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] 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] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Hi, You're right, that's a good distinction to make, because dormant/inactive is not always the same as mature/stable. That's why we wrote the explanation on the Watchdog page with regards to servlet specification versions. On the ORO page, I might imagine a notice saying this project is dormant but considered mature/stable, and not much work is being done now because regex's are natively in supported in JDK 1.4. Or something to that effect... Yoav On 3/5/06, sebb [EMAIL PROTECTED] wrote: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Or does Dormant/Inactive imply Mature/Stable? S. On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] 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] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Representing project inactivity on the site
Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Public key fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E signature.asc Description: This is a digitally signed message part
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. That's one of the problems, we have many different messages: Alexandria - Dead. Unreleased. No future. Delete. BCEL - In need of a bugfix release, design-wise ASM is preferrable. BSF - Would have been in the inactive category, now active again. ECS - Tiny user base. No interest in a 2.0. Unfashionable designwise. JCS - Seems very inactive. Unsure on userbase. Keeps getting forked. (ehcache, jcache/fkache). Regexp - Tiny user base. Dead development. ORO - JDK 1.2 engine of choice. Inactive development - there is no reason to start development up again currently. Slide - Too inactive to complete its TLP move. Turbine - Umbrella of its own. Hard to know what the activity is in each, but the mailing list isn't that active. Commons - Active, but definite areas of inactivity. Taglibs - Inactive, RDC Taglib is about it for activity there. Velocity - At least DVSL is dead - unsure about tools. POI - Seems to be fighting inactivity. Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. How about a project is in hibernation. In other words no future developement is expected unless the enviroment for that project changes. -- 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/5/06, Henri Yandell [EMAIL PROTECTED] 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. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. -- Martin Cooper 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]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. That's one of the problems, we have many different messages: Alexandria - Dead. Unreleased. No future. Delete. BCEL - In need of a bugfix release, design-wise ASM is preferrable. BSF - Would have been in the inactive category, now active again. ECS - Tiny user base. No interest in a 2.0. Unfashionable designwise. JCS - Seems very inactive. Unsure on userbase. Keeps getting forked. (ehcache, jcache/fkache). Regexp - Tiny user base. Dead development. ORO - JDK 1.2 engine of choice. Inactive development - there is no reason to start development up again currently. Slide - Too inactive to complete its TLP move. Turbine - Umbrella of its own. Hard to know what the activity is in each, but the mailing list isn't that active. Commons - Active, but definite areas of inactivity. Taglibs - Inactive, RDC Taglib is about it for activity there. Velocity - At least DVSL is dead - unsure about tools. VelocityTools is very much alive. POI - Seems to be fighting inactivity. Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. 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: Representing project inactivity on the site
BCEL - In need of a bugfix release, design-wise ASM is preferrable. Almost there :) ...still a few bugs to close cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] 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. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. I'm suggesting: Active Subprojects * Alexandria * BCEL * BSF * Commons * HiveMind * JMeter * Tapestry * Velocity Inactive Subprojects * Cactus * ECS * JCS * ORO * POI * Regexp * Slide * Taglibs * Turbine Though it's also obvious that I want all of the Commons components, Turbine components, Velocity components, Taglibs components and any other hidden away sub-sub-projects to be at the same level. Alexandria itself would just go into a trash-can - same place JServ went. -- All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Am Sonntag, den 05.03.2006, 16:08 -0500 schrieb Henri Yandell: Inactive Subprojects ... * POI ... No! POI is not inactive at all. I just committed a major enhancement a few days ago. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Public key fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E signature.asc Description: This is a digitally signed message part
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 16:08 -0500 schrieb Henri Yandell: Inactive Subprojects ... * POI ... No! POI is not inactive at all. I just committed a major enhancement a few days ago. *evil grin* I may have added a couple to that list that I know are active-ish to see if they pay attention to general@ :) Generally POI's mailing list is full of gump errors and bug reports, but there was a recent bit of discussion. I also don't pay attention to the svn checkins for poi but look for mail list discussion to indicate activity. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Henri Yandell wrote: Inactive Subprojects * Cactus Cactus is more on a 'Hibernation' status; I agree there hasn't been activities in the last weeks, but we have some stuff planned (for instance, I should have relased Cactus 1.7.2 to fix the jboss-j2ee.jar issue, but couldn't do so yet...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Felipe Leme wrote: Henri Yandell wrote: Inactive Subprojects * Cactus Cactus is more on a 'Hibernation' status; I agree there hasn't been activities in the last weeks, but we have some stuff planned (for instance, I should have relased Cactus 1.7.2 to fix the jboss-j2ee.jar issue, but couldn't do so yet...) This is true of most of our inactive codebases - and it will stay that way if we let them wait quietly on their -dev lists for time to show up. I've screwed up in forgetting the jboss-j2ee jar issue; should be yelling at you guys to get that release done :) For something like this, it's essential that we're talking about it on general@ and not on cactus-dev. If something has been in Hibernation status for a period of time, the only real hope (imo) is to declare it inactive and see if that shocks the committers into doing something. I've meant to do something about my PGP problems for 2 years or so. It's only the embaressment of admitting that it's just a couple of evenings worth of work to fix them and a couple of USB keys at the supermarket that have kicked me into dealing with it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] 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. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. I'm suggesting: Active Subprojects * Alexandria * BCEL * BSF * Commons * HiveMind * JMeter * Tapestry * Velocity Inactive Subprojects * Cactus * ECS * JCS * ORO * POI * Regexp * Slide * Taglibs * Turbine But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. Though it's also obvious that I want all of the Commons components, Turbine components, Velocity components, Taglibs components and any other hidden away sub-sub-projects to be at the same level. Alexandria itself would just go into a trash-can - same place JServ went. -- All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I 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 become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. 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: Representing project inactivity on the site
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. Agreed - that's why I'm not JFDI as one piece of advice I've received suggests. I'm also trying to avoid it being manipulation - I could have pushed each item one at a time in most-likely-to-be-accepted order. That would have been a lot easier, but too machiavellian. Least I'm trying to not be doing that :) Thus emails about long term ideas etc. More confusing to the community, but less manipulative. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. Stepping further back than the community question - do you think the current Jakarta community of communities is healthy? Do you think there are ways that an umbrella (in the negative sense of the word) can continue to grow (in health rather than size) within the ASF? It's possible it's just me wanting to make the chair role a non-fulltime job. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I 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 become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. You snipped out the part that explains what you quoted. ;-) What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not If you are saying that you wouldn't even try out a component that's marked as 'inactive', to see if it does what you need, then I think it would be a *huge* disservice to flag components as inactive right on the front page, because then people might not even look at them, even if they're done and would completely fit their needs. Marking a component as 'inactive' would then be the final nail in its coffin. -- Martin Cooper 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: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. Agreed - that's why I'm not JFDI as one piece of advice I've received suggests. I'm also trying to avoid it being manipulation - I could have pushed each item one at a time in most-likely-to-be-accepted order. That would have been a lot easier, but too machiavellian. Least I'm trying to not be doing that :) Thus emails about long term ideas etc. More confusing to the community, but less manipulative. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. Stepping further back than the community question - do you think the current Jakarta community of communities is healthy? Not completely, no. I don't follow all the pieces as closely as I believe you do, but gangrene has definitely set in in places. Taglibs is the example I'm most familiar with, but I believe that can be resolved by amputating the truly dead limbs and revitalising the remainder as part of the (eventually, I hope) forthcoming Jakarta Web Components subproject. (On the other hand, I suspect that part of the reason for the demise of Taglibs is because a lot fewer people are using JSP tags these days, having moved on to AJAX or JSF.) With many Jakarta subprojects having been around for some time, some of them are just more or less done, which leads to quiet spots in the community. I think that's fine - we need to recognise that most software projects don't go on forever (even if it can seem otherwise, sometimes ;), and most developers don't work on the same projects all of their lives. When the conversation slows or comes to an end on subproject X, we shouldn't assume the community is then unhealthy. Maybe it's just done, or people have moved on to a different technology, or whatever. Putting an old race horse out to pasture is a lot different than killing it. ;-) Do you think there are ways that an umbrella (in the negative sense of the word) can continue to grow (in health rather than size) within the ASF? In health, yes, and I think we're on that path. Shrinking in size and bringing the scale of subprojects closer together both help, and much of that has happened, with the big subprojects moving out to TLPs. Getting Web Components off the ground will also help. And in that same vein of collecting like components into Commons-ish sets, I believe that Stephen Colebourne's proposal for Jakarta Language Components would also help. Despite some pitfalls along the way, I believe the Commons model has worked well, and seeing that spread into Web Components and Language Components is great. -- Martin Cooper It's possible it's just me wanting to make the chair role a non-fulltime job. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Martin Cooper [EMAIL PROTECTED] wrote: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. My thoughts exactly. -- 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/5/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/5/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I 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 become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. You snipped out the part that explains what you quoted. ;-) What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not If you are saying that you wouldn't even try out a component that's marked as 'inactive', to see if it does what you need, then I think it would be a *huge* disservice to flag components as inactive right on the front page, because then people might not even look at them, even if they're done and would completely fit their needs. Marking a component as 'inactive' would then be the final nail in its coffin. i quite agree! -- Martin Cooper 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
