Re: [Jakarta Wiki] Update of JakartaBoardReport-current by MartinvandenBemt
If everyone is ok with it, I will send the current state of this page as the board report ? Mvgr, Martin - Original Message - From: Apache Wiki wikidi...@apache.org To: general@jakarta.apache.org Sent: Monday, May 18, 2009 9:45:42 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [Jakarta Wiki] Update of JakartaBoardReport-current by MartinvandenBemt Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by MartinvandenBemt: http://wiki.apache.org/jakarta/JakartaBoardReport-current -- === Status === - Chair to summarize Jakarta-wide news + the current state of affairs. + It has been a while since I reported the last time. In june 2009 I announced + that I wanted to be replaced because of time constraints, with no one + volunteering. After that however I got caught up with what was happening in my + personal life and also was shutdown for over 3 months, which ended up in a + long period of silence. + Now all major personal events (positive I might add, so please don't worry) + have passed, I however still find myself fighting to find time (and energy) to + spend at Apache. + + In the light of this, I hand in my resignation as VP Apache Jakarta. + To my relieve a discussion about the (in reality already effective) vacancy + started and some people stood up to volunteer to take over the position. + + I myself regret the long absence and silence and I hope it didn't cause to + much worry and problems. + === Releases === - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] JMeter 2.3.2RC7 - please!
Looks good.. +1 Mvgr, Martin sebb wrote: Trying yet again ... votes needed (positive or negative) - thanks! The licence issues reported by Henri have (I trust) been fixed. Also the lib/opt directory is now included in the source archives. To rebuild or test JMeter, you need to unpack both the binary and source archives in the same directory structure. This is because the library files are not duplicated in the source archive. Note that there is a bug in Java on some Linux systems that manifests itself as the follow error when running the test cases or JMeter itself. [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.2RC7/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2RC7/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC7 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC tag. Here's my: +1 S/// - 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: [VOTE] JMeter 2.3.2RC1 - cancelled
Do you by default run RAT on releases ? Mvgr, Martin sebb wrote: I'll be doing another build to try and address the issues raised so far. In the meantime, please continue to report any further problems that may be seen - thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Board Report January
== December 2007 Board Report == === Status === The downsizing of Jakarta continued this quarter. HttpComponents became TLP and has finished moving all the resources to their own TLP. We wish them all the best with their new identity! Slide was retired (see Slide section for more details), with a notice on the Slide page (see http://jakarta.apache.org/slide/). The main focus this quarter will be (re)starting discussions about the future of the mature components/libraries like ORO, Regexp (maintained) and ECS and BCEL (not maintained). === Releases === * 29 September 2007 - JMeter 2.3 final * 9 October 2007 - !HttpComponents !HttpCore 4.0 alpha 6 * 7 November 2007 - !HttpComponents !HttpClient 4.0 alpha 2 * 30 November 2007 - JMeter 2.3.1 final === Community changes === No changes in the community === Subproject news === BCEL No activity this quarter. Since there is a lack of developer and user community, we should definitely retire BCEL this quarter and also point the users to possible alternatives. A discussion will be started about this. BSF There is an outstanding request for the TCK for scripting. Geir expressed the concern that this TCK could be part of the JDK 1.6 TCK and not independ. We are sitll waiting for the definitive answer on this. Cactus Development has picked up after Apachecon Atlanta and Petar is working towards a release. ECS No activity and not maintained. As with BCEL it is probably best to retire the project or see if it can find a home at Apache Commons. HttpComponents HttpComponents released one alpha each for HttpCore and HttpClient as a Jakarta sub-project. A TLP proposal was submitted for the November board meeting and accepted. Starting December 2007, HttpComponents submits separate board reports as a TLP. By end of December 2007, HttpComponents is no longer using Jakarta resources. Mailing lists, SVN, website, dist, and archive have been moved. The HttpComponents Wiki still has Jakarta in it's name, but it is a separate Wiki. JCS No developer activity going on at this moment, though there is user activity on the dev and user lists. JMeter JMeter released 2.3 and 2.3.1 final. ORO Since the mature nature hardly any activity (it is maintained). There are still a lot of users and bug reports are actively monitored and acted upon. Since the library nature of the subproject it is definitely worth investigating if Apache Commons can be the new home for this library. Regexp See ORO. Slide Due to the lack of a developer community, Slide has been retired on 03/Nov/2007. It is thus no longer actively maintained or supported by the ASF. Subversion, Bugzilla, and one of the mailing lists will remain open for a transition period. Slide users will be pointed to Apache Jackrabbit as a replacement. Every few weeks, somebody inquires about a separate WebDAV client project on a mailing list of Slide, Jackrabbit, Commons, or HttpComponents. There are some people, some of which are Apache committers, who expressed some interest to put in some time, if others are with them. But nobody seems to want to take the lead and request a sandbox or lab project in which to start. The presence of two separate codebases (Jackrabbit, Slide) from which one could start doesn't help. Jackrabbit is alive, Slide is used in the wild. Taglibs Development is still taking place, although not at a high priority. Bug fixing took place on the Standard Taglib and there is the intention to make a final release after all bugfixing is done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta at the center of the (ASF) universe
Jukka is not subsribed, but the reason there are 5 is to kind of limit the size of the image (1 results in a huge image) Mvgr, Martin Nathan Bubna wrote: On Nov 18, 2007 1:14 PM, Nathan Bubna [EMAIL PROTECTED] wrote: On Nov 18, 2007 1:10 PM, Jim Jagielski [EMAIL PROTECTED] wrote: On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote: But that's the fact - that most of JavaLand sprang from jakarta... Jukka's graph shows committer cross-polination, not *codebase* cross-polination (as I understand it)... then you'd expect Harmony and Geronimo would connect with Velocity via Geir... i'm not sure what cross-pollination this graph refers to. Jukka, could you clarify? ah. i RTFA. a connection requires 5 committers in common. i'd be curious to see the graph with the threshold set to 3 (as that is more of a magic number in Apache community stuff). :) So yes, since most committers for most ASF java projects were in Jakarta (since those projects were *in* Jakarta, after all), I still think that the non-Jakarta page provides a more accurate representation of the real dynamics, by removing the artifical aspects of Jakarta. Of course, I could be wrong :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams - 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]
Who's coming to Apachecon..
Hi everyone, Since I suffered / suffering from a serious lack of time the last couple of months (sorry about that), I have in mind of doing some catching up at Apachecon :) So it would be nice to meet up with everyone and have a discussion about things todo, timelines, etc :) I will arrive Thursday afternoon.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External plugin repository for JMeter?
Mojo plugins start out in the sandbox and need 3 votes from current committers to promote to proper. If you want to release a vote is expected to happen (I think apache voting rules apply) Mvgr, Martin Roland Weber wrote: Hi Sebastian, sebb wrote: I don't see it as splitting the community, rather as an adjunct to the existing community. One of the reasons would be to allow independent release cycles. Also, not every user would need all the plugins. Perhaps this could be done by rearranging the JMeter project, but it seems cleaner to have a separate repository - as is done with Maven. HttpComponents is also managing currently two components on separate release cycles. However, that comes with a certain overhead. At the current frequency of our releases, I can fully understand Oleg's reluctance against putting more modules on separate release cycles. If the idea is to have each extra JMeter plugin on a separate release cycle, you're probably better off without the Apache overhead. I assume Codehouse does not require three PMC votes for a release? If the extra JMeter plugins are meant to share on release cycle, and there are no licensing issues, I believe it can be handled at Apache. cheers, Roland - 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: Commons is TLP
The commons one is probably less straight forward, although could be a lot easier. Since there was a commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc already there), besides setting up the karma for the people, moving over the website, etc,etc.. So probably best to figure out on infrastructure how to approach this specific situation. Mvgr, Martin Torsten Curdt wrote: On 21.06.2007, at 00:57, Martin van den Bemt wrote: Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. ...so where do we start with the TLP move is the question :) cheers -- Torsten - 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: Commons is TLP
+1 to keep httpclient and move it to httpcomponents. Mvgr, Martin Roland Weber wrote: Martin van den Bemt wrote: The commons one is probably less straight forward, although could be a lot easier. Since there was a commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc already there), besides setting up the karma for the people, moving over the website, etc,etc.. So probably best to figure out on infrastructure how to approach this specific situation. This also raises the question how the HttpClient 3.x code should be managed. Path-wise it is part of commons in SVN: /jakarta/commons/proper/httpclient but it is maintained by HttpComponents which doesn't move to the Commons TLP. If it isn't too much effort for infra, I would suggest to keep that part of the tree under Jakarta karma control. Either in place, or by moving it to the HttpComponents part of the repository, for example as /jakarta/httpcomponents/oachttpclient or /jakarta/httpcomponents/httpclient3x cheers, Roland - 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]
Commons is TLP
Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Board Report
I've added it to the report.. Mvgr, Martin Rony G. Flatscher (Apache) wrote: ... snip ... BSF MvdB :Silent quarter. A talk for Apachecon US was accepted (Rony Flatcher), which will hopefully increase the user base (observation : since the user list is also pretty quiet it can mean that BSF is bug free or it needs more users) ... snip ... Sorry, oversaw that the release of beta 1 of BSF 3.0 fell into the second quarter (ant was able to report the result of the vote on 2007-04-16) and should have been reported as such by us! This is the version that brings JSR-223 (a.k.a. Java 6 scripting framework) to the Apache table: it allows de/employing the Java scripting framework starting with Java 1.4 (the Sun implementation is only available starting with Java 1.6/6, foregoing the entire pre-Java-6 installed base). ant has been trying to get word on receiving the appropriate Sun TCK from Geir, but so far no news can be reported here ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Board Report
== June 2007 Jakarta Board Report == === Status === Another 2 projects have left Jakarta to live on their own : POI and Turbine and both of almost (or completely) finished the move. I like to wish the projects the best and a very good and long lasting future. In a seperate mail there is a TLP proposal for commons, which on acceptance will mean that the biggest part of the Jakarta community have no direct ties anymore with Jakarta. The focus after commons will be on the projects left at Jakarta and see if there is possibility for them to go TLP or when that is not viable or possible, find a suitable solution for those projects. My explicit wish is that there will be no deadline for projects to move so there will be enough time to find the best solution, instead of the quickest solution. We owe that to all the people in those projects who invest a lot of time and energy in those projects. One of the big discussions that took place was about the future of Jakarta and the thing we in majority agreed on (at least the people who spoke up) is that it is worth to save the Jakarta brand. Since I prefer to spend the energy and time I have in the projects that are left at Jakarta, I decided not to invest time on what will happen to the Jakarta brand at this time, simply because they deserve my time and energy and out of respect for the projects that still currently have their existance at Jakarta. If the board decides to not esablish the commons TLP, we need to go back to the drawing table. All in all : a lot is happening and a lot is going to happen in the months to come. If there is reason to do so, I will provide extra board reports besides the quarterly schedule. Reports prefixed with MvdB are written by me. === Releases === * 30 March 2007 - !HttpComponents !HttpCore 4.0 alpha 4 released * 4 April 2007 - Commons DBCP 1.2.2 * 8 April 2007 - Commons Configuration 1.4 * 18 May 2007 - POI 3.0 Final released * 6 June 2007 - JCS 1.3 released === Community changes === New committers, pmc persons, asf members and departures. * New Committers * Ben Speakmon was voted in as a Commons Committer * Alf Hogemark was voted in as a JMeter Committer * Asankha C. Perera was voted in as a !HttpComponents Committer * M. Johnson (although not new, his account was created just now, because of CLA problems). (POI) * PMC Members * Thomas Vandahl was voted on to the PMC * Danny Angus was persuaded to come back on the PMC. * Ant Elder was voted on the PMC. Fixed the bookkeeping on the addition of Nick Burch to the Jakarta PMC (that was reported in the December 2006 report. === Infrastructure news === The only things currently happening is the move of infrastructure for the Turbine and POI TLP projects. === General project news === The Jakarta PMC has started to review all Jakarta projects whether they contain or rely on cryptographic software and if they must be marked as described on http://apache.org/dev/crypto. This is an ongoing process and we expect some corner cases where we will need legal advice. === Subproject news === BCEL No activity. BSF MvdB :Silent quarter. A talk for Apachecon US was accepted (Rony Flatcher), which will hopefully increase the user base (observation : since the user list is also pretty quiet it can mean that BSF is bug free or it needs more users) Cactus MvdB: The ip clearance finally passed, so Petar is now able to (re)integrate his code into the cactus codebase. Commons A commons TLP resolution was sent to the Board at the same time of this board report. 31 March 2007 - vote passed to promote the JCI (Java Compiler Interface) to a proper component (from the Sandbox). ''Chain'' * Ready for a 1.2 bugfix release. ''CLI'' * Gearing up for a 1.1 release. ''Configuration'' * 8 April 2007 - Configuration 1.4 released ''DBCP'' * 1 April 2007 DBCP 1.2.2 released ''IO'' * Gearing up for a 1.3.2 bugfix release. ''JCI'' * Gearing up for a first 1.0 release. ''JXPath'' * Gearing up for a 1.3 release. ''Logging'' * Needs someone to do a 1.1.1 bugfix release. ''Math'' * Gearing up for a 1.2 release. ''SCXML'' * Working towards a 0.7 release. ECS Nothing happened on the ECS front. HttpComponents Work on the first alpha of !HttpClient 4.0 has made good progress. We expect to release client-alpha1 and the matching core-alpha5 shortly. There is currently no release manager for a potential !HttpClient 3.1 final release. Since the RC1 was released only in March, this is not an immediate problem. Bug reports are still dripping in, and bugs keep getting fixed. But we'll need to find a volunteer eventually. Various options to spin off !HttpComponents from Jakarta are being discussed. This could improve the focus of the active members of the !HttpComponents (sub-)community. JCS JCS 1.3 has been released. Thomas Vandahl acted as the release
Re: Commons TLP for Board Meeting ?
Cool I'll send it in this weekend.. And indeed adding people to the PMC will not be a problem afterwards. So no worries from my side that people are going to miss the boat.. Mvgr, Martin Henri Yandell wrote: On 6/11/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi everyone, The board meeting is the 20th, so it would be nice if we can add the commons TLP proposal for that meeting. So we probably need to finalize the proposal and send it off during the weekend. I think the majority opinion was to send the proposal as is. The only problem I can think of is that there were people who said they'd not put their names on there. Not that it'll be hard to add them on to the PMC later. 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]
Commons TLP for Board Meeting ?
Hi everyone, The board meeting is the 20th, so it would be nice if we can add the commons TLP proposal for that meeting. So we probably need to finalize the proposal and send it off during the weekend. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta site directory no longer contains .svn directories
Good one :) Didn't fix Velocity yet (better to put that in the root .htaccess and get rid of subdirs) So Turbine can be redirected too ? Mvgr, Martin Henning Schmiedehausen wrote: Once, the sites are up, feel free to copy /www/jakarta.apache.org/velocity/.htaccess and /www/velocity.apache.org/moving.html Best regards Henning On Thu, 2007-06-07 at 22:24 +0200, Martin van den Bemt wrote: Thanx for clearing it up, I was starting to doubt myself, since I did some cleanup of old Jakarta projects a couple of days ago (no worries, didn't touch POI and Turbine yet !) Mvgr, Martin Thomas Vandahl wrote: sebb wrote: Thanks; that's also fixed the missing updates. I wonder how it happened? That was me. I could have *sworn* that I copied these over by accident and as busy to remove them as fast as possible. Is this procedure svn update - edit - ant - svn commit - svn update site documented somewhere? I've never seen anything like this. Bye, Thomas. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta site directory no longer contains .svn directories
Coolio I will keep my hands of Turbine then.. Could you send a message to the private list when the move is complete ? Mvgr, Martin Scott Eade wrote: I set Turbine to redirect yesterday. I will delete the turbine directory once I am happy that everything is okay with the new Turbine TLP site. We still have Turbine on the Jakarta downloads page - we will sort this out when we have the Turbine download page working. In summary: We are taking care of Turbine as part of the TLP move and will tidy up after ourselves towards the end of this process. Thanks, Scott Martin van den Bemt wrote: Good one :) Didn't fix Velocity yet (better to put that in the root .htaccess and get rid of subdirs) So Turbine can be redirected too ? Mvgr, Martin Henning Schmiedehausen wrote: Once, the sites are up, feel free to copy /www/jakarta.apache.org/velocity/.htaccess and /www/velocity.apache.org/moving.html Best regards Henning On Thu, 2007-06-07 at 22:24 +0200, Martin van den Bemt wrote: Thanx for clearing it up, I was starting to doubt myself, since I did some cleanup of old Jakarta projects a couple of days ago (no worries, didn't touch POI and Turbine yet !) Mvgr, Martin Thomas Vandahl wrote: sebb wrote: Thanks; that's also fixed the missing updates. I wonder how it happened? That was me. I could have *sworn* that I copied these over by accident and as busy to remove them as fast as possible. Is this procedure svn update - edit - ant - svn commit - svn update site documented somewhere? I've never seen anything like this. Bye, Thomas. - 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] - 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 site directory no longer contains .svn directories
I've fixed it.. Old dir structure under site3. (just moved the old site directory to site3 and run svn update from the /www/jakarta.apache.org directory) Mvgr, Martin Scott Eade wrote: sebb wrote: Not sure what's happened, but the .svn directories seem to have disappeared from the directory tree: /www/jakarta.apache.org/site It means that svn update site no longer works... What would the fix be - to check out the site again? Scott - 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 site directory no longer contains .svn directories
Weird script when the result was that there was still the directory /www/jakarta.apache.org/.svn present. Very curious when httpd is going to use maven for their site :) Mvgr, Martin Henning Schmiedehausen wrote: probably a find /www -name .svn -type d | xargs rm -rf ## we do not need these directories, all sites are built and deployed by maven anyway. :-) Best regards Henning On Thu, 2007-06-07 at 10:32 +0100, sebb wrote: Thanks; that's also fixed the missing updates. I wonder how it happened? S/ On 07/06/07, Martin van den Bemt [EMAIL PROTECTED] wrote: I've fixed it.. Old dir structure under site3. (just moved the old site directory to site3 and run svn update from the /www/jakarta.apache.org directory) Mvgr, Martin Scott Eade wrote: sebb wrote: Not sure what's happened, but the .svn directories seem to have disappeared from the directory tree: /www/jakarta.apache.org/site It means that svn update site no longer works... What would the fix be - to check out the site again? Scott - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta site directory no longer contains .svn directories
Thanx for clearing it up, I was starting to doubt myself, since I did some cleanup of old Jakarta projects a couple of days ago (no worries, didn't touch POI and Turbine yet !) Mvgr, Martin Thomas Vandahl wrote: sebb wrote: Thanks; that's also fixed the missing updates. I wonder how it happened? That was me. I could have *sworn* that I copied these over by accident and as busy to remove them as fast as possible. Is this procedure svn update - edit - ant - svn commit - svn update site documented somewhere? I've never seen anything like this. Bye, Thomas. - 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]
Board report time..
Hi everyone, The board meeting is going to be on the 20th (2 weeks from now). So it's now time to add stuff to the http://wiki.apache.org/jakarta/JakartaBoardReport-current page :) And maybe get the Commons TLP proposal out the door :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JCS 1.3
If you vote again your vote is binding too :) Mvgr, Martin Thomas Vandahl wrote: Hi Sebastian, sebb wrote: However: http://apache.org/dev/apply-license.html says much the same, and seems to be policy. As you can see from the SVN tag JCS_1_3 and the artifacts at my site, your concerns have been addressed and the license files have been fixed. I would like to ask you to be so kind as to re-vote on the subject, based on the new status. Regards, Thomas. - 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: Result: [VOTE] Release JCS 1.3
Rony is a PMC member.. However the -1 of Sebb (which is binding and blocking) is still there (unless I missed his +1).. Added Rony to the jakarta-pmc authorization file (thanx for spotting this).. Mvgr, Martin Thomas Vandahl wrote: Hi Roland, Roland Weber wrote: Hi Thomas, I could not find any information about whether Rony Flatscher is a member of the PMC In the committers-only SVN module is a file board/committee-info.txt which lists the PMCs of all Apache projects. It's (supposed to be ;-) the authoritative source. Rony Flatscher is listed there as PMC member. I came across some commit message regarding asf-authorization which contained a list of members of the jakarta-pmc group and he was not listed there. So I was unsure. I'm not sure myself how Sebastian's -1 will be weighed here. I would have expected that the NOTICE and LICENSE files get fixed and he changes his vote. As by his last mail on the topic, the content in SVN did not get fixed. If you changed the release files manually, you should commit those changes to SVN and give Sebastian some time to change his vote. We were voting on the artifacts on people.apache.org/~tv/jcs/, not on SVN. This is at least what I understood the release-then-vote-policy means. I have committed the latest changes and moved the tag, however. If Rony is a PMC member we have a result of 3 +1 votes, which should be sufficient. However its up to the PMC to decide this. Bye, Thomas. - 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: Result: [VOTE] Release JCS 1.3
Agreed. though that page probably needs a bit of a reality check.. The problem is when someone does a -1 with reasoning, people tend to stop voting until that vote is switched to a +1 and if that vote is switched to a +1 and there are enough votes, people that stopped voting will keep silent. Hope I make sense :) Mvgr, Martin Will Glass-Husain wrote: Martin, Actually, that's not true. Releases cannot be vetoed by a -1. See http://www.apache.org/foundation/voting.html If there's a majority approval and at least 3 +1 PMC votes, than it's up to the release manager to decide whether or not to release. He can decide to table the vote based on feedback, if so desired. (We had this issue in the release of Velocity 1.5). WILL On 6/3/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Rony is a PMC member.. However the -1 of Sebb (which is binding and blocking) is still there (unless I missed his +1).. Added Rony to the jakarta-pmc authorization file (thanx for spotting this).. Mvgr, Martin Thomas Vandahl wrote: Hi Roland, Roland Weber wrote: Hi Thomas, I could not find any information about whether Rony Flatscher is a member of the PMC In the committers-only SVN module is a file board/committee-info.txt which lists the PMCs of all Apache projects. It's (supposed to be ;-) the authoritative source. Rony Flatscher is listed there as PMC member. I came across some commit message regarding asf-authorization which contained a list of members of the jakarta-pmc group and he was not listed there. So I was unsure. I'm not sure myself how Sebastian's -1 will be weighed here. I would have expected that the NOTICE and LICENSE files get fixed and he changes his vote. As by his last mail on the topic, the content in SVN did not get fixed. If you changed the release files manually, you should commit those changes to SVN and give Sebastian some time to change his vote. We were voting on the artifacts on people.apache.org/~tv/jcs/, not on SVN. This is at least what I understood the release-then-vote-policy means. I have committed the latest changes and moved the tag, however. If Rony is a PMC member we have a result of 3 +1 votes, which should be sufficient. However its up to the PMC to decide this. Bye, Thomas. - 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: [VOTE] Release JCS 1.3
Full license text should go in LICENSE and attributions and notices in NOTICE.. Mvgr, Martin Henning Schmiedehausen wrote: Well, I understand it differently and Thomas (probably looking at other projects) did this too: - LICENSE.txt contains the terms under which the software is licensed. This is Apache License 2.0 - NOTICE contains attributions to included code and the licenses that it is included under. Some projects choose to reference foo.LICENSE files for foo. Some choose to put the appropriate licensess into the NOTICE file. Yet others put these (third party) licenses into the LICENSE file. All of the above are ok IMHO. I personally have a preference for the first variant. httpd uses the second. I think FOP uses the third. Best regards Henning On Mon, 2007-05-28 at 15:24 -0700, Henri Yandell wrote: On 5/27/07, sebb [EMAIL PROTECTED] wrote: On 27/05/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: The license under which the code gets licensed to our end users is in LICENSE.txt. Copyright notices and optional third-party licenses under which the code got licensed to us is in NOTICE. Are you sure? That does not seem to agree with the sample NOTICE file: http://www.apache.org/licenses/example-NOTICE.txt Nor does it seem to agree with the way that httpd use the NOTICE and LICENSE files: http://svn.apache.org/viewvc/httpd/httpd/trunk/ As I understand it, the NOTICE file is for attributions. The LICENSE file is for licenses. These may either be included inline, or in separate files referenced from the main LICENSE file. That's how I understand it too. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
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 I voted +1, unless the goal is that commons becomes Jakarta in the end.. (then I want commons to stay) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse Commons to try and save Jakarta. If the Jakarta name is worth saving, people and community will form to save it. If not, then it will die. Thats normal and natural. Maybe not a reference to me, but in case it is, a reaction is probably needed. I am not abusing commons to save Jakarta. I just don't want commons to claim the Jakarta name when it leaves, since that would be abusing the other projects still present at Jakarta. That's what my notes are about : if the commons goal is to become Jakarta, you shouldn't leave. (not saying that this is what you wanted, just my observation from the threads going on) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
My silence is because I think I made my preferred option quite clear way too many times. Mvgr, Martin Danny Angus wrote: On 5/21/07, J Aaron Farr [EMAIL PROTECTED] wrote: This thread has been more quiet than I expected. Actually, thinking about it, perhaps that's because we all think we know where this is inevitably going and we're just waiting for it all to settle out. d. - 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: [PROPOSAL] The future of Jakarta
Ted Husted wrote: Worse case, the Commons group could always go with Apache Jakarta Commons. No one has objected to the re-use of the word Jakarta, and more than one person has affirmed that it could be used. That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed objections (you even responded to those objections) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
Danny Angus wrote: On 5/21/07, Ted Husted [EMAIL PROTECTED] wrote: On 5/21/07, Danny Angus [EMAIL PROTECTED] wrote: Ok Ownership is perhaps the wrong word, if Jakarta is being disbanded who provides the oversight? The same people who provide oversight for any ASF project: The people doing the work. If anyone wants Jakarta to be the ASF portal to all of our Java assets, then make it so. A commit is the only vote that counts. Yes, OK, and that's what I'm trying to find out. Does anyone? or is it just me? It's not just you :) It's just too early to do that at this stage, since if it is just some commits as Teds says, it will be a dead horse. I don't need something formal or something, but at least get some attention from the java projects out there if they are willing to help out and also have some collaboration with David Reid / projects.a.o. It's not worth it if the Apache java projects don't like the idea and help out at least with their project. (not suggesting you are of a different opinion though Danny) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
Yep still feel that way. Projects that want to use the Jakarta name, should just stay here till they are the only one left and after that re-establish the Jakarta Project. Mvgr, Martin Ted Husted wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed objections (you even responded to those objections) Yes, I looked back over the thread, and I stand corrected. You did say that the use of the Jakarta name in another TLP seemed premature. Do you still feel that way? -Ted. - 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: [PROPOSAL] The future of Jakarta
Ted Husted wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's not just you :) It's just too early to do that at this stage, since if it is just some commits as Teds says, it will be a dead horse. I don't need something formal or something, but at least get some attention from the java projects out there if they are willing to help out and also have some collaboration with David Reid / projects.a.o. It's not worth it if the Apache java projects don't like the idea and help out at least with their project. (not suggesting you are of a different opinion though Danny) Then take it to the next stage. Update the Jakarta home page to include links to our other Java products that were never part of Jakarta, like iBATIS, and invite all ASF Java products to use our news feed. Open the door, and see if anyone walks in. I am on a different schedule, volunteering on my own terms. In my view doing this now is *way* too premature. I currently only want to invest my time and energy on Jakarta and it's current projects. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
One link to a separate page isn't a problem, since I prefer that no major changes happen to the main site at this stage. Currently I am pretty much dedicated in keeping Jakarta as a brand. And when that time comes to worry about that, I'll work with the people who still have the itch and the cycles to spare. Starting to make it happen now feels like a waste of time, since the future of Jakarta is by no way set at this moment. Mvgr, Martin Ted Husted wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Then take it to the next stage. Update the Jakarta home page to include links to our other Java products that were never part of Jakarta, like iBATIS, and invite all ASF Java products to use our news feed. Open the door, and see if anyone walks in. I am on a different schedule, volunteering on my own terms. In my view doing this now is *way* too premature. I currently only want to invest my time and energy on Jakarta and it's current projects. That's fair. Every volunteer should scratch their own itch :) If other volunteers were ready to explore this course of action now, would you object to someone creating a [EMAIL PROTECTED] portal here by extending the Jakarta home page? -Ted. - 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: [PROPOSAL] The future of Jakarta
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.. Mvgr, Martin Ted Husted wrote: What if the proposal were to create the TLP for the purpose of reporting directly to the board, but nothing else changed? Would the project name Apache Jakarta Commons still be a problem for you if the physical infrastructure remained here, under the Jakarta hostname? -Ted. On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Yep still feel that way. Projects that want to use the Jakarta name, should just stay here till they are the only one left and after that re-establish the Jakarta Project. Mvgr, Martin Ted Husted wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed objections (you even responded to those objections) Yes, I looked back over the thread, and I stand corrected. You did say that the use of the Jakarta name in another TLP seemed premature. Do you still feel that way? -Ted. - 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: [PROPOSAL] The future of Jakarta
Flattened means : jakarta.apache.org/commons becomes jakarta.apache.org :) Mvgr, Martin Ted Husted wrote: On 5/21/07, Ted Husted [EMAIL PROTECTED] wrote: On 5/21/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.. Actually, it might be helpful if you repeated yourself in full, to be sure we're not talking past each other. For example, I don't know what flattened means. -Ted. - 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: [PROPOSAL] The future of Jakarta
Ted Husted wrote: On 5/21/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.. Then why the concern about the use of Apache Jakarta Commons as a project name? When the time comes, we could just point jakarta.apache.org at commons.apache.org/jakarta. I am highly opposed to that because of the following reasons : - If commons wants to be Jakarta they just should work *here* to achieve that. - If commons is leaving to come back, they are just ignoring the other projects that are still here. - It is solving the problem the wrong way - The biggest (developer) community is in commons. We need them to still care and think about the rest of Jakarta. It's just like leaving your parent's home to live on your own to run away from your siblings and then try to move back in when the siblings left the parental home. Big chance your parents will not let you do that. Going to bed now.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
If moving commons TLP is just a twisted (maybe a bad choice of a word) way to come back to jakarta.apache.org in the end, I am -1 on the TLP move.. We currently have 2 projects moving TLP (Turbine and POI) and after that we need to start thinking about every other project at Jakarta. So if the goals is to make commons Jakarta, we should aim for that, instead of artificially trying to accomplish that. If I am not mistaken the real goals/questions are : - Fix oversight issues - Be more transparent for the board - Move towards a community with the same focus (= eg reusable java components) - Be able to say in one sentence what Jakarta is about (is consequence of above) - See where we can fit project that are in maintenance mode or not actively supported anymore. - How to handle projects that don't fit well within the new focus, but work pretty well as part of Jakarta (are people waiting for being on eg 15 PMC's to be able to support these projects) - And Apache wide : is there only a place for projects that have a healthy community ? Mvgr, Martin Danny Angus wrote: On 5/14/07, Henri Yandell [EMAIL PROTECTED] wrote: As my random suggestion that Ted quoted points out, you can have a PMC without their having to be TLP. Least I was told that a couple of years ago either on board@ or face to face, so we could do the following: * Create the Jakarta Commons PMC, without changing the website (or even the svn maybe). * Continue to encourage Jakarta subprojects to move to TLP, go into maintenance or move over to other PMCs. * Reach a point at which we can end the Jakarta PMC, or federate or whatever. Do you mean that the resources can then be handed over to the Jakarta-commons (or whatever) PMC? I'm in favour of that idea, jakarta==jakarta-commons is the option which I think makes most sense of all for the future of Jakarta. 1/ it preserves a valuable brand 2/ commons embodies the original ethos of Jakarta 3/ commons (as we've seen hints of) still actively depends (c.f passively benefiting) upon the Jakarta brand. To close down the project and hand the brand to another PMC would also meet all but the most draconian interpretation of what the reorg@ discussions suggested needed to be done about the problem of Jakarta. d. - 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: [VOTE] Commons moving to TLP
Simon Kitching wrote: On Sun, 2007-05-13 at 01:06 +0200, Martin van den Bemt wrote: If the new TLP is java-only it seems very rude to take the name commons.apache.org : it's far too generic. Perhaps jakarta-commons.apache.org would be appropriate.. Leaving means not using the Jakarta name anymore. I don't see why. As a member of the Jakarta PMC I'm willing to allow jakarta-commons.apache.org to use our trademark :-) The problem is that you will be hijacking the Jakarta name and since the future of Jakarta (and usage of the name) is by no way set, using the Jakarta name in a new commons TLP is for me at this stage a premature call. But if that's so then perhaps jcommons.apache.org? Or commons4j.apache.org? (though that implies IBM to me...) Or coffee.apache.org :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
If the new TLP is java-only it seems very rude to take the name commons.apache.org : it's far too generic. Perhaps jakarta-commons.apache.org would be appropriate.. Leaving means not using the Jakarta name anymore. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
I am not a Jakarta commiter, and also vote is not binding, but I want to ask something. What are the benefits for commons of moving to a You are a Jakarta committer :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move POI to TLP
It helps if people who want to move with POI to TLP add their names to the proposal. Mvgr, Martin David Fisher wrote: I was thinking he was asking the same thing as you, but after composing an email like yours, I realized Shawn was asking if after going to TLP he would remain as a committer to POI. I am sure that the answer is yes all current POI committers remain POI committers. After going to TLP it will be easier for others to become POI committers because then it will the POI PMC votes that will bring them into the fold. If I am wrong then I hope someone with a better understanding will correct me. Regards, Dave On May 8, 2007, at 3:17 PM, Robert Burrell Donkin wrote: On Mon, 2007-05-07 at 15:36 -0500, Laubach, Shawn Contr 555 ACSS/GFLA1 wrote: So I can vote for this but then I'm not a committer anymore? Just curious. anyone can vote (and please feel free to do so). however only some votes are binding upon apache. in this case, it's Jakarta PMC votes. if POI graduates then only Apache POI PMC votes will be binding. - robert - 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]
TLP proposal Turbine POI for this board meeting and todo items.
Hi everyone, The 16th of May is the next board meeting, so I was wondering if you were all ready to go TLP at this stage or if you prefer to wait for next months board meeting ? Getting the approval done will not mean you have to move over everything immediately (we are still volunteers) and gives us a better time-line to help out with moving things over, set up redirects, etc.. There are a couple of things I like to see (re) checked : - Have all people added their name to the TLP proposal ? - Is the proposal setup according to https://svn.apache.org/repos/private/committers/board/templates/subproject-tlp-resolution.txt ? (this was just changed recently) If everything is ok, ping me, so I can add it to the boards agenda.. Please remember that everything that is added to the agenda needs to be 80 characters on a line :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move POI to TLP
+1.. Mvgr, Martin Nick Burch wrote: Hi All After lots of discussion within POI, and Jakarta in general, we think POI is ready to graduate to its own TLP. Thanks to the magic of ApacheCon, lots of people have been on-hand to help finalise the proposal for this, which is attached below. So, now is the time to vote on the proposal: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Cheers Nick WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the continued implementation of the library for manipulating files in various business formats currently known as Apache POI for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache POI Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache POI Project be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software and documentation related to the POI library based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, POI be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache POI Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache POI Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the POI PMC: * Nick Burch [EMAIL PROTECTED] * Amol S. Deshmukh [EMAIL PROTECTED] * Jason Height [EMAIL PROTECTED] * Marc Johnson [EMAIL PROTECTED] * Rainer Klute [EMAIL PROTECTED] * Yegor Kozlov [EMAIL PROTECTED] * Danny Muid [EMAIL PROTECTED] * Andrew C. Oliver [EMAIL PROTECTED] * Avik Sengupta [EMAIL PROTECTED] * Glen Stampoultzis [EMAIL PROTECTED] * Sean Sullivan [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nick Burch be appointed to the office of Vice President, POI, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that all responsibility pertaining to the Apache POI sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. - 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 BOF at 9 PM
This was yesterday evening at Apachecon Amsterdam.. We had a nice dinner and Niall really showed his excellence in speaking French :) Mvgr, Martin Jean Carlo Salas wrote: what? On 5/2/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Jakarta BOF is scheduled at 9 PM right after the Incubator BOF. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta BOF at 9 PM
Jakarta BOF is scheduled at 9 PM right after the Incubator BOF. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Turbine to TLP
+1... Mvgr, Martin Scott Eade wrote: The Turbine project has been discussing a proposal to the board that the Turbine projects leave the Jakarta umbrella and become their own top level project. We are now at the point in the process that calls for a vote to take place. The proposal is available at: http://wiki.apache.org/jakarta-turbine/TLPTurbine For the interested, most of the discussion took place in the following thread: http://www.nabble.com/-DISCUSS--TLP--tf3574436.html Here are the vote options: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Thanks, Scott - 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]
Apachecon Jakarta talks in fast feather tracks.
Hi everyone, If someone wants to give a talk about a Jakarta project, there is an option of doing that during the feather tracks on Friday. So if you think you have something useful to say about a Jakarta project, please let me know (reply to general is ok). Even if it's just a single commons component, it's ok and I'll take it back to the Apacechon planners to see if we can schedule the talks. (If you don't have a presentation yet, don't worry, just let me know if you want to give a talk). Nice candidates would be eg Turbine (lot of Turbine related people are coming), Robert with a talk about RAT, etc, etc ;) If you don't want to give a talk, but like to have someone else (co) present it, I am willing to help out .. Don't have an idea yet what the max time for a talk is (although if you talk fast, you can give a 5 hour presentation in 1 hour ahum) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta - Internal project health audit..
Hi everyone, A lot of things happening at Jakarta atm and even though I have some views on where Jakarta could end up, things are in no way set. On thing that I think needs to be done is to establish what the health of your project is. Which means you have to look internal. Things to consider : 1) Number of *active* committers 2) Do the active committers have a binding vote. 3) Is your project able to do a release with just the *active* people. 4) Are you investing time to *build* a developer community. 5) Is there any possibility that a community can be build at all? 1 2 and 3 can be solved by 4 :) 5 could make 4 impossible or useless. So please invest time in building a developer community so you are able to live on your own. Not saying everyone has to live on their own, but if you *can* you are healthy :) My feeling is that 4 is something we really need to work on and the only way to achieve that is doing it while the developer community is still active. Where I find the time, I will try to ping individual projects. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta BOF at Apachecon EU ?
I've planned a Jakarta BOF for Apachecon EU. Please increase the Interested People Counter on the http://wiki.apache.org/apachecon/BirdsOfaFeatherEu07 page if you ar einterested on having a BOF. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Board Report
March 2007 Jakarta Board Report Status Activity seems to pick in projects that haven't been so active, so that's really good news. Besides the releases and the code donation (see Cactus) and the releases, there is nothing in particular that needs board attention at this moment. On a side note : I really hope we can go back to the 3 month schedule again. If there is something out of the ordinary however, I will add an extra report. Releases * 13 February 2007 - Commons Fileupload 1.2 Released * 17 March 2007 - Commons HttpClient 3.1-rc1 Released * 18 March 2007 - Commons Transaction 1.2 Released * 18 March 2007 - Jakarta Regexp 1.5 released Community changes Ant Elder - Voted as a committer for the BSF. Stephen Kestle - Voted as a committer for Commons BSF Ant Elder - Voted as a committer for the BSF. Cactus Currently in the process of voting on a new committer (Petar Tahchiev). After this vote a vote will be started to finish the code donation by Petar, for more details of the code grant, please see http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html. Commons FileUpload The release 1.2 of Commons Fileupload 1.2 introduces a new streaming API, which allows to use the library with arbitrarily large files and an extremely low memory profile. POI Gearing up for a release of 3.0, which hopefully will be in a month or so's time. Regexp Released 1.5 version of Regexp which brings number of known issues down to 3. Dev and user lists are quiet. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Petar Tahchiev as Jakarta Committer
+1 I second Felipe's observations about Petar btw.. Mvgr, Martin Felipe Leme wrote: Hi all, I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer. Petar currently works as software engineer in Bulgaria, but was a MSc student last year, when we proposed porting the Cactus build to Maven 2 as a GSOC (Google Summer of Code) project. Although the project didn't make it to the allotted ASF projects, Petar kept doing the (hard) work, despite my slowness to support him. Prior to participate on Cactus development, he made some contributions to Apache Ant and other ASF projects. He also has a blog at java.net (http://weblogs.java.net/blog/paranoiabla/). A couple of months ago, I failed (again :-() to setup a sandbox SVN branch at ASF for him to continue his work, so he ended up creating a separated repository on SourceForge where we could do some work in parallel. Now that code is ready to come back to the Jakarta codebase, and the proper legal measures has already been taken (see http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html). Besides the technical aspect, I can tell from personal experience that he is a talented and enthusiastic developer, and will be a valuable contributor to the Cactus/Jakarta communities. So, here is my (PMC binding) +1 vote. -- Felipe - 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]
Last Call : Board report due..
Hi Everyone, The board report is due again (hopefully we can move back to a 3 month schedule for the next time). Please add anything noteworthy, like committer votes, releases (in the Release section + a bit more detailed transcipt of the release under your component) and other things you want to share. The current board report is *always* at http://wiki.apache.org/jakarta/JakartaBoardReport-current, so if there is anything happening of importance, you are kind of expected to add information to this page. I will send out the report at the latest on Sunday. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
Matt Benson wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] I didn't know whether this had been done before in Commons - but seems that it has for the Commons CSV component back in December 2005: http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html Actually I knew about this but thought I remembered someone (Henri?) saying later that having gotten the code in this way might not have been the best choice in retrospect. Does that ring any bells with anyone? Yep that rings a bell and going down that route again, is not something that has my support for *new* components (which this is). If the code is destined for an existing codebase, we could do the IP route, else I would like to see some level of incubation (besides handling ip). See the discussion on not-yet-commons ssl. On another note : If there will be no mentors for the project from Jakarta, I don't see a reason that Jakarta be the sponsor of the project. Not that this is a documented Incubator policy however, but since 1) we have a lot of people who are allowed to be a member and 2) the project should have active guidance from the community where it is destined to end up (esp important in a commons situation). I am planning to start a thread on these kind of situations on incubator general to gather thoughts. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
On another note : If there will be no mentors for the project from Jakarta, I don't see a reason that Jakarta be the sponsor of the project. Not that this is a documented Incubator policy however, but since 1) we have a lot of people who are allowed to be a member Replace member with mentor :) People who are allowed are normally members of the ASF. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
Niall Pemberton wrote: On 3/9/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Matt Benson wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] I didn't know whether this had been done before in Commons - but seems that it has for the Commons CSV component back in December 2005: http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html Actually I knew about this but thought I remembered someone (Henri?) saying later that having gotten the code in this way might not have been the best choice in retrospect. Does that ring any bells with anyone? Yep that rings a bell and going down that route again, is not something that has my support for *new* components (which this is). If the code is destined for an existing codebase, we could do the IP route, else I would like to see some level of incubation (besides handling ip). See the discussion on not-yet-commons ssl. I'm wondering why? Seems to me that this is a slightly different situation to either CSV or the SSL situations since one of the developers is an existing ASF and Commons committer. There are new committers involved. With CSV Henri is a committer (not talking karma here) (and me too, although we are both not very active). I think when new people are involved incubation (besides legal) should occur (even though the community import isn't that big, compared to similar situation like activemq, servicemix, etc, where the core developers are actually ASF Members) In case of this scenario (and ssl) I envision this for incubation : - Get the people on board as a committer on the initial proposal - Have them *show* that they are here to stay for an x amount of time - Ideally have the normal exit criteria, although I can imagine for commons a slightly weaker exit strategy may be adapted (don't think the incubator thinks that eg 3 committers on a project is a vibrant community, although within commons it definitely will be!). - Get a release out. If someone starts hacking on code in the sandbox I am ok with that, but rather not see new code again hitting the sandbox, since we don't accept new committers on sandbox components and it doesn't have the ability to have a release (disclaimer : I became committer in Jakarta because of a sandbox component, ahum). I highly prefer that incubating commons components to use the commons-dev and commons-user list, since to do development however, since it would be quite a cultural shock when moving from incubator specific lists to the commons ones. Disclaimer : this is just a brain dump and I would love to see some new projects at Jakarta, but I think we also need to figure out how we should handle that in a constructive way and prevent feedparser and csv situations. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Official Request For Moving Cactus In The Incubator
Hence the reason I wanted to wait for a response till I had more time (still busy).. My approach for you would have been : get a software grant, ccla and icla on file and start a vote on you being a committer for cactus, I just failed horribly to send out that mail (btw sending in those documents is what legal incubation is about). I will send you some links for this, if you didn't figure it out earlier or someone else beats me to it.. Since there is still enough interest in Cactus I think that new activity will be enough to get more people aboard and get the ball rolling again :) Mvgr, Martin Petar Tahchiev wrote: On 3/7/07, Martin van den Bemt [EMAIL PROTECTED] wrote: will come back to this on friday.. Mvgr, Martin Petar Tahchiev wrote: Hello guys, first of all let me introduce myself. My name is Petar Tahchiev and I am from Bulgaria. I wanted to enroll in the last-years Google Summer Of Code where I applied with the project of migrating the Cactus build system to Maven. Unfortunatelly me and Felipe Leme (my mentor), who I would like to thank once again for the encouragement and the help he provided me, weren't qualified. Later I had a few personal issues to solve, but the point is that I continued to work on my own and sooner I managed to migrate the Cactus project to be built with Maven. When everything was done I started submitting patches in the cactus jira, for some known bugs. The problem with the patch of the build system was that it turned out to be very large so I couldn't apply it in the jira. Then me and Felipe agreed that it would be better to move the cactus to a separate repository and test the build system there (you understand that the new build structure was absolutely different from the old one and merging was a kind of a tough task). So I got my work and imported it in my own repository at the sourceforge.netwhere we began testing. The point is that when we wanted to apply the changes in the cactus trunk in the Apache repository we were adviced by Martin van den Bemt that we have to ask that the project be moved in the incubator first and then when the code is appropriate for the cactus's trunk move it in the trunk. Now the process of moving Cactus in the incubator is stalled, as well as our work on it, because I want to move it in the incubator, before I continue making additional changes and implementing new features. So my request to you guys is this: if anyone can help us move the code in the incubator, he is more than wellcome. Thank you very much. P.S. You may find additional information of the whole process here: [1] http://www.mail-archive.com/cactus-dev@jakarta.apache.org/msg08579.html [2] http://www.nabble.com/Question-About-the-Current-State-Of -Cactus-In-the-Incubator-t361.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok, no problem. I know that you are busy, but I have another idea that came to me reading the Matt Benson's post. In fact the guys are dealing with a project that seems to be inspired the jakarta commons Convert project and so it would be possible to accept the code without passing through the incubator. So why isnt' this situation possible for Cactus (I mean I have refactored existing code and added the maven xml files - it is not a new project). I also agree that passing through the incubator is the best solution in the great majority of cases, but in my opinion there are still some cases (like Cactus for instance) that are threatened of stalling even more. P.S. Personaly for me, I am happy with both of the solutions - with or without the incubator. My desire is to start working on the project as soon as possible because we are planning of implementing some new features and then releasing a RC. Looking forward to your reply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Official Request For Moving Cactus In The Incubator
I know that you are busy, but I have another idea that came to me reading the Matt Benson's post. In fact the guys are dealing with a project that seems to be inspired the jakarta commons Convert project and so it would be possible to accept the code without passing through the incubator. So why isnt' this situation possible for Cactus (I mean I have refactored existing code and added the maven xml files - it is not a new project). I also agree that passing through the incubator is the best solution in the great majority of cases, but in my opinion there are still some cases (like Cactus for instance) that are threatened of stalling even more. Martin or others may answer this better - but AIUI one of the two primary goals of the incubator is building community around code bases. This is not just a nice thing at Apache - its an absolute necessity. As an example under Apache rules without 3 votes from the PMC (project management committee) responsible for a project you can't release anything. Once a project falls below that critical level of involved people its basically dead in the water as far as releasing any software goes. In the case of a project like Cactus the main reason for going back to the incubator would be to re-create a viable community. From what I understood from current people that have cactus on their radar and have sufficient power to vote, Cactus will be able to get a release out the door. An another note : After incubation it could still be that you cannot get a release out the door if you end up at Jakarta, depending on the fact if you actually make it on the Jakarta PMC. This is also one of the reasons an Incubator project should have 3 mentors, so they can actually release, without depending on the time of people not directly involved. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Official Request For Moving Cactus In The Incubator
All right, I get it now. Thank you Martin. Yes, It sounds now more reasonable to move in the incubator. Sorry you didn't get it :) (probably me though, mailing too much today). I was saying that I think Cactus can gather enough votes in the current situation for eg a release (so without a need to go through the incubator), so the Incubator path isn't needed (at least the way I look at it). Exception of course is the legal part :), besides that we are taling about an existing Jakarta codebase here. If people think the cactus should go back to the incubator, because of a lack of vibrant community and not being able to release, because of the 3 +1's, we probably shouldn't stop there , and start shipping other Jakarta (sub and subsub) projects to the incubator. In this case Felipe was keeping tabs on what you were doing (and if I understood correctly Felipe currently hasn't much time left to work on Cactus, but is still interested) and Kenney Westerhof also worked on a cactus plugin for maven2, so he could also be a candidate to become active on cactus.. So the path will probable be (got no objections on this when sending this to private) - Get your paperwork done (Code grant, icla, ccla) - Have a vote on cactus-dev / general to accept your codebase into Cactus - Do the incubator paperwork, start a vote there (based on lazy consensus, so if no one objects, the code is accepted) - Start a vote (on cactus-dev / general) to add you as a Jakarta committer. No difference in this scenario with Mantissa/Luc path (to give an example) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
I've already have a promise to help out Julius with incubation and am currently am mentor for Trinidad, so I don't think it is wise for me to add another effort to my list. Mvgr, Martin Matt Benson wrote: @Members: I have recently joined the development team of an OSS project, Morph, that captures the spirit of Jakarta commons-convert but where the convert project stagnated, Morph is a well-evolved, though still not 100% complete, library whose development I feel would benefit greatly from The Apache Way and would make a worthy ASF project. Object conversion seems to be a woefully under-served subject in the Java OSS space, despite the ubiquity of the need for it (however well-hidden it may tend to be) in enterprise Java development. I have contacted a few of you personally already, but having received no bites as yet I am widening my audience one last time before giving up on this. You can learn more about this library at: http://morph.sourceforge.net Thanks, Matt Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - 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: An Official Request For Moving Cactus In The Incubator
will come back to this on friday.. Mvgr, Martin Petar Tahchiev wrote: Hello guys, first of all let me introduce myself. My name is Petar Tahchiev and I am from Bulgaria. I wanted to enroll in the last-years Google Summer Of Code where I applied with the project of migrating the Cactus build system to Maven. Unfortunatelly me and Felipe Leme (my mentor), who I would like to thank once again for the encouragement and the help he provided me, weren't qualified. Later I had a few personal issues to solve, but the point is that I continued to work on my own and sooner I managed to migrate the Cactus project to be built with Maven. When everything was done I started submitting patches in the cactus jira, for some known bugs. The problem with the patch of the build system was that it turned out to be very large so I couldn't apply it in the jira. Then me and Felipe agreed that it would be better to move the cactus to a separate repository and test the build system there (you understand that the new build structure was absolutely different from the old one and merging was a kind of a tough task). So I got my work and imported it in my own repository at the sourceforge.netwhere we began testing. The point is that when we wanted to apply the changes in the cactus trunk in the Apache repository we were adviced by Martin van den Bemt that we have to ask that the project be moved in the incubator first and then when the code is appropriate for the cactus's trunk move it in the trunk. Now the process of moving Cactus in the incubator is stalled, as well as our work on it, because I want to move it in the incubator, before I continue making additional changes and implementing new features. So my request to you guys is this: if anyone can help us move the code in the incubator, he is more than wellcome. Thank you very much. P.S. You may find additional information of the whole process here: [1] http://www.mail-archive.com/cactus-dev@jakarta.apache.org/msg08579.html [2] http://www.nabble.com/Question-About-the-Current-State-Of -Cactus-In-the-Incubator-t361.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
It is short for the dutch Met vriendelijke groeten, which translates to english as With kind regards :) Mvgr, Martin Matt Benson wrote: Thanks for the reply, Martin. BTW, and not to derail my own topic, but what is Mvgr? :) -Matt --- Martin van den Bemt [EMAIL PROTECTED] wrote: I've already have a promise to help out Julius with incubation and am currently am mentor for Trinidad, so I don't think it is wise for me to add another effort to my list. Mvgr, Martin Matt Benson wrote: @Members: I have recently joined the development team of an OSS project, Morph, that captures the spirit of Jakarta commons-convert but where the convert project stagnated, Morph is a well-evolved, though still not 100% complete, library whose development I feel would benefit greatly from The Apache Way and would make a worthy ASF project. Object conversion seems to be a woefully under-served subject in the Java OSS space, despite the ubiquity of the need for it (however well-hidden it may tend to be) in enterprise Java development. I have contacted a few of you personally already, but having received no bites as yet I am widening my audience one last time before giving up on this. You can learn more about this library at: http://morph.sourceforge.net Thanks, Matt Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - 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] Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - 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: reinstatement
What exactly is the problem ? You have karma on Jakarta so you should be able to commit... Mvgr, Martin Michael Oliver wrote: Hi, I am a committer on the slide project and have been inactive for more than six months and access is denied. I now have several commits to make and need to be reinstated, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] is my account. Michael Oliver Cell: 518-378-6154 Skype: MikeOliverAZ Phone:702-866-9034 - 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: reinstatement
Send a request to infrastructure or root at apache dot org to have that done.. ( I don't have karma to do that) Mvgr, Martin Michael Oliver wrote: Perhaps then it is just password needing to be reset. Michael Oliver Cell: 518-378-6154 Skype: MikeOliverAZ Phone:702-866-9034 -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 6:23 AM To: Jakarta General List Subject: Re: reinstatement What exactly is the problem ? You have karma on Jakarta so you should be able to commit... Mvgr, Martin Michael Oliver wrote: Hi, I am a committer on the slide project and have been inactive for more than six months and access is denied. I now have several commits to make and need to be reinstated, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] is my account. Michael Oliver Cell: 518-378-6154 Skype: MikeOliverAZ Phone:702-866-9034 -- -- - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Create [EMAIL PROTECTED] mailinglist..
Hi everyone, For various reasons there are a couple of projects at Jakarta that currently don't have any development community. I like these projects to have dev discussion move to [EMAIL PROTECTED], so it is easier for us to give oversight and guide newbies to learn the Apache way. The initial projects I have in mind are : oro, regexp and ecs (others are welcome too btw). This idea sparked from 1) my thread about reviving inactive projects 2) the thread on ecs-user on who is still using ECS and looking at the content it could very well be that some people will start sending patches in the near future. The strength of this list should be is that with a lot of hands the chance that nothing happens when there is activity is minimized. If someone has an hour to spare, it could very well be useful to apply a patch and mentor people. I would kind of expect that every PMC member is also subscribed to this list (in the same way it is kind of expected that you are subscribed to general), but as always cannot force anyone ;) Since I don't like to extend the scope of the general list, I prefer dev discussion not to take place there. Thoughts ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote][conclusion] Re: [Vote] Where should not-yet-commons-ssl go?
Not a vote result, since it is just a conclusion from my side. Jakarta hat on Even though there are enough +1's to start sponsoring ssl, I think I want to see a lot more support than what I currently see (I mean active support). So at this stage I don't think it is wise that Jakarta should sponsor this project. Let's see where incubation takes ssl, without being destined for Jakarta and only decide if ssl requests to be part of Jakarta when it wants to or is ready to when it's time to leave the incubator. /Jakarta hat on Personal hat on Since there are more (Apache) projects interested in ssl, I think however we can get enough people on board to do a successful incubation, so I offered to Julius to help him out with incubation as the sponsor and the mentor. /Personal hat on If you strongly disagree with my conclusion, please step up to get actively involved, if not I will start working with Julius on a personal basis to get this baby going. Mvgr, Martin Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. - 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. - Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. - SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. - Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification! 5. KeyMaterial constructor blows up earlier. - If a JKS or PKCS12 file is provided that isn't going to work (e.g. no private keys), the KeyMaterial constructor throws an exception right away. 6. getSSLContext() now available to help inter-op with Java 5 SSL-NIO libraries. - Oleg has
Re: [vote][conclusion] Re: [Vote] Where should not-yet-commons-ssl go?
Martin van den Bemt wrote: Not a vote result, since it is just a conclusion from my side. Personal hat on Since there are more (Apache) projects interested in ssl, I think however we can get enough people on board to do a successful incubation, so I offered to Julius to help him out with incubation as the sponsor and the mentor. /Personal hat on Correction : the sponsor will be the incubator PMC in this scenario. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Create [EMAIL PROTECTED] mailinglist..
Andrew C. Oliver wrote: I think it is a bad idea. Either a project is alive or it is dead and most of the dead are not coming back. The site, the project and everything else should reflect this. I suggest that: 1. ECS 2. ORO 3. Regexp 4. Alexandria (already does basically) Was closed down about a year ago. all have a page that looks like this one: http://avalon.apache.org/closed.html Stating that the projects are dead and state what things have taken their place and provide links. There is no need for an artificial dev list or users list. Just close the lists. (If you disagree look at the list archive for each over the last 6 months and see if you REALLY disagree in more than THEORY). I know how the lists look like, I am subscribed to all Jakarta lists (bugzilla is the most active developer on these lists ;). These projects may be dead currently from a developer perspective (ignoring Daniels mail here for a moment), but hardly from a user perspective. And there is currently talk amongst users on eg ecs to potentially start activity. I like that to get more visibility and opportunity, which is now hidden in the ecs lists. Also I like the message on a website to contain something more than just the message this project is dead with some links. I rather state how people can get active on these projects again and I like to point them to a central dev list, instead a (potentially) forgotten dev list. When you want to close down the user list, should we point people to the general list for their support questions (which doesn't happen often, but it happens) ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Icons for Java application (JMeter)
Continuum has them.. See http://svn.apache.org/repos/asf/maven/continuum/continuum-1.0.1/continuum-web/src/main/resources/images/ Mvgr, Martin sebb wrote: I'm looking for some icons suitable for use in a Swing JTree - so they need to be GIF or PNG (I don't think SVG works). I need the following icons: Success - perhaps a tick? Failure- perhaps a cross? These are to be used on the tree entries to distinguish successful and unsuccessful samples. At present the label is coloured red for failures, but this is not much use for colour-blind users (or indeed B+W printing). There are lots of icon samples on the web, but I've not found one that is suitable. Perhaps someone knows of some suitable icons already used by Apache products? S/// - 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: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
Let's keep this statement your personal opinion on the fact that it is not relevant. I still like to know the opinion of others. If you want opinions, don't use a vote to collect them. This is a vote thread, not an opinion thread. Votes within the ASF are for decision making, not opinion polls. Jakarta is well known, in a negative way, for being overly vote-happy, so we should be doing our best to confine our use of voting to things that really need to be voted on. That includes neither opinion polls or consensus building. My statement was that the final destination of a project is not relevant for a vote on whether or not it should be accepted into the incubator. I consider that to be a simple fact about the way the incubator works, not an opinion. The difference of opinion here is that you see this as a vote about incubating ssl, which is simply not our call. We can vote however on accepting ssl into Jakarta, which has the consequence that Jakarta is going to be actively involved as a champion / sponsor role to have the Incubator accept ssl. Say if the target is commons, we probably should have commons-ssl end up in the website of commons, have Julius participate on the commons website, instead of having separate lists, separate website and a separate PPMC and learning the commons way is pretty hard when you are actually not integrated into the commons community to begin with. We are talking about around 20 classes here and 1 new committer (afaik). What makes this case special compared to eg webwork (came across this while wading through the incubator archives to find similar scenario's) ? Maybe it's just a different definition of the meaning of full incubation. Things I want see solved during incubation here is (assuming commons is the target) : - IP clearance (paperwork is done by the way) - It contains crypto, so we probably need some legal advice on this (currently a discussion on legal btw) - Making sure Julius is here to stay (so preventing a new dead commons project) - Getting enough support in commons, so it's not a one man project - Everything takes place on the commons mailinglists (user and dev) - Release votes needs to be the same as any other commons component, with the addition of an extra incubator vote. - Reuse of commons infrastructure, probably with the exception of svn (eg incubator svn and have separate permissions, with the whole of jakarta being able to work there) Thoughts welcome... Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [ ] Jakarta should sponsor (which effectively states we like to see the code end up here) [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) if accepted in Jakarta, it should end up in : [ ] commons as a component [ ] httpcomponents as a component [ ] subproject directly under Jakarta [ ] integrate / merge code into project xxx (please replace x) (so not a subcomponent of a project!) And [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF) [ ] I want to get involved in coding [ ] No interest in getting involved. Reasoning : 1) the first decides if Jakarta wants to sponsor this 2) we need to know the place it should end up in Jakarta (at least have some kind of direction) 3) if no one is interested in getting involved or being a mentor (preferably 3 mentors!), we can easily see if option 1 and 2 are viable at all. The problem with the current vote is that I have to start yet another vote to let us sponsor and where it should end up, best to do it in one go in my opninion... So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) Mvgr, Martin Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. - 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. - Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. - SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. - Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification! 5. KeyMaterial constructor blows up earlier.
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
Martin van den Bemt wrote: I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [X] Jakarta should sponsor (which effectively states we like to see the code end up here) [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) if accepted in Jakarta, it should end up in : [X] commons as a component [ ] httpcomponents as a component [ ] subproject directly under Jakarta [ ] integrate / merge code into project xxx (please replace x) (so not a subcomponent of a project!) And [X] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF) [ ] I want to get involved in coding [ ] No interest in getting involved. Reasoning : 1) the first decides if Jakarta wants to sponsor this 2) we need to know the place it should end up in Jakarta (at least have some kind of direction) 3) if no one is interested in getting involved or being a mentor (preferably 3 mentors!), we can easily see if option 1 and 2 are viable at all. The problem with the current vote is that I have to start yet another vote to let us sponsor and where it should end up, best to do it in one go in my opninion... So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) Mvgr, Martin Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. - 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. - Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. - SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. - Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification! 5. KeyMaterial constructor blows up earlier
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
Martin Cooper wrote: On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [ ] Jakarta should sponsor (which effectively states we like to see the code end up here) +1 [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) No, it means that it still needs to find a Sponsor before it can be accepted into incubation. It says nothing about where it will end up after incubation or even if it will start incubation. if accepted in Jakarta, it should end up in : This is not relevant. The final location of a project is not decided until it is ready to _exit_ incubation, so it's more than a little premature to be discussing this here. Let's keep this statement your personal opinion on the fact that it is not relevant. I still like to know the opinion of others. Main reason : it is very interesting to see to figure out what the exit criteria should be for a small component like ssl (besides the IP stuff). Would be nice to get Robert's view on this (I will start a discussion after the vote, so the vote doesn't get too polluted). Could be that I am the only one seeing the difference during incubation depending on the target within Jakarta, so if that's the case it's probably best for SSL that other people step up as mentors and champions. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta board Report February
I am actually maintaining that, although at a pace that makes you fall a sleep ;) Mvgr, Martin Niall Pemberton wrote: Previous Board reports have been archived here: http://jakarta.apache.org/site/pmc/board-reports.html Would be good to continue this IMO. Niall On 2/19/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Jakarta Board Report Status This board report was mainly constructed by other people than me, which is a big improvement (thanks everyone). I also moved the board report to a fixed location on the wiki (http://wiki.apache.org/jakarta/JakartaBoardReport-current), so it's easier to locate for people. The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). What is not completely clear for me at this point, is the board report schedule. An extra report was requested (lack of commons projects in the report). Reporting next month again will be a lot of work, since my goal is to report on every subproject (even if there is no or hardly any activity). Inactive projects Disclaimer : we have lot's of active projects ! Definition list : Inactive project = a project that has no *developer* community. The Apache Way : To become committer on a project you have to earn that right, you have to stand out, submit patches, show you care, learn the apache way and have to get noticed by the current committers who can nominate such a person. Problem : If that didn't happen enough in the past, it can happen that at a certain point no developer community is active anymore. Which causes : A catch22 situation. Since there is no developer community, no one is able to determine if people deserve to become a committer. Even if you are monitoring such a list (such as I do for all Jakarta lists), it is hard to determine if people deserve committership. Solution : The only thing we know for sure : inactive projects needs someone to mentor the project to become active again. This goes for all possible scenario's : 1. Actively support forks and when they show they are capable to work on the project, get the code back (needs mentoring, grants, etc) 2. More liberal in getting committers on board 3. Actively following the user / dev lists and issue trackers to see if there is someone ready for committer ship. (is the normal way, although the focus here is not if patches etc are technically correct) I like to prevent Jakarta becoming some kind of collection with inactive project, so the first goal is preventing that this scenario occurs on our current subprojects where possible. So I would like to ask the current active developers to invest a little bit more time in looking what others are doing. I think this discussion is also useful to have on the incubator list. Releases * 13 February 2007 Commons Lang 2.3 * 13 February 2007 Commons IO 1.3.1 * 30 January 2007 Commons IO 1.3 * 30 December 2006 Commons Betwixt 0.8 * 30 December 2006 Commons VFS 1.0 * 19 December 2006 Commons SCXML 0.6 Community changes New committers, pmc persons, asf members and departures. PMC Members * Yoav Shapira resigned from the PMC The following new commiters were voted in: * Yegor Kozlov (POI) * Luc Maisonobe (Commons Math) * Matt Benson (Commons JXPath) Infrastructure news Started to investigate the moderators we have and contacting all the moderators asking if they are still active. If there are gaps, I will try to fill the void by finding volunteers. This way we prevent that lists aren't moderated. Subproject news Sections with a prefix of MvdB are notes added by the chair BCEL MvdB : Some user questions, further no action taken on the future of BCEL (on the list is contacting the 2 currently exising forks out there, to see if there is interenst in moving development back to Jakarta. Afaik Findbugs and AspectJ have forks. BSF MvdB : They are currently planning for a 3.0 release and for jsr223 they are investigating to get the TCK. Geir is in the process of arranging things. Cactus MvdB : Cactus development was stalled and recently Petar Tahchiev sent a mail to the list, saying he had continued development of cactus on https://mamouth.svn.sourceforge.net/svnroot/mamouth. I (=Martin van den Bemt) am currently in the process of informing Petar on what actions to take (eg Code Grants/CLA/CCLA) to move development back to the cactus project. When the paperwork is there, we will run the code base through the incubator (at a minimum legal). Commons Switching from Maven-1 to Maven-2 gets closer - we can now build the website from Maven-2. Next we need to look at how we would do a release under Maven-2 and whether it passes our requirements. Key: * Inactive
Re: [Jakarta Wiki] Update of JakartaBoardReport-current by RolandWeber
I've added it to the board template :)
Mvgr,
Martin
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta Wiki for
change notification.
The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta/JakartaBoardReport-current
The comment on the change is:
Martin, you might want to update your template
--
''!FileUpload''
- ''!HttpClient''
-
''IO''
''Jelly''
@@ -105, +103 @@
ECS
HttpComponents
+ ''including !HttpClient''
JCD
-
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]
Last call for board report additions!
Last call for board report additions, I will post it on Sunday.. The current board report in progress will always be at http://wiki.apache.org/jakarta/JakartaBoardReport-current Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site update
Hi everyone, I updated the site to have a link to apachecon amsterdam and messed up the style of the site :(. By accident I committed a local change that shouldn't have ended up in subversion. All fixed now, waiting for it to become live (just update /www/jakarta.apache.org on people. I also fixed the mail2.html, where all links were broken (archives were all pointing the mail-archives.eu.apache.org which is kind of broken :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
heads up
Doesn't seem much, but haven't done anything with mail since Wednesday, so I am seriously behind. Will try to catch up during the weekend.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
Hi Julius (learning here :), Thanx for the comprehensive and well thought out mail.. Julius Davies wrote: Thanks for your reply, Martin! To reiterate (hopefully more clearly this time), I see two dilemmas and two problems: Dilemma #1: -- You can't stop people from forking. Forking is the lowest barrier way for a committer-less community to revive an inactive project. So should you fight the fork, or roll with the fork? Keep in mind that forking itself is not an insignificant act! To learn the code, create new code, setup a new SVN, host a new domain - these are all real work. So I think a fork should be recognized as a sign of significant community interest in reviving the project. A fork, while the lowest barrier, is still not something to be dismissed. Goal is not to stop forking. A lot of code is forked (even I do it, although normally not complete codebases), although I like to prevent forking for the wrong reasons, which in this case means a project that is inactive. Dilemma #2 (Martin's dilemma) -- To keep things in the family (avoiding the fork), you need a committer. On an inactive project a committer cannot be created without lowering Apache's standards. Lowering standards, while problematic in itself, is politically infeasible, since it debases the status of being a fully fledged committer. (Some people will not care about this, but some people will, and I think @apache.org email addresses are an important status symbol in the IT world, and not worth debasing.) (If I may be bold, I would cry out to you all, Don't be ashamed of the status! You have established an IT peerage of sorts, and it's quite miraculous to see it both community and meritocracy based!). There are acutually 2 problems : 1 is reviving and 2 prevent projects from being inactive. Both can be achieved without lowering Apache standards I think. (The aside that lowering standards is problematic in itself points to other problems that I hope are obvious, and are perhaps as big a deal as any status issues mentioned above). (I wonder if I love parentheses so much because I am a programmer?) Problem #1 -- Code developed outside Apache will not have Apache's strong guarantee that the code is not stolen, and is indeed available for use under ASL. (As someone trying to donate not-yet-commons-ssl - let me tell you - Apache is serious about this stuff!). So it's hard to bring any forked code back in. It isn't that hard, just legal paperwork and a legal check (see http://incubator.apache.org/ip-clearance/ip-clearance-template.html for more info) You are kind of in a different spot, since you have an original work created by you (/ the company you work for), which depending on where it will end up could require full incubation or just ip clearance. The paperwork as far as Apache goes (for not-yet-commons-ssl) is already in place. As said I will restart the discussion on this when your employer is happy. Problem #2 -- Any solution that requires an existing committer become more busy than they already are will not work. I find that existing committers are extremely busy. Imagine a perfect solution where all that is needed is that an existing committer scratch their nose once. I think such a solution will fail because committers (and contributors as well) are already too busy. Ok what you are saying here is that reviving a project is effectively not possible. To notice new committer material you have to invest some time, after a vote, you have to mentor them. Now let's assume there is fork. When you want to bring the fork back, we need to do a lot more work than just that, clear ip, vote to get the codebase back in and also do the same as getting a new committer on board. So in the end it will mean twice as much work. My Solution -- I think it's important to ride the community wave. With inactive projects, the community has no committer, so I believe they are essentially forced into a fork in this case. I think Apache should try to create a procedure that leverages as much of the existing committer-less community momentum as possible. For inactive projects, try to become fork friendly. Or to become more friendly to people who want to get involved.. How much external code can the fork generate before it's time to bring it back into the family? I figure 95% - 99% of the pre-existing code will remain. A simple diff will make this apparent. Full incubation is too heavy when you know that 95% of the code is already pure Apache already! It doesn't matter if the code new is 0.1% or 50%. The amount of work is the same (though if you want to review every change, the 50% thing takes more time of course) But Martin has an excellent point here: The problem most of the time that there
Howto revive inactive projects ?
Hi everyone, Moving this from the private list to general (this is actually a spin of from a thread about adding a committer to an inactive project, hence that it was on private). Definition list : Inactive project = a project that has no *developer* community. The Apache Way : To become committer on a project you have to earn that right, you have to stand out, submit patches, show you care, learn the apache way and have to get noticed by the current committers who can nominate such a person. Problem : If that didn't happen enough in the past, it can happen that at a certain point no developer community is active anymore. Which causes : A catch22 situation. Since there is no developer community, no one is able to determine if people deserve to become a committer. Even if you are monitoring such a list (such as I do for all Jakarta lists), it is hard to determine if people deserve committership. Solution : I don't have one specifically :) Part of the solution is always that a project needs a kind of mentor that is willing to invest time in a project, teach the Apache way, etc.. Let's come up with a way to get around the catch22 scenario.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
Hi Julies, Julius Davies wrote: Hi, Martin, and Everyone, If someone is interested in taking over a truly inactive project, maybe they should fork and start their own SVN repository from their own domain. The person should make it clear that their fork is in no way sanctioned by Apache. That's a requirement, since it cannot be called the same as the Apache project name. The only responsibility Apache might have in this situation, if so inclined, is to include a link from [inactive-project].apache.org to the fork, with some warnings that Apache's higher standards with respect to intellectual property are not in effect if you follow the link. Don't agree here. Our current code base is our responsibility, even though there are no active developers. Better information on the project status could be useful however. If the fork proves popular, and the person wants to bring it back into the family, the person could write an email to Jakarta-General asking to be nominated, become a committer, and then merge the fork back in. They will have to come through the incubator to come back to us, because of legal issues. The problem most of the time that there isn't even someone asking to take over.. A fork may also not use our project name. So I prefer to get momentum back here :) I'm assuming that a reactivated project with only one committer is still better than an inactive one with none I'm also assuming that the majority of inactive projects are smaller ones which probably only had one main committer / benevolent-dictator in the first place: http://blog.generationjava.com/roller/bayard/entry/enterprise_communities_episode_2 blockquote Commons is a very interesting case study here. Here's a pretty obvious white elephant - nearly every Commons component is running under the dictator model. You can point to any component and as long as it's active, it's So and so's baby. /blockquote Martin, can you provide some example projects that are running into this catch22? Is it quite a rare situation? Slide is the current case at hand, which is far from a small component (and has quite a complex code base from what I understood). Currently we have one committer there who is still learning his way into the code base (please correct me Antoine if this is a false statement). Cactus has a bit of the scenario you described btw (external code), but I prefer people working here, instead of forking, so people can see the project is alive and no legal stuff needs to be dealt with when returning the code. Another project is BCEL, which actually has got 2 forks. So it's not really a rare scenario and could surface any time when there aren't enough committers left to get new people aboard. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds docu?
Gump doesn't build against the versions of the dependencies specified in the pom / project.xml, but builds against the latest of everything, which could mean other trouble if you are using those jars. Mvgr, Martin Andrew C. Oliver wrote: Ummwhy not out of Gump? Phil Steitz wrote: Henri Yandell wrote: On 1/16/07, Ortwin Glück [EMAIL PROTECTED] wrote: Hi, Does anyone (Henry?) know what happened to http://www.apache.org/dev/nightly-builds.html ? It's referenced from http://www.apache.org/dev/ at the very bottom of the page. I'm looking for information how to get nightly builds done for HttpComponents. It probably never existed. When that page was created the links were made for pages that didn't exist to encourage people to write them - didn't work :) Nightly build wise... it's still an unorganized situation. In Commons we have some hand written scripts that are used on a zone (vmbuild) to build the code each night. Taglibs used to be built each night on Glenn's machine (I suspect that's not true anymore). We could expand the script for Commons to work from the Jakarta perspective and not the Commons one. +1 and would not be hard to do. Makes sense to do this for all Jakarta components that want nightlies and as long as the builds are reasonable in execution time, this should not be a problem. The current script supports Ant, Maven 1 and Maven 2. The script code is in svn at jakarta/commons/proper/commons-nightly/. The main script, commons_nigthly.sh gets svn upped on vmbuild by a crontab wrapper before executing each night, so if you just make changes to include a new build or build type into this script and config and check in the changes, the new component will be added. Phil - 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: My svn account
You received Joes mail ? Mvgr, Martin Andrew C. Oliver wrote: [EMAIL PROTECTED] :cat /usr/local/bin/svnpasswd #!/bin/sh echo Please visit https://svn.apache.org/change-password; robert burrell donkin wrote: On Wed, 2007-01-10 at 16:44 -0500, Andrew C. Oliver wrote: IIRC, this is my 4th attempt to resolve this (I try like every 3-4 months). I would like to commit something. My SVN account is not working. per the instructions off the SVN page I emailed [EMAIL PROTECTED] I got no response. I am still able to log in to people.apache.org. svnpasswd...? - robert - 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: My svn account
:) Can you give me the error that you are getting, so I can ping infra with something specific. I checked your account in the svn authorization and couldn't find any mistakes there, so probably has to do with your password setting. Mvgr, Martin Andrew C. Oliver wrote: IIRC, this is my 4th attempt to resolve this (I try like every 3-4 months). I would like to commit something. My SVN account is not working. per the instructions off the SVN page I emailed [EMAIL PROTECTED] I got no response. I am still able to log in to people.apache.org. Suggestions for resolution? Account name: acoliver. Any help would be appreciated. I will consider requests for bribes. -andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A chart/graph Library suite
Geir Magnusson Jr. wrote: On Jan 7, 2007, at 8:55 AM, J.Pietschmann wrote: Senthil S wrote: Expecting a chart/graph making library from Apache that is similar to jfreechart and has enhanced features to create live and interactive graphs. The question is: why do you think there should be another charting/graphing library? Do you have problems with the JFreeChart license (LGPL)? Wasn't it a BSD license before? Are you confusing it with JChart maybe ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report December
Just a reminder : the board report was written by me (completely) and the feeling is something I have and doesn't necessarily mean the whole of Jakarta agrees with that. The board is aware that it is my personal report. Don't forget that in the first place this feeling (/ observation of this disconnect) is expressed by POI people themselves (the complete thread) and was offered help by Henri (at that time VP Jakarta) to help fix the situation : http://www.mail-archive.com/poi-dev@jakarta.apache.org/msg11492.html. The vote for Nick to be added to the PMC, didn't give me a good signal either. It showed that Jakarta PMC members representing POI had a hard time to vote, probably causing that (almost) no one at Jakarta felt the need to vote or invest energy to see who Nick is. Since I don't believe people feel that Nick shouldn't be on the PMC shows that there is a disconnect between Jakarta and POI. If you add that with the svn karma exception with the legal NDA stuff (which isn't something that the PMC is officially aware of), the release vote withouth result, not notifying the pmc of the release, not sending mail to eg announcements of release, not adding the releases to the main jakarta page, you can probably see the reason for my feeling that POI is not part of Jakarta or Apache. That being said : I don't have any doubts that the intentions are good and we are happy to help out, but it helps to be proactive. A good start would accepting Marks offer :) Mvgr, Martin Rainer Klute wrote: Avik Sengupta schrieb: It feels like they are acting as a separate entity in Jakarta and even the ASF itself Let me put on record my severe objection to this statement. Yes, the wording is quite harsh. However, following the arguments in the POI thread, we indeed seem not to act as we should - be it deliberately or not. I must admit I didn't follow the Apache politics closely in the past for the lack of time, but it seems we have to invest some time to get back on track. I am sure Apache fellows will help us by pointing us into the right direction. 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 OpenPGP fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Tetsuya Kitahata wrote: [+1] Open up POI svn commit access. [-1] Don't open POI svn commit access, because... As long as the ASF (entity)/ Jakarta PMC have an WILL to protect and can protect the developers from the Legal Issues, I am willing to put +1 to this vote. The biggest problem is that if we need protection, there is currently nothing in place (even though you need to swear something). There are no records, no signed documents and such thing needs to be organised at a PMC / Apache level. -- I, personally, hope I can live happily and peacefully in this wonderful jakarta land (and the apache land). +1 to that ;) -- Tetsuya [EMAIL PROTECTED] P.S. Mvgr Don't forget the vote in March where everyone voted +1 Mvgr except the POI committers. Seems that I could not catch up this thread (in [EMAIL PROTECTED] / March) at that time. Sorry. http://marc.theaimsgroup.com/?l=jakarta-generalm=114344584424864w=2 is the start of the thread / vote. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Martin van den Bemt wrote: -1 from me. Harmony doesn't let anyone commit on their project unless they they sign a statement saying they haven't looked at Sun's source code[1]. AFAIK this is a similar issue and the POI policy [2] is designed to protect POI, which as a user of POI is a good thing IMO. Even if this fear is actually unfounded seems like a sensible policy to err on the side of caution. Just FYI, the policy doesn't mean anything legally, so it doesn't help anyone. We have the ICLA that covers that. Keeping POI SVN closed, is as far as I could see, just based on the assumption that it means something. Besides that if this is a policy of some kind, where are the records ? Ouch rereading this I meant : The POI policy of course :) (in case it is misread) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Avik Sengupta wrote: I dont care about this vote (any more). I do care deeply about POI. I do care about Apache and Jakarta. I resent the opposite presumption on less than rock-hard grounds, because it is a pretty big accusation. As noted in my analyses, I stated that I could be misinterpreting things. The fact that the POI and remaining jakarta communties are separate is a FACT. Most people on this thread seems to have turned it into a JUDGEMENT. If that does not gel well with what the 'oversight' requirements, we need to find a way to work WITH the community, rather than attack it. See my reply to the board report (where you stated the wording was harsh). All open source project projects contributors go thru highs and lows of contribution. Commiters come and go, some permanently, some temporarily. (I recall reading a well written account of this from either Brian or Stefano.. cant remember... anyone have a link). At POI, we're lucky enough to have fresh blood coming in at regular intevals (as with most open source projects, usually from nowhere, surprising you with their commitment and great code..). Once again, we need to work with this phenomenon, rather than condemn the whole project on that basis. Condemning the project isn't what my goal is. And I think I made clear in other mails that POI is pretty healthy with development, user base, etc. (Since I am not a user of POI, I cannot judge it technically, although I assume you wouldn't have any users if it was technically bad). The charge of insularity can go both ways. This thread is only about SNV access. Can I not ask how many of the indignant correspondents on this thread have taken the effort to come and help us get things right on the poi dev lists? However, that's an argument that wont get us anywhere, so lets not go down that path. There were efforts in the past (see my board report reply) and I was thinking of taking a different approach, which I described in the board report too. So in reply to every other offer of help, welcome! But I dont understand, why do people want to be an officially anointed 'mentor' before helping out? I thought the Apache way was about the 'doing' ... he who does ... etc. Please join the POI dev lists, and show us where I joined the dev and user list before I became VP. And I thought hey the vote thread isn't finished yet. Hence my e-mail to poi / private list about the release. After that offer you could have asked for help (which was offered) and state we are on it or something (about the release itself not being checked). we go wrong. We'd even instituted a policy to open the svn access to all jakarta committers for only asking. If you read this thread Andy gave a very different explanation of this policy to me (although I could have misread him). Permit me to get personal to illustrate my point. When Henry noticed a few issues with the release, he wrote back saying what they were. Some we've pushed back, other's we've promised to fix, and in the meanwhile, he's offered to fix some of them himself, an offer that's been very gratefully accepted. I read the thread. This thread, on the other hand, has degenerated into complete POI bashing. Once again, I'd be happy to discuss the merits of this svn proposal... its the subsequent bashing that completely baffles me. Just speaking for myself here : I just wanted to open up svn karma as a first step to improve things. Maybe it should have been the last vote in the process. When there was asked about the reasoning behind the vote, I just added the same thing I already said in the mail about the release (about PMC members giving oversight) and trying to get to bounce the ball back to the project to get some answers on eg the legal issue, which still remains partially unanswered. If POI bashing is what I did, my apologies, although after rereading the thread, the negativity comes from both sides and I also seen a lot of messages with positive attitude, so let's focus on that :) Finally Martin, you say If you have anything positive to contribute...; dont know if you mean me personally or the project as a whole, I find that a wee bit offensive... sorry if I'm misunderstanding. POI is in active development, used by thousands , Never disputed that, I even said that in the message you are replying to. I wanted to make clear with that statement (the positive part) that in that respect the project is doing more than well (which I stated in other parts of the thread as well). I was kind of missing that in the responses from, in this case, you. it doesn't need a mandate from the PMC to be successful project, does it? It does need a mandate to be a successful project, which is the thing I am trying to solve here, that most requests/vote announcements don't get a response is because the vote and release is because we have lazy consensus. Some do get a response (eg not the needed 3 +1
Re: [VOTE] Remove POI svn restrictions.
If you are lost in bad sentences let me know :) Forgot to proof read :( Mvgr, Martin Martin van den Bemt wrote: Avik Sengupta wrote: I dont care about this vote (any more). I do care deeply about POI. I do care about Apache and Jakarta. I resent the opposite presumption on less than rock-hard grounds, because it is a pretty big accusation. As noted in my analyses, I stated that I could be misinterpreting things. The fact that the POI and remaining jakarta communties are separate is a FACT. Most people on this thread seems to have turned it into a JUDGEMENT. If that does not gel well with what the 'oversight' requirements, we need to find a way to work WITH the community, rather than attack it. See my reply to the board report (where you stated the wording was harsh). All open source project projects contributors go thru highs and lows of contribution. Commiters come and go, some permanently, some temporarily. (I recall reading a well written account of this from either Brian or Stefano.. cant remember... anyone have a link). At POI, we're lucky enough to have fresh blood coming in at regular intevals (as with most open source projects, usually from nowhere, surprising you with their commitment and great code..). Once again, we need to work with this phenomenon, rather than condemn the whole project on that basis. Condemning the project isn't what my goal is. And I think I made clear in other mails that POI is pretty healthy with development, user base, etc. (Since I am not a user of POI, I cannot judge it technically, although I assume you wouldn't have any users if it was technically bad). The charge of insularity can go both ways. This thread is only about SNV access. Can I not ask how many of the indignant correspondents on this thread have taken the effort to come and help us get things right on the poi dev lists? However, that's an argument that wont get us anywhere, so lets not go down that path. There were efforts in the past (see my board report reply) and I was thinking of taking a different approach, which I described in the board report too. So in reply to every other offer of help, welcome! But I dont understand, why do people want to be an officially anointed 'mentor' before helping out? I thought the Apache way was about the 'doing' ... he who does ... etc. Please join the POI dev lists, and show us where I joined the dev and user list before I became VP. And I thought hey the vote thread isn't finished yet. Hence my e-mail to poi / private list about the release. After that offer you could have asked for help (which was offered) and state we are on it or something (about the release itself not being checked). we go wrong. We'd even instituted a policy to open the svn access to all jakarta committers for only asking. If you read this thread Andy gave a very different explanation of this policy to me (although I could have misread him). Permit me to get personal to illustrate my point. When Henry noticed a few issues with the release, he wrote back saying what they were. Some we've pushed back, other's we've promised to fix, and in the meanwhile, he's offered to fix some of them himself, an offer that's been very gratefully accepted. I read the thread. This thread, on the other hand, has degenerated into complete POI bashing. Once again, I'd be happy to discuss the merits of this svn proposal... its the subsequent bashing that completely baffles me. Just speaking for myself here : I just wanted to open up svn karma as a first step to improve things. Maybe it should have been the last vote in the process. When there was asked about the reasoning behind the vote, I just added the same thing I already said in the mail about the release (about PMC members giving oversight) and trying to get to bounce the ball back to the project to get some answers on eg the legal issue, which still remains partially unanswered. If POI bashing is what I did, my apologies, although after rereading the thread, the negativity comes from both sides and I also seen a lot of messages with positive attitude, so let's focus on that :) Finally Martin, you say If you have anything positive to contribute...; dont know if you mean me personally or the project as a whole, I find that a wee bit offensive... sorry if I'm misunderstanding. POI is in active development, used by thousands , Never disputed that, I even said that in the message you are replying to. I wanted to make clear with that statement (the positive part) that in that respect the project is doing more than well (which I stated in other parts of the thread as well). I was kind of missing that in the responses from, in this case, you. it doesn't need a mandate from the PMC to be successful project, does it? It does need a mandate to be a successful project, which is the thing I am trying to solve here, that most
Re: POI TLP -- constructively
See inline. Andrew C. Oliver wrote: It is fair to say that not many POI people participate in Jakarta. However, to add perspective we never joined the Jakarta as it is -- we joined Jakarta as it was...and one day this formed around us. It is fair to criticize our build...it is pretty rusty and yucky. I do however thing focusing too much on it is a bit well...mean. Nick has been doing a great job and a lot of work. (I on the other hand will have to merge my patches into SVN before I can even commit them since they're off of CVS :-P ). However it was his first release. Moreover, Apache's release policies have evolved considerably since the last official release and none of us have a valid signed key...that needs to be rectified (laziness, don't like conventions where all the cool key signing parties). We're not the only one's guilty of kinds of neglect. Our own Marc Johnson (who cofounded the project) has been extremely frustrated at the lack of responsiveness in getting his access/etc in order and no one at POI seems to be able to jerk the right chain in Apache to make that happen (and I think he requested from this PMC with no effect). So much that he's given up! First of all : Nick is not the one that got blamed and was given credit for the good work he is doing at POI. The real point here was oversight, which sparked the idea of mentoring. I didn't have a clue about Marc Johnson to be honest. And POI shouldn't jerk the right chain the VP of Jakarta should do that, only this VP didn't know about Marc Johnson :) (maybe just bad reading on my part though). I prefer to restart a vote to get him aboard, or you can do the honors yourself (meaning POI) when POI is TLP (although if you take that path that process will take even longer) In any case, legal issues aside (which have to a good degree abated, but Let's leave that aside for the moment. I therefore propose this: * Jakarta PMC has the responsibility to not call more votes on restructuring POI during the next X months. (Access or otherwise) We need to set a date on this (see below about the board). BTW this was the only vote that was in my planning to be called, so no other votes will be called :) The steps after this vote was passed, wouldn't need any votes (as far as I can oversee now). * POI committers have responsibility for achieving the proper oversight procedures and putting out a new release in the next X months That is what every project does / should do. The problem was that this was not happening. As Stephen already said, the Jarkarta PMC (and me personally) are responsible for whatever you do at POI as long you are at Jakarta. So with vote results, the actual release, new committers and other issues, you need to inform the PMC, so they have the ability to check that everything is ok. (just want to add this specifically, although I don't think you meant to specifically exclude this) * POI committers have responsibility for putting together a TLP proposal and working out a consensus. Agreed. Maybe we should poll the board if they have any conditions, since they are the actual body that needs to approve the establishment of the POI Project. I'll ping them and see if they have time to talk about this on Wednesday. I'll let everyone know if there is anything to report from that front. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POI TLP -- constructively
Is this just your proposal or do other POI committers back this up ? (probably in the text, but not as clear as I like it to be). If poi committers agree with this proposal, I like to hear them :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POI TLP -- constructively
Need to add here that for the TLP Proposal you also need a vote from Jakarta.. I'll try to shut up now :) Mvgr, Martin Martin van den Bemt wrote: See inline. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Niall Pemberton wrote: On 12/16/06, Martin van den Bemt [EMAIL PROTECTED] wrote: -1 from me. Harmony doesn't let anyone commit on their project unless they they sign a statement saying they haven't looked at Sun's source code[1]. AFAIK this is a similar issue and the POI policy [2] is designed to protect POI, which as a user of POI is a good thing IMO. Even if this fear is actually unfounded seems like a sensible policy to err on the side of caution. Just FYI, the policy doesn't mean anything legally, so it doesn't help anyone. We have the ICLA that covers that. Keeping POI SVN closed, is as far as I could see, just based on the assumption that it means something. Besides that if this is a policy of some kind, where are the records ? Why is it any different than Harmony? If someone has received knowledge of MS propriety formats under a NDA then wouldn't using that knowledge to contribute to POI put the POI project at risk? If the ICLA means that legally from an ASF POV it doesn't matter since the responsibility/liability would be with the contributor then the same logic could be applied to harmony. Seems to me that even if the ASF is covered at the end of the day avoiding a legal issue with a big entity such as MS is far more desirable than getting into a tangle in the first place. I am not saying the legal stuff would be bad, just that currently nothing is in place to have that covered. With harmony this is a Harmony policy, which is handled by the PMC and there are records and the board is aware of this. So effectively we don't have anything in place, just a statement on the website, so if we needed any protection based on the NDA stuff, we don't have anything to show for. I cannot start with getting the legal stuff figured out when POI is acting as it's own entity, without even any oversight from the Jakarta PMC members representing POI. But I think I made that point clear in some of the replies i've given. I also think its a mistake to deal with whatever issues people think there are in POI via a vote. Back in March the POI devs voted to exclude POI from this policy of opening SVN access. If we think the reason underlying POI's exclusion from this policy is not valid then it would have been far better to start a discussion with them regarding this first - rather than launching straight into a vote. I'd have rather seem an attempt at consensus first rather than going straight for conflict. I could have started this in another way, although I doubt consensus would be reached if I did that another way. POI is living in it's own universe currently (we are even talking about them) and since this issue concerns the whole of Jakarta and things need to happen now,because of the lack of oversight given by the PMC members representing POI. Opening up POI is a first step in the right direction, next steps would be mentoring the POI project, get the legal issue straightened out (that is making an official Jakarta policy if that is needed and having official records). Alternatives like POI going TLP (as was mentioned by a couple of people) would also be an option, so that they deal with the board directly, but since the POI committers aren't ready for that (see the mentoring part), that would be a hard case to sell. Seems to me that svn access isn't the root of the issue here and therefore a red herring, since changing that isn't IMO going to resolve whatever the real issues people think there are. svn access is the first step towards improvement. Svn access for me *is* a real issue, I think the vote made that clear. Don't forget the vote in March where everyone voted +1 except the POI committers. Now we are 8 months further and it is time they join the majority in my opinion. If they want to have separate svn access at this time, I think they are stating that they do not want to be part of Jakarta. Mvgr, Martin Niall Mvgr, Martin - 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: [VOTE] Remove POI svn restrictions.
Niall Pemberton wrote: On 12/17/06, Roland Weber [EMAIL PROTECTED] wrote: Hello Niall, Why is it any different than Harmony? Harmony requires that an Authorized Contributor Questionnaire be signed. The ACQ surely has been reviewd by the ASF legal team, and signatures are legally significant. http://harmony.apache.org/auth_cont_quest.html The POI Get Involved page only mentions this: Those submitting patches that show insight into the file format may be asked to state explicitly that they are eligible or possibly sign an agreement. http://jakarta.apache.org/poi/getinvolved/index.html may be? possibly? Did the ASF legal team prepare such a document for signing or not? If they did, shouldn't it be linked on the web page? And why isn't every contributor required to state or sign something? Who decides who will have to state or sign? And who will process and keep track of the statements or signed documents if not the ASF legal team, who obviously are not aware of any such thing? If there is an established procedure addressing these questions, it should be documented on the web page. If there is not, the statement quoted above is just idle. I agree there should be an established policy endorsed by the PMC. My fear is that Andy Oliver either won't have the patience to do what it takes or fail to get anywhere because he pi**es off too many people in the process. Hopefully he'll prove me wrong or someone else from POI will sort it out. I simply don't care to be honest. Nick is doing lot's of work for POI, without any guidance from the people you anticipate of giving guidance, which is what I care about. So my first goal is helping out Nick so he can continue the good work he is doing over there. If someone has received knowledge of MS propriety formats under a NDA then wouldn't using that knowledge to contribute to POI put the POI project at risk? Yes it would. That's why the page mentions that people with access to NDA'd information are not allowed to contribute. As far as I can tell, there is no discussion about this policy. There is a discussion about access restrictions in SVN. Let me throw the following statements/opinions into this discussion: 1. Jakarta committers have proven that they are responsible developers, otherwise they wouldn't have been voted committers. 2. No responsible developer would just commit some code to a Jakarta subproject with which he/she is not familiar, or ignore the rules and policies in place for that subproject. Generally this is true, although I have seen a couple of occasions where committers have made code changes on Commons components they had no prior involvement with without pinging the mailing list first. And we educated those people. 3. If current committers show interest in contributing to the POI subproject, they will make an appearance on the mailing lists and submit patches to the bug tracking system for review. There is plenty of opportunity to educate them about the policy and to question them about possible NDA contamination. 4. If anyone would commit unwanted/dangerous code to POI (directly without patch review!) that contribution would immediately be detected from the commit message that is automatically generated, and would be vetoed and undone by the regular committers to the subproject. This discussion is about removing technical barriers in SVN, not about throwing random (barbed ;-) code into POI. It's about running a community based on mutual trust and review as opposed to walls and fences. At least that's how I see it. Personally I'm +/-0 on removing svn barriers anyway. I don't believe any exisiting committer that starts to contribute to a project in the normal way isn't going to get given commit access pretty quickly. Anyway generally I don't disagree with the sentiments/opinions you've expressed - but I do think POI has grounds for a slightly different policy than most of our code bases since what they deal with is the IP of a large company that if infringed could cause us problems in the same way as with Harmony and Sun's source code. IMO then the contrubuting policy for POI needs to be resolved/formally established first and svn access should be decided afterwards once we have a policy endorsed by the PMC. The first problem we have to deal with is that releases aren't done the way the ASF wants them to be done, which is currently the legal issue at hand. Part of the problem is that they (sorry bad word choices coming here) don't trust the rest of Jakarta of doing the right thing and the rest of Jakarta trusts them to do the right thing. They have proven they don't do the right thing atm (to be clear : not blaming Nick here!), which hurts Jakarta as a whole. Maybe repeating myself here :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [VOTE] Remove POI svn restrictions.
Hi Avik, Avik Sengupta wrote: Wow! The one weekend I decide not to check mail!! :) I know what you mean :) Am replying to the original message for convenience, but have read the thread till this point. Basically, the amount of negativity towards POI project in the thread seems seems quite painful. At the end of the day, I believe we keep saying 'Apache is about communities'. Legal oversight is important, but if its at the cost of destroying a community, what's the use? I would have voted -1 on this, not because of legal reasons (which I don't have too strong a view on any more) but because I do not understand the need for this current intervention. 'Majority' does not seem to be a good enough reason. Errors in build which have been promised a fix does not seem a big enuf reason either. I like to know your reason of the -1, despite of what has already been said (and despite of what is said below here) How can we determine what the next appropriate step is if you don't speak up ? However, given the strongly negative tone of this thread, I do not wish to debate this further. Therefore count me in as a 'don't care any more' If you have anything positive to contribute, let me know. I can think of a couple : A lot of development is being done, user list are healthy, so enough to invest energy in. The simple fact is that you are currently part of Jakarta and POI doesn't seem to realize that or to misuse your words don't care about that. Everything that affects POI actually affects Jakarta. I've been a VP Jakarta for about 6 months now and I actually never had the feeling that POI was part of that, even though I am the one who his held accountable of what happens at POI. With the releases going bad, even though there is PMC representation for POI, was the ultimate trigger for this vote as an initial start to improve things and after that taking the next steps (I summed them up already). So your remark about don't care anymore is not making me very happy, since I hoped you would start caring, although I hope I misinterpreted that remark and making assumptions that are wrong. The big problem is that no one from POI is actually making any effort to clear any misinterpretations and assumptions. Hope you understand what I am trying to say. I'd have been happy seeing POI move to a TLP. However, some of the comments in this thread seem to preclude that possibility either. I think his leaves the community between a rock and a hard place ... I dont want us to be subsumed as a commons project Subsuming is not something I see happening, we already have enough sub sub projects. The total projects in Jakarta is currently at 109 (only sub projects and projects without sub projects are counted). Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report December
Jakarta Board Report First of all I like to mention that I haven't be able to spent the time I wanted to spend, which is something I will try to improve. I like to request special attention is given to the POI subproject section in the report. Another improvement should be that the majority of the report should come from the community, which I am totally failing to delegate atm. I will start actively persuing additions to the board report by our Jakarta committers when events occur. I don't see this as a community problem, the failure is completely mine. Apachecon Austin was my first visit to apachecon and it was a great experience to meet the people I haven't met in person yet. One of the things I had planned was the Jakarta BOF, where I had the idea to give a presentation and get feedback on other peoples thoughts about Jakarta. It gave me some more insight in projects I didn't have too much knowledge about and the nature of the BOF turned out to be more of free discussion and thought outlet. On my todo list is to extract the points that were identified as needing attention and send them to the general list for discussion. Most important on that list is the identity of Jakarta, easy access information of the state the projects are in and Jakarta being more proactive of getting people aboard on the less active or non active projects. Another idea the recently popped up is having experienced mentors assigned to projects. With a 100+ projects this seems like a good idea (see JCS for an example of this) PMC : New pmc members: Nick Burch Roland Weber Change : Dany Angus requested to be removed from the PMC. Not acted upon this yet, since he is an ASF member, a change in the committee-info.txt probably is sufficient. New committers : Jurgen Hoffmann was voted on to be able to commit to Jakarta. He earned this because of his devotion on Turbine. Antoine Levy-Lambert, so he can work on Slide (on his own request and voted on by the PMC). Releases : - HttpComponents HttpCore 4.0-alpha3 - Commons Digester 1.8 - Commons Discovery 0.4 - Commons DbUtils 1.1 - Commons Validator 1.3.1 - Commons HttpClient 3.1-beta1 - BSF 2.4.0 - Commons Lang 2.2 - Commons Configuration 1.3 Not yet project commons-ssl: There were announcements on the httpcomponents list (and on the tomcat list) about a release of commons-ssl, which in real life isn't a commons project at all, but an external project, with the intention of joining Jakarta. An CLA is on file and currently an envelope is on the way to Jim, since his employer wants to have a signed copy back. I asked Julius Davies if he could start a proposal on the Jakarta to discuss if we could sponsor the donation. The thread kind of died and I will restart the thread when the paperwork is handled. place. Julies fixed the naming of commons-ssl by calling it Not-Yet-Commons-ssl, with giving an explenation. Link can be found here : http://juliusdavies.ca/commons-ssl/ Projects (currently 15 main projects) BCEL Bcel hardly has any activity and during the BOF I learned that Torsten Curdt adopted BCEL. With the Google summer of code Torsten mentored 1 person working on BCEL and BCEL supports 1.5 now. It could be worth investigating if the 2 forks of BCEL that are out there (Findbugs and AspectJ) can be merged back to BCEL itself, however Torsten said that both forks probably don't want to invest there time in a merge, since the current situation works for them. Currently BCEL is considered legacy and since projects are using it, it is still maintained. If there are signals of people wanting to become active, we will definitely take that opportunity. BSF After about 4 years of no releases, BSF finally got their release, which was in the Apachecon press release. Since the release things have become a bit more quiet and the user list still points to fact that not a lot of users have picked up on the release yet, since there were problems with the downloadscript. It will probably also take time to get the users back that were lost in the past by not having any releases. Personal note : I would like to thank the BSF committers for doing a great job. Cactus Cactus is currently unmaintained. There are still users, but most questions don't get an answer. A lot of people also are wondering if maven2 will be supported and with what j2ee versions cactus will work. There is definitely work to do here (Cargo integration comes to mind). Commons Commons has 33 proper, 11 sandbox and 16 dormant subprojects. Currently there is a huge release boom going on at commons. After past problems with votes not getting any attention I think things have picked up for the better and most votes get attention. The situation is still not perfect and still needs focus. ECS ECS is mature / dormant. The dev list had it's last noise in August. The user list didn't have any traffic since April, which kind of looks like there isn't a user base. Will make this an agenda item. HttpComponents Currently
Re: Board Report December
Replying to myself :) People I am doing something wrong. The board report should be created by the committers, with a personal note added from the Vice President (or in slang Chair). As you all can see, I am the only one who wrote it, which is 1) time consuming 2) icomplete (just have a look a very small commons section) 3) maybe completely wrong in some cases :) 4) We have 109 projects in Jakarta, I am stupid for even trying to create this report completely by myself. So to correct my misbehaviour : I will setup a template in the wiki for the next board report, so if anything happens that you feel needs sharing and in case of new committers, pmc members, releases and other decisions I kindly request that everyone adds it. I will send a mail to general (and maybe even all the dev lists) when the page is up and running and when I see something happening I will ping the person who made something happening to add it to the report. Hope you people forgive me ;) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report December
Nah not like that one :) One with all correct projects already present (I'll just change that page!) :) I want to make sure that all reports contain all subprojects and preferrably all sub sub projects (and I really hope we don't have any sub sub sub projects) Thanx for the link :) Knew something was up there, but didn't have a look yet :) Mvgr, Martin Dennis Lundberg wrote: Martin van den Bemt wrote: Replying to myself :) People I am doing something wrong. The board report should be created by the committers, with a personal note added from the Vice President (or in slang Chair). As you all can see, I am the only one who wrote it, which is 1) time consuming 2) icomplete (just have a look a very small commons section) 3) maybe completely wrong in some cases :) 4) We have 109 projects in Jakarta, I am stupid for even trying to create this report completely by myself. So to correct my misbehaviour : I will setup a template in the wiki for the next board report, so if anything happens that you feel needs sharing and in case of new committers, pmc members, releases and other decisions I kindly request that everyone adds it. You mean like this one :) http://wiki.apache.org/jakarta/BoardReportTemplate?highlight=%28Template%29 I will send a mail to general (and maybe even all the dev lists) when the page is up and running and when I see something happening I will ping the person who made something happening to add it to the report. Hope you people forgive me ;) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
made a proposal to promote POI now, I would expect the board to reject it and tell us make POI work in Jakarta before you promote it to TLP. That is was my feeling as well, but I understood from the board that they rather prefer that things are not hidden in subprojects, which is something that can easily happen with big projects like Jakarta (and I can imagine that no one actually had any real idea of the number of projects over here). Based on that I started with this report giving information about all projects, so they still have the opportunity to intervene. This also means that board reports should be more open and preferably identify issues and problems, as well as the positive things happening. We should make the job easier for the board to determine if Jakarta is healthy. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board reports.
Hi everyone, The official way board reports should be handled has 2 parts : 1 part that is edited by the the committers (= the people who know best about there projects) and after that the VP can add his personal notes to the report. So starting from now I would like to see that people add the things they want in the report to this page : http://wiki.apache.org/jakarta/JakartaBoardReport-March2007 Some things need to be in the board report : - New committers - New PMC Members - Releases (under the release section at the top) and a more detailed explenation of the release under the project section (not too detailed please, a summary will do). Besides that I would also like to see feedback for individual commons components (in proper). Especially interesting is the developer involvement and the user list interaction over the last 3 months. If you want to share anything else that you think is important for the board to know, please do so at above page. Thanx for your help :) Mvgr, Martin PS There are more subprojects with subprojects, besides commons, though eg Taglibs has only 2 or 3 components with activity. I leave that to the respective projects to decide if a distinction in subprojects is needed, although it would be appreciated that you at least identify that there are subprojects in your projects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Trivial Update of JakartaBoardReport-March2007 by RolandWeber
Feel free to remove it from commons and add it to HttpComponents. It was just a dumb copy paste from the commons webpage :) While you are at it, you could also add this to the template (+ httpcode and httpasync) Mvgr, Martin Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta/JakartaBoardReport-March2007 The comment on the change is: HttpComponents project is responsible for maintaining Commons HttpClient -- ''!FileUpload'' - ''!HttpClient'' + ''!HttpClient'' - see !HttpComponents project below ''IO'' - 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]
