RE: [PROPOSAL] The future of Jakarta
Martin van den Bemt wrote on Tuesday, May 22, 2007 2:16 AM: That's quite problematic : Jakarta is responsible for jakarta.apache.org, not commons, sharing that responsibility will just complicate things a lot. It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. +1 We have the brand and lot of people do not even recognize that Jakarta Commons != Jakarta (nor do they probably care). Especially now that most of the original jakarta projects went to TLPs. Assimilate the rest in one flat hierarchy. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. I thought that that idea was unpopular with some commons commiters on this PMC? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Danny Angus [EMAIL PROTECTED] wrote: On 5/22/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. I thought that that idea was unpopular with some commons commiters on this PMC? I'm a Commons Committer (although not active lately, nor likely to be again soon because of other personal interests, so take this for what it's worth) ... but I always assumed that what Martin describes (commons becomes Jakarta) was the natural endgame when you've encouraged all the active subprojects that should be TLPs to do so, and dealt appropriately with dormant/dead/inactive codebases. The only other reasonable alternative would seem to mean sending Commons somewhere else and retiring the Jakarta name. That doesn't make marketing sense to me ... although (even though I have a Business Admin degree, Marketing was definitely my least favorite subject :-) On the other hand, are there enough Commons committers (across *all* the libraries) to matter (i.e. create a viable community), or should we just consider the whole thing an exercise that has come to a natural conclusion (a bunch of mature code, and a bunch of experiments that never attracted much community) and call it a day? If Commons is still viable, then Commons - Jakarta only makes sense, and the sooner the better to minize user confusion. Otherwise, the discussion of what to do next seems a bit academic. Craig PS: Yes, of course, there are passionate believers in the development of particular libraries. Are there enough to make a viable community for *any* of the libraries on their own? Or enough that care about the Commons ecosystem as a whole to satisfy Apache's notions of community? It is not clear to me (any longer) that a commons type environment fits Apache culture (as it is currently being discussed) at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: PS: Yes, of course, there are passionate believers in the development of particular libraries. Are there enough to make a viable community for *any* of the libraries on their own? Or enough that care about the Commons ecosystem as a whole to satisfy Apache's notions of community? It is not clear to me (any longer) that a commons type environment fits Apache culture (as it is currently being discussed) at all. You're right, it probably doesn't. Towards that end, we should encourage Commons components with robust communities to apply for top-level status, so that they can report directly to the Board and have their own mailing lists. The one list rule is a great equalizer and should help keep the Commons from becoming another Jakarta. To support smaller communities throughout the ASF, we may need to adjust our notion of Committer and PMC Member to include not only people who can write and apply patches, but to embrace power users too. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Voting on releasing RC artificats as Final
On Mon, 21 May 2007, Henri Yandell wrote: Don't your jars contain the version number too? Yeah, everything seems to :/ The most recent release types I've done are the type where you create the exact release and put it in your ~login where it's voted on. I like this because it makes the actual release extremely easy. The biggest downsides are a) someone might be idiotic and use a random jar from a ~login and b) if you have the release date in there somewhere you have to use the day the vote ends. That makes sense as a plan. While the rc has -final- in the artificat names, you can put it in a directory called -rc, and add a readme. Since you're probably just going to include the url to the files in the vote email to -dev (who ought to know what it means), it strikes me it ought to be fine. I've updated the poi release guide to follow your method, so we'll have to see how it works for 3.0.1! Thanks Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
- Original Message From: Ted Husted [EMAIL PROTECTED] On 5/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: PS: Yes, of course, there are passionate believers in the development of particular libraries. Are there enough to make a viable community for *any* of the libraries on their own? Or enough that care about the Commons ecosystem as a whole to satisfy Apache's notions of community? It is not clear to me (any longer) that a commons type environment fits Apache culture (as it is currently being discussed) at all. You're right, it probably doesn't. Towards that end, we should encourage Commons components with robust communities to apply for top-level status, so that they can report directly to the Board and have their own mailing lists. The one list rule is a great equalizer and should help keep the Commons from becoming another Jakarta. Huh? Commons has one mailing list. Each of its components are not isolated islands suitable for TLP, but part of the shared commons identity. They are not Jakarta style subprojects. Note that there are cliques within commons, some people care about one set of components, other people care about another set of components. Thats OK. We can all commit, we can all vote, we can all comment on the mailing list. This approach of commons is different to the rest of the ASF, but it does work (and is probably the only way to support small codebases within the ASF. I also believe it is sufficiently different to how the other projects in Jakarta have been run to make merging not necessarily smooth. In summary: a) I believe the status quo is not viable b) I believe that merging commons into Jakarta merges two mismatched groups c) I believe that commons is big enough and strong enough to be a TLP So, I support Apache Commons TLP - Just as Tomcat grew up and left the Jakarta brand name, so should Commons. But we should assert our right for that to be Java only - we really did get the name first, and the commons community (one-list, one-pmc) is fundamentally tied to Java. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The future of Jakarta
Hi Stephen, Stephen Colebourne wrote on Tuesday, May 22, 2007 2:43 PM: [snip] In summary: a) I believe the status quo is not viable b) I believe that merging commons into Jakarta merges two mismatched groups c) I believe that commons is big enough and strong enough to be a TLP So, I support Apache Commons TLP - Just as Tomcat grew up and left the Jakarta brand name, so should Commons. But we should assert our right for that to be Java only - we really did get the name first, and the commons community (one-list, one-pmc) is fundamentally tied to Java. The point is (b). Is it really that different: A merged jakarta commons vs. commons alone? Commons has also some projects with different weight. Compare lang and digester. Any current Jakarta project that feels uneasy with such an absorbtion (possibly HttpComponnets, Taglibs ??), may head for an own TLP. All the others will not make much difference - since there are view committers left and most of them have dwindling communities. Additionally most of the left ones fit quite good into commons like oro, regexp, ECS, ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Stephen Colebourne [EMAIL PROTECTED] wrote: In summary: a) I believe the status quo is not viable b) I believe that merging commons into Jakarta merges two mismatched groups My suggestion was to merge the Jakarta subprojects into the Commons, not the other way around. * The remaining subprojects all seem to be reusable components within the scope of the Commons charter. * If the remaining subprojects join the Jakarta Commons, then we could then ask the board to re-establish the Jakarta PMC, using the list suggested in the draft resolution as the initial PMC. * The extended Commons group then becomes the new Jakarta PMC. * The http://jakarta.apache.org/commons/index.html page becomes the Jakarta home page, and we change the first sentence there to read The Jakarta Commons project is focused on all aspects of reusable Java components.. In the alternative, without an anchor subproject, or a ready initiative to promote Java at Apache, realistically, Jakarta whithers away. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Quick summary of this thread 28 Votes for (23 binding), 4 against (3 binding). Seems to me that those objecting don't seem to have pursuaded people to change their vote. At what point do we decide on a result? Votes +1 (* indicates binding) 1. Henri Yandell(*) 2. Dennis Lundberg(*) 3. Mladen Turk(*) 4. Torsten Curdt(*) 5. Oliver Heger(*) 6. Robert Burrell Donkin(*) 7. Stephen Colebourne(*) 8. Daniel F. Savarese(*) 9. Martin Cooper(*) 10. Mark Thomas(*) 11. Niall Pemberton(*) 12. Stefan Bodewig(*) 13. Phil Steitz(*) 14. Jörg Schaible(*) 15. Jean-Frederic(*) 16. Henning Schmiedehausen(*) (conditional on The TLP proposal matching the template) 17. Nick Burch 18. Davanum Srinivas(*) 19. Thomas Vandahl 20. Oliver Zeigermann(*) 21. Rony G. Flatscher(*) 22. Scott Eade(*) 23. Yegor Kozlov 24. Luc Maisonobe 25. Mario Ivankovits(*) 26. Roland Weber(*) 27. Andrew Oliver(*) (think this was a vote for, voted -1 to Commons=Jakarta) 28. Jesse Kuhnert Added themselves to the TLP Proposal but didn't vote(?) 1. Jochen Wiedmann 2. Martin van den Bemt(*) 3. Matt Benson 4. Rory Winston(*) 5. Joerg Pietschmann Objections / Votes -1 = 1. Petar Tahchiev - sees no direct benfits for Commons 2. Ted Husted(*) - Strike Java from resolution or don't hijack Commons Name 3. Simon Kitching(*) - Will erect walls we took down - like Ted doesn't want java to monopolise commons name 4. Danny Angus(*) - preserve the Jakarta brand - Wants Jkarata==Jakarta Commons - thinks Commons should sort out Jakarta problems Bile Nonsense === Jean Carlo Salas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/22/07, Niall Pemberton [EMAIL PROTECTED] wrote: Quick summary of this thread 28 Votes for (23 binding), 4 against (3 binding). Seems to me that those objecting don't seem to have pursuaded people to change their vote. At what point do we decide on a result? I think you just did :) Definitely a consensus in favour of the resolution. The negative opinions in the thread then started moving in the direction of other ideas. My preference is for a single-community Jakarta, I think the time has come to finish the job - however if that looks like it's never going to come then I think the best thing is for Commons to go TLP. Here's what I think could happen: If willing, ECS, ORO, Regexp moving into Commons. Probably move ECS into maintenance immediatley but that's a different story. Both dev and user mailing lists to merge in. I think JCS, BCEL and BSF should also all move into Commons if willing; with the intention of moving them to TLP if they grow. I think BSF is a good TLP on paper, but some more time 'incubating' will be valuable and that'll be better in the relatively small move to Jakarta-Commons. Dev lists should merge in, user lists could stay outside I think (assuming some level of activity currently). Taglibs is currently discussing a good chunk of internal clean-up. We'll retire most of the taglibs and focus on three. Much like BSF, I think the future for Taglibs could easily be folding into Commons or going TLP if it more activity. Again, fold dev into commons, keep user separate. The devs there already have high overlap with Commons. --- up til this point was the easy bit :) Http Components is much the same as Taglibs/BSF, but less overlap and less interested in returning to Commons. I think it would do well to follow the same course (merge dev list, different user list, keeping an eye on TLP in the future if growth). * Slide. There's some sign of activity here. Not enough yet. * Cactus. Tiny bit of activity, again not enough for a TLP. * JMeter. Lots of commits from Sebb, but not a big community. For all three of these the best solution I can think of is to move them to the Incubator. Keep the lists where they are, move the svn, move the websites. They need to be thinking TLP, they need to get community. -- If that, or something like it, sounds like a good consensus plan, then I'm definitely more in favour of that than Commons going to TLP. There are really only four steps: Step 0: Consensus. Step 1: Move 3 projects to the Incubator. Step 2: Move other projects into Commons. Step 3: Re-establish Jakarta PMC - we'd use pretty much the same resolution we just voted on here. So the question is; is the above direction worth discussing, or should we just go with the Commons TLP. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
Henri Yandell wrote: * Slide. There's some sign of activity here. Not enough yet. * Cactus. Tiny bit of activity, again not enough for a TLP. * JMeter. Lots of commits from Sebb, but not a big community. For all three of these the best solution I can think of is to move them to the Incubator. Keep the lists where they are, move the svn, move the websites. They need to be thinking TLP, they need to get community. I think the people that work on and use these projects would feel somewhat marginalized if they were pushed over to Incubator. How about we have four categories in Jakarta Commons becomes Jakarta: * proper * sandbox * dormant * jakarta-holdouts (replace this with a better name of your choosing) The last one being a home for these projects until they can find a home elsewhere (tlp or otherwise). Would it be correct to say that one of the reasons for a commons to go tlp was that a more focused PMC is required going forward? This would still be possible with a few holdouts in the mix. Scott (crawls back under rock) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
