Re: [VOTE] Remove POI svn restrictions.
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 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. 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. Niall Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
On Fri, 2006-12-15 at 18:25 -0500, Andrew C. Oliver wrote: [...] what is your interest here? Do you have nothing better to do? You *might* (at some point) read up what part of Apache the POI project is in and who is currently legally responsible for it. This is not your small, private show on sf.net as you seem to think. You are, as a part of the ASF, bound to our legal structure, our rules and our community. Get used to it. If you don't want to be a part of Jakarta, apply for TLP. Best regards Henning -Andy Martin van den Bemt wrote: Hi everyone, You probably think Hey I have seen a similar vote started by Henri on 27-3-2006 and the outcome was 3 -1 from POI so their SVN is still closed for Jakarta committers. The reasoning behind this is that POI is still trying to stick to what it Jakarta once was and it is time they join the club completely. [+1] Open up POI svn commit access. [-1] Don't open POI svn commit access, because... The vote will be open for a week. 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
On Fri, 2006-12-15 at 20:30 -0500, Andrew C. Oliver wrote: [...] I would like to see a formats.apache.org project which was devoted to We do know that you are not serious here. [...] With the launch of Buni (http://buni.org) my time for repeating votes Domain Name:BUNI.ORG Created On:06-Oct-2006 13:29:38 UTC Last Updated On:14-Dec-2006 19:11:28 UTC Expiration Date:06-Oct-2007 13:29:38 UTC Sponsoring Registrar:Register.com Inc. (R71-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:4754392604712011 Registrant Name:Andrew Oliver Registrant Organization:Bunisoft, Inc. Registrant Street1:5426 Lake Vista Dr. Registrant Street2: Registrant Street3: Registrant City:Durham Registrant State/Province:NC Registrant Postal Code:27712 Registrant Country:US Registrant Phone:+1.9193218856 So what is the point? Just rebranding POI under another name? Why do you care if you have so much better stuff to do? Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
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. 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. 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. 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. +1 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. +1 cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
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. 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. 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. Niall 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. +1 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. +1 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:
Re: svn commit: r487443 - /jakarta/site/docs/site/downloads/downloads_bsf.cgi
Hi Sanka, what you are missing is svn propset svn:executable on site/docs/site/downloads/downloads_bsf.cgi This will set this file to executable when you check out the site into the jakarta tree and allow the CGI script to run. Best regards Henning On Fri, 2006-12-15 at 04:42 +, [EMAIL PROTECTED] wrote: Author: sanka Date: Thu Dec 14 20:42:34 2006 New Revision: 487443 URL: http://svn.apache.org/viewvc?view=revrev=487443 Log: Removed the download page temporarily. Removed: jakarta/site/docs/site/downloads/downloads_bsf.cgi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - 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.
hy im happy to join to ur party -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/general@jakarta.apache.org/5604698.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Rainer Klute schrieb: Martin van den Bemt schrieb: [+1] Open up POI svn commit access. [-1] Don't open POI svn commit access, because... [0] I don't care. Having read all the contribution http://dict.leo.org/ende?lp=endep=/gQPU.search=contributions on this thread, I revoke my vote quoted above and instead vote as follows: [+1] Open up POI svn commit access. Please read my vote not just as referring to a technical issue concerning commit access or not. My vote is a clear statement to * keep POI under the Jakarta hood, * stick to the ASF rules, and * do everything that is needed to straighten things out. I am a POI committer. 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 signature.asc Description: OpenPGP digital signature
Re: [VOTE] Remove POI svn restrictions.
On 12/15/06, Henri Yandell [EMAIL PROTECTED] wrote: On 12/15/06, Nick Burch [EMAIL PROTECTED] wrote: On Fri, 15 Dec 2006, Martin van den Bemt wrote: Apache legal doesn't know anything about this.. Back when I joined POI, I was told the apache legal team had suggested the requirement. Perhaps one of the older POI committers can supply the original details? My understanding is that the advice is from Andy's personal lawyer many moons ago, maybe before POI joined the ASF. I've sat and re-read all email I've ever received from Andy and I can't find anything to this effect - so it's no longer my understanding. Apologies for misleading everyone. Hen From an ASF point of view if someone breaks an NDA on our list or in a commit, then it's their head and not ours. We would respond as quickly as possible once we're aware of the issue by removing reference to that issue (and unless we think it was an honest mistake also yanking the commit rights of the person who broke it). I'm not sure if we'd legally have to do that or not - I don't know how NDAs fit into IP (copyright/trademarks), or if its just a personal agreement between two parties and the NDA breaker is just breaking that contract. I am not a lawyer etc etc, but the above is my understanding and would hold for any of our mailing lists. Public statements seem like an odd thing. There's no official archive of them at the ASF (and they're not made to the ASF), so I doubt they hold any weight or value to the ASF. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Wow! The one weekend I decide not to check mail!! :) 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. 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' 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 Regards - Avik Quoting Martin van den Bemt [EMAIL PROTECTED]: Hi everyone, You probably think Hey I have seen a similar vote started by Henri on 27-3-2006 and the outcome was 3 -1 from POI so their SVN is still closed for Jakarta committers. The reasoning behind this is that POI is still trying to stick to what it Jakarta once was and it is time they join the club completely. [+1] Open up POI svn commit access. [-1] Don't open POI svn commit access, because... The vote will be open for a week. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [VOTE] Remove POI svn restrictions.
On 12/17/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Avik Sengupta wrote: 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). My previous pro for POI as a TLP is that it would give the POI community more independence and would allow Jakarta to move in the direction of having an identity rather than being the what's left. I know I come across strongly as thinking that identity is commons-like, but I'll welcome any workable solution. The other option I could think of is for Jakarta to be a Java federation (as per XML), but I don't get the feeling that the federation ideas have had much success. I'd love to hear other ideas. [Short aside: Federation idea is for Jakarta to be a place where Java projects come together - basically the old Jakarta with each subproject being a TLP and yet still part of the same community. I think it's 4 years too late to try that :( ] My current con for POI as a TLP is that I think we shouldn't be going the release was wrong, send them TLP; we should be ensuring that things are good (source headers, releases, voting, all that junk^Wjazz) first as that's the Jakarta PMC's responsibility. A previous con I had was that it seemed to be going inactive, but activity seems to be happily up. So.. I think we need to: 1) Get the fixed POI release out. Fixed source headers, vote on the files etc. 2) Sort out the legal statement so that it's more official and organized (copying Harmony seems good). While everything I'm hearing when I ask legal-internal, legal vp, secretary etc (and same for Martin afaik) says we don't _have_ to do anything; I can see the points of the arguments for playing it safe. Effectively it's Jakarta PMC policy rather than legal requirement so we need to make it so. Apologies again to Andy for suggesting the legal statement was a policy he initiated rather than ancient and lost Jakarta PMC policy. 3) Work on a TLP proposal. - On subproject subsuming. My basic premise is that a Jakarta subproject can only be healthy within Jakarta currently if it is also viable as a TLP (where healthy = fits into the current ASF structure). An umbrella without large internal overlap is too weak unless we create our own internal sub-PMC system and reporting structure and that's one of the things that lead to splitting Jakarta up in the first place (as far as I recall). I'd personally much rather see POI as an active TLP than being squashed into a flattened umbrella, but I definitely don't want to see it being stuck in the old subproject structure. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [VOTE] Remove POI svn restrictions.
Hello Avik, 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 I don't think that the level at which POI resides will make any difference. I admit that at the beginning of this thread and after Andy's first responses I also thought hey, let's get them promoted to TLP and we're finally rid of these discussions in Jakarta. I've since had time to reconsider and realize that this is not a solution. And actually I don't think that it is even an option. POI is not running the Apache way. Promoting it to TLP or hiding it in commons will not change anything. If it were a TLP, you'd be having basically the same discussions directly with the board. Do you think they'll look more kindly on failure to follow the established Apache procedures? If we 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. A release can go wrong all right. That this wasn't detected by the POI community itself is reason for worry. But the kind of things that went wrong, like files being in the wrong place or missing is even more reason for worry. The copyright statements on the POI web site indicate that the project has been around since 2002. Does that mean that in 4 years nobody cared to write a build process that generates release jars conforming to Apache standards? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report December
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 -- Dennis Lundberg - 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]
[Jakarta Wiki] Update of BoardReportTemplate 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/BoardReportTemplate -- News related to various subprojects, if they have news. Volunteers for subproject news are desired, otherwise the Chair is responsible for finding out said news (and should mark that they had to do so). - Subproject A + BCEL - Committer lands on Moon + BSF - Subproject B + Cactus - Sending committer to Mars + Commons + ''Attributes'' + + ''!BeanUtils'' + + ''Betwixt'' + + ''Chain'' + + ''CLI'' + + ''Codec'' + + ''Collections'' + + ''Configuration'' + + ''Daemon'' + + ''DBCP'' + + ''!DbUtils'' + + ''Digester'' + + ''Discovery'' + + ''EL'' + + ''Email'' + + ''!FileUpload'' + + ''!HttpClient'' + + ''IO'' + + ''Jelly'' + + ''Jexl'' + + ''JXPath'' + + ''Lang'' + + ''Launcher'' + + ''Logging'' + + ''Math'' + + ''Modeler'' + + ''Net'' + + ''Pool'' + + ''Primitives'' + + ''SCXML'' + + ''Transaction'' + + ''Validator'' + + ''VFS'' + + ECS + + HttpComponents + + JCD + + JMeter + + ORO + + POI + + Regexp + + Slide + + Taglibs + + Turbine + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of BoardReportTemplate 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/BoardReportTemplate -- ''VFS'' + + ''Dormant'' + + ''Sandbox'' + + ECS HttpComponents - 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]
Re: [VOTE] Remove POI svn restrictions.
On 12/17/06, Roland Weber [EMAIL PROTECTED] wrote: Hello Avik, 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 I don't think that the level at which POI resides will make any difference. I admit that at the beginning of this thread and after Andy's first responses I also thought hey, let's get them promoted to TLP and we're finally rid of these discussions in Jakarta. I've since had time to reconsider and realize that this is not a solution. And actually I don't think that it is even an option. POI is not running the Apache way. Promoting it to TLP or hiding it in commons will not change anything. If it were a TLP, you'd be having basically the same discussions directly with the board. Do you think they'll look more kindly on failure to follow the established Apache procedures? If we 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. I can't speak for the others - but that's what I was saying in the email I was writing at the same time as you :) A release can go wrong all right. That this wasn't detected by the POI community itself is reason for worry. But the kind of things that went wrong, like files being in the wrong place or missing is even more reason for worry. The copyright statements on the POI web site indicate that the project has been around since 2002. Does that mean that in 4 years nobody cared to write a build process that generates release jars conforming to Apache standards? I bet a lot of Jakarta does not conform - it's only when a release happens that we think about bringing it up to date. This is not a problem of the POI community but a problem of the Jakarta community structure and for the PMC. It's the PMC's responsibility to make sure these releases are right and not the POI community. A plus point of POI as a TLP is that then it becomes the POI community's responsibility far more (as I imagine there would be far more of 1:1 ratio of committers to PMC there). Let's not go over the top here - the release itself isn't that bad and it's got the important things right (license, notice). Having gone and looked at them, I'm not overly worried about the two particular releases themselves, just that it's clear that information is not getting out to POI and that it urgently needs to somehow. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Hi, On 12/17/06, Mark Thomas [EMAIL PROTECTED] wrote: Martin van den Bemt wrote: 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. A mentor (or similar) has been mentioned a few times in this thread. If POI would like my help then I am happy to assist. For those of you who don't know me, I have been lurking in Jakarta since Tomcat moved to a TLP and am currently release manager for Tomcat 4. That's an excellent idea and offer, +1! Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Hello Henri, I bet a lot of Jakarta does not conform - it's only when a release happens that we think about bringing it up to date. This is not a problem of the POI community but a problem of the Jakarta community structure and for the PMC. It's the PMC's responsibility to make sure these releases are right and not the POI community. OK. A plus point of POI as a TLP is that then it becomes the POI community's responsibility far more (as I imagine there would be far more of 1:1 ratio of committers to PMC there). You see a chance to move POI to TLP in the current situation? I've always see going TLP as a way to gain visibility, and would have expected the board to make sure that projects doing that step are working well. You've definitely more insight here. Let's not go over the top here - the release itself isn't that bad and it's got the important things right (license, notice). Having gone and looked at them, I'm not overly worried about the two particular releases themselves, just that it's clear that information is not getting out to POI and that it urgently needs to somehow. OK again. Thanks for putting that into perspective. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report December
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. Regards - Avik Quoting Martin van den Bemt [EMAIL PROTECTED]: 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
Re: Board Report December
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 signature.asc Description: OpenPGP digital signature
