Re: Proposal
I agree, but I think we need to give some more concrete guidance how to develop an open community and develop in the open, because although it is clear to ASF people, I think it is often not so clear for many other people @msacks: Did you already have a look at https://incubator.apache.org/cookbook/ ? HTH Michael Am 17.05.22 um 07:56 schrieb Dave Fisher: Develop an open community and develop in the open. If the community starts to grow then come back and ask for guidance in how to make your open source community an ASF community. Did I mention open and community enough? All the best, Dave Sent from my iPhone On May 16, 2022, at 10:47 PM, m sacks wrote: Not sure if this made it: Just a term of endearment, mot taken to be meant literally. Sure. Initially the community would be a private group put together by me. Then we can discuss building it once others have decided if it’s even a useful application first? On Mon, May 16, 2022 at 10:20 PM Daniel Widdis wrote: I'm not an ASF warlord or general. In fact, I don't think such things exist. It's about community. Decisions are made by communities. Warlords, generals, and benevolent dictators don't fit well. Related, I don't see anything "community" in your post. You state "I" have got code, not "we". You can have the best code in the universe, but if you don't have a community developing it, it's not really a good fit here. So tell us less about your code and more about your community developing it. On 5/16/22, 10:05 PM, "m sacks" wrote: I have some gpt3 based python code to simulate leonardo da vinci as a chatbot proof of concept. I think it could be useful, but i am not sure, so i leave it to the council of ASF warlords and generals to decide if the code should be incubated? I have not shared sources as of yet. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Anyone interested in a scheduler project?
just curious, but what are the differences to quartz and why would you like to donate it to the ASF? Thanks Michael Am 28.10.12 04:29, schrieb Zemian Deng: Hello there, I started a scheduler project called TimeMachine Scheduler here: https://bitbucket.org/timemachine/scheduler Would anyone here be interested to make it as part of Apache family? Best Regards, Zemian Deng - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Stefane Fermigier wrote: On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote: Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: *Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats. I cannot see any contradiction. Can you explain where exactly you see the contradiction? As I understand it, the Apache Way means that building consensus has more value than a code base that can be donated but can't be modified because, well, there are good reasons not to do it. are you refering to the OpenCMIS code? If so, then please say so and give the OpenCMIS folks a change to prove different. - Let our Apache Foundation overlords decide. who are you refering to? I'm not familiar with the process, but I understand that some people are going to be responsible for deciding who will graduate and who won't. maybe you want to take a look at http://incubator.apache.org/guides/graduation.html since I guess this also matters to Chemistry ;-) I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. Maybe you want to go one step towards OpenCMIS and make a concrete suggestion what you think could be shared and I am quite certain the OpenCMIS guys will also make a step towards Chemistry as well and I am confident collaboration will happen, but yes somebody has to make a first step and maybe it is even an advantage to take this first step ;-) I think suggestions have already been made. are you refering to Jukka's suggestions? Of which suggestions exactly? @OpenCMIS folks: What is your point of view re Jukka's suggestions? Cheers Michael S. -- Stefane Fermigier, Founder and Chairman, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 New: follow me on Twitter: http://twitter.com/sfermigier - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Niclas Hedhman wrote: The Board has in the past condemned balkanization of community, and my take on this situation is exactly that. This is not yet another web framework, which often brought forward as examples that the ASF encourages competition within. Those typically have a different angle, approach or metaphor, something making each very different beasts. But in this case we are talking about the same spec. There is no real distinguishing features and huge overlap of commonality. there isn't just one JCR implementation and I am glad there is a choice and some healthy competition. Yes, the ASF only hosts one JCR implementation, but would it matter if another would be part of the ASF? I don't think it would matter, but it would rather show that the ASF is really open-minded about different approaches. I think this is a NIH-syndrome in play, in the best case oh we have the code working already and the worst case we don't like to collaborate with them, and there is reason to think that that goes for both sides of the fence. if so, then let's be specific on this and parties should explain themselves re this particular allegation I want to see Chemistry capable to absorb such contribution and collaborate heavily to bring such codebase in. And I want to see the people of the OpenCMIS proposal to show that they indeed can work with others. Exactly how the merged community goes about with the technical integration is its own business, but I am worried that the new codebase will not receive the welcome I hope, the Chemistry base will dominate, and the OpenCMIS proposer get fed up and leaves. Important Mentors understand the risks here, and keep eyes extra open for attrition, domination and forceful consensus-seeking. I think discussion should continue on Chemistry dev@ list. If agreement can't be reached there, then I am NOT in favor of incubating OpenCMIS separately and will vote -1 to such proposal. that seems to me very wrong. If you have two folks speaking to each other and in the end they find out that they cannot work together for some reason, then we send one of them into the desert just because the other one was there first (especially if you have enough space actually). Let's first see how the discussion goes and then decide how to continue. I will also form myself an opinion of how well Chemistry is trying to collaborate, and it may improve or deteriorate its status with me. This can become an excellent opportunity for all involved to show off their ApacheWay skills I would be glad if we could stop refering to the ApacheWay, because AFAIK there is no strict definition of the ApacheWay. I would rather prefer if we could be specific, for example that both parties make a concrete list, where they are different code-wise and why they think it is not possible to merge the code initially and also make a plan what the common interfaces could be initially and in the future. Thanks Michael -- Niclas On 13 Dec 2009 09:47, Emmanuel LŽcharny elecha...@gmail.com wrote: Joe Schaefer a écrit : snip/ I see where Joe is going to with his let both project get in and let's see which one will su... I must admit that it's human nature, but I think - but I'm probably optimistic - that people working on an apache project should overcome this reluctance. In this very case, as Chemistry has entered the incubator more than 6 months ago, I can understand that 'merging' with OpenCMIS would slow down the process, and OTOH, OpenCMIS may not like the idea to be seen as a sub-project... But this is the Incubator, the perfect place yo work out such problems. My fear is that by accepting two separate projects, one may die (or even both), because of the lack of community... It seems less likely if both project work out a common solution, IMHO. Collaboration does not kill good ideas... - To unsubscribe, e-mail: g... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: *Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats. I cannot see any contradiction. Can you explain where exactly you see the contradiction? - Let our Apache Foundation overlords decide. who are you refering to? I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. Maybe you want to go one step towards OpenCMIS and make a concrete suggestion what you think could be shared and I am quite certain the OpenCMIS guys will also make a step towards Chemistry as well and I am confident collaboration will happen, but yes somebody has to make a first step and maybe it is even an advantage to take this first step ;-) Cheers Michael S. On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote: Florian Müller wrote: Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section The Foundation Incubator): It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality. right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. Or am I missing something which violates any current rule of the incubator? Cheers Michael Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- Stefane Fermigier, Founder and Chairman, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 New: follow me on Twitter: http://twitter.com/sfermigier - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Stefane Fermigier, Founder and Chairman, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 New: follow me on Twitter: http://twitter.com/sfermigier - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Emmanuel Lcharny wrote: Michael Wechner a écrit : Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: *Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats. I cannot see any contradiction. Can you explain where exactly you see the contradiction? Hi, I just grab the description of both projects : OpenCMIS will deliver a Java implementation of the OASIS CMIS specification. Apache Chemistry is a generic Java language implementation of the upcoming OASIS CMIS specification. I barely see how two communities working on two projects with the very same target can't collaborate and form the best possible community to fulfill this target, leveraging the great people from both of the current project... This is where I see a contradiction : it seems like there is some divergence on the technical side, which is not really the Incubator concern. What is important to us is that a community is built, because it's the guarantee for a long term existence for the project. We don't have the resources and time to setup a darwinian process here :) I am not sure what exactly you mean with we, but I would argue that the CMS community out there is rather large and has enough potential to provide contributors for both projects. It's up to each incubator project itself to build a healthy community and AFAIK these rules are clear and in particular what it takes to leave the incubator. So either a project will make it or not. I am assuming this is what the incubator is good for, right? Cheers Michael my 2 cts ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Florent Guillaume wrote: On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner michael.wech...@wyona.com wrote: Right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. My concern is that if there are two separate svn trees then factoring things between the two projects will be much harder. Let's not kid ourselves, having two different maven release cycles, and having dependencies to foreign SNAPSHOT projects, will not help. To me it's a waste of time and effort. Let me ask the question differently: what's lost by having the code in the Chemistry svn tree? Beside that I agree with Joe's email I would additionally argue that you can easily share code without being within the same project and having it separate from each other it forces you to make the architecture/code even better, which I think has (nearly) only advantages. Cheers Michael Florent - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Florian Müller wrote: Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section The Foundation Incubator): It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality. right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. Or am I missing something which violates any current rule of the incubator? Cheers Michael Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- Stefane Fermigier, Founder and Chairman, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 New: follow me on Twitter: http://twitter.com/sfermigier - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Bertrand Delacretaz wrote: As Gianugo says, the Chemistry folks are certainly the best people to judge (together with you guys of course) whether your ideas can be incorporated in Chemistry, or are better off in a separate project. The Incubator's position is very probably that it's fine to have different projects working on similar things, but in general we're all for strong communities, and if you guys can join forces with Chemistry from the start that's probably a better way to build a strong community. well, let's be honest: Merging communities can be a very difficult thing (from both sides) I don't think it's a problem to have two CMIS projects. I think the important thing is that each project is able to build a healthy community around code of great quality and that the communications/processes are transparent. I understand that from the outside it looks odd to have two or even several projects of the same topic, but evolution is variation (with some balance though ;-) Cheers Michael -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Gianugo Rabellino wrote: On Thu, Dec 10, 2009 at 11:17 AM, Michael Wechner michael.wech...@wyona.com wrote: Bertrand Delacretaz wrote: As Gianugo says, the Chemistry folks are certainly the best people to judge (together with you guys of course) whether your ideas can be incorporated in Chemistry, or are better off in a separate project. The Incubator's position is very probably that it's fine to have different projects working on similar things, but in general we're all for strong communities, and if you guys can join forces with Chemistry from the start that's probably a better way to build a strong community. well, let's be honest: Merging communities can be a very difficult thing (from both sides) I don't think it's a problem to have two CMIS projects. I think the important thing is that each project is able to build a healthy community around code of great quality and that the communications/processes are transparent. I understand that from the outside it looks odd to have two or even several projects of the same topic, but evolution is variation (with some balance though ;-) Michael, don't get me wrong, I have no objections in principle for having two or more competing projects. It's just that my bar is higher in this case, as: - we are talking about two podlings, which IIRC is a first; - they both aim to implement a moving target; - the prospective OpenCMIS community started seemingly with the wrong foot by not addressing the Chemistry community first and looking for potential mutual engagements, despite being in the best possible situation, such as having a committer in common; - when asked to try and contact Chemistry, Paul chalked it up as time consuming; - the proposal came in with no candidate champion or mentors. None of the above issues is a blocker, but the sum of the parts doesn't give me exactly a warm, fuzzy feeling. I would appreciate the proponents having a discussion with Chemistry first. If OpenCMIS, however, prefers to skip that step and manages to score champions and mentors, I won't stand in the way. sounds reasonable to me :-) Cheers Michael - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
Ian Boston schrieb: not least because committed mistakes demand fixing by the committer and then anyone who can fix the bug. The only downside is that occasionally trunk wont build/run and if trunk is close to production that probably matters. I think another downside is, that (maybe depending on the community) in reality a proper review often doesn't happen in the case of CTR and in the case of performance/scalability this can be very bad, because the actual problems are often detected at a very late stage and then it can be very hard to solve these issues, because the code has already advanced too far. I see the postive sides of CTR re community and progress, but I think it requires some additional rules, guidelines in order to make it work. Cheers Michael Shindig is mostly RTC, and was very close to big production. Sling is mostly CTR Ian Cheers, -g On Wed, Nov 11, 2009 at 11:09, Matthieu Riou matth...@offthelip.org wrote: Hi guys, What's the take of other mentors and the IPMC on podlings practicing RTC? I'm asking because some seem to see it as a blocker for graduation whereas I see it much more as a development methodology with little community impact and therefore no real influence on graduation. Strong opinions here? Thanks, Matthieu - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: moving a failed incubation project
J Aaron Farr wrote: If the fork wishes to do more than patch up the original or wishes to create its own identity unique from the Apache original, then it would be wise to rename the packages, but there is no legal requirement to do so. believing you that there is no legal requirement (I am no lawyer ;-), but that's also my understanding of the ASF license and incubator agreement), then that's how it is for the moment. But for the future I think it's in the best interest of the ASF to think about this more thoroughly, because it can be very misleading if one is using Java packages with org.apache.*, but this code - might have nothing to do with the ASF - might be a fork of existing ASF, but has been changed quite a bit in the meantime To me the first step would be to talk to these people and ask them kindly to change the package names. If they will change it, then almost everyone will be happy, except people with dependencies, but that can be fixed by keeping previous versions available and adding a note. The problem is when people don't want to change and this is where the ASF should ask itself do we care (well, I do) and if the ASF does care, then what can be done? Are there legal means? Are there other means? Cheers Michi -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 [1] this is trademark, not copyright issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving a failed incubation project
Paul Fremantle wrote: I agree with the general point about the legality of using the org.apache namespace. However, I think there is a significant issue here. People assume that org.apache code is from Apache. agreed. Hence I would also suggest that when moving the code that the package names should be renamed, but I also would suggest to make the current code as it is available somewhere (either within the ASF or somewhere else), but with a clear note telling the history of this code, such that dependent products don't break. Also I think Maven could help with that, for instance I have made tsik available within our own maven repo http://maven2.wyona.org/apache-org-incubator/tsik/r389866/ such that projects as for instance joid can reference it http://maven2.wyona.org/joid/joid/r84-patched/ and in case joid is ever being updated to the new tsik package names, one can easily switch Cheers Michi And the reasoning that its too much effort to rename is frankly wrong. Even sed could do a decent job and probably sort the problem out. I think the usage of org.apache should be considered in the same way as the Apache Logo - something that the ASF controls rigorously to protect our brand image. Paul On Jan 22, 2008 8:12 PM, Niall Pemberton [EMAIL PROTECTED] wrote: On Jan 22, 2008 6:23 PM, Craig L Russell [EMAIL PROTECTED] wrote: I think the terminology in the subject is wrong. You are not moving a failed incubation project. That project is dead. What you can do is to use the code in another project, and assume all responsibility to verify that the license in the code is correct. What you can't do is to use the Apache brand for another project, meaning to use the package names including apache if it's not an Apache project. I thought the whole point of the AL was that pepople could take code away and do whatever they want with it - it doesn't say in the AL you can do whatever you want with it as long as you rename the packages. Niall And please be aware that the code might be tainted. Since it never left incubation, the code's provenance might never have been vetted. So you don't really know what you're getting, in terms of ownership, license, patent, etc. If you use the code you're responsible for making sure it's really ok. Craig On Jan 21, 2008, at 6:23 PM, Hans Granqvist wrote: Hi I want to move a failed incubation project (TSIK) to Google Code, but the source is full of org.apache.* packages, so I'm not sure what the right way to do this is. (The code would keep the same ASF 2.0 license.) Changing the package names will break any and all code, so if it'd be great if that's avoidable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving a failed incubation project
Paul Fremantle wrote: Niall Asking someone politely to rename the package is hardly throwing our weight around. very much agreed and I guess if one can show a migration path (as I have suggested) which doesn't break too much, then I think nobody should mind renaming the packages. But with the ASF member hat on I think the package org.apache.* is something which the ASF should protect, just as the logo and the brand name itself resp. add a policy to the incubation process which people have to agree to when entering the incubation phase. Cheers Michi Paul On Jan 22, 2008 8:50 PM, Niall Pemberton [EMAIL PROTECTED] wrote: On Jan 22, 2008 8:27 PM, Paul Fremantle [EMAIL PROTECTED] wrote: I agree with the general point about the legality of using the org.apache namespace. However, I think there is a significant issue here. People assume that org.apache code is from Apache. And the reasoning that its too much effort to rename is frankly wrong. Even sed could do a decent job and probably sort the problem out. I think the usage of org.apache should be considered in the same way as the Apache Logo - something that the ASF controls rigorously to protect our brand image. If we throw our weight around that IMO goes against what our own license permits, then thats going to damage the ASF's brand image and its liberal license. I can't see how this could ever be official policy, but we should stop saying it until it is. Niall Paul On Jan 22, 2008 8:12 PM, Niall Pemberton [EMAIL PROTECTED] wrote: On Jan 22, 2008 6:23 PM, Craig L Russell [EMAIL PROTECTED] wrote: I think the terminology in the subject is wrong. You are not moving a failed incubation project. That project is dead. What you can do is to use the code in another project, and assume all responsibility to verify that the license in the code is correct. What you can't do is to use the Apache brand for another project, meaning to use the package names including apache if it's not an Apache project. I thought the whole point of the AL was that pepople could take code away and do whatever they want with it - it doesn't say in the AL you can do whatever you want with it as long as you rename the packages. Niall And please be aware that the code might be tainted. Since it never left incubation, the code's provenance might never have been vetted. So you don't really know what you're getting, in terms of ownership, license, patent, etc. If you use the code you're responsible for making sure it's really ok. Craig On Jan 21, 2008, at 6:23 PM, Hans Granqvist wrote: Hi I want to move a failed incubation project (TSIK) to Google Code, but the source is full of org.apache.* packages, so I'm not sure what the right way to do this is. (The code would keep the same ASF 2.0 license.) Changing the package names will break any and all code, so if it'd be great if that's avoidable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
Leo Simons wrote: Jo! The whole jira-patch-commit workflow for the documentation seems annoying. At least it annoys me -- in particular the patches don't show up in my email so I have to visit jira which I try and avoid as much as possible :-). Suggestions: 1) create http://svn.apache.org/repos/asf/incubator/public/staging writeable by *all* committers svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \ http://svn.apache.org/repos/asf/incubator/public/staging vi infrastructure/trunk/subversion/authorization/asf-authorization svn commit infrastructure/trunk/subversion/authorization/asf- authorization 2) create an svn:externals on http://svn.apache.org/repos/asf/incubator/public/trunk/site- publish like this website-staging http://svn.apache.org/repos/asf/incubator/ public/staging/site-publish so that you can see the work-in-progress at http://incubator.apache.org/website-staging/ 3) instead of sending documentation patches, people who are helping with the documentation work on the staging branch 4) set up svnmerge.py for staging/ and trunk/ * see http://www.orcaware.com/svn/wiki/Svnmerge.py * make sure to block the revision from step #2! 5) propose documentation changes on the mailing list * get diffs cd incubator/trunk svnmerge.py --bidirectional diff ~/staging-diffs.txt # or use -r to get only a few revisions * send diff to mailing list for discussion and lazy consensus approval 6) merge cd incubator/trunk svnmerge.py --bidirectional avail svnmerge.py --bidirectional # or use -r12345,... svn commit -F svnmerge-commit-message.txt cd ../staging svnmerge.py svn commit -F svnmerge-commit-message.txt 7) rejoice at the lightweight workflow, which also survives Robert's laptop sinking to the bottom of the sea! what about a CMS with a workflow, which would sit on top SVN accessing both branches (staging resp. draft and live) and hence would allow devs still accessing it through other SVN clients and also allow updating the live site as static SVN update? We have implemented versioning and workflow into Yulup (http://www.yulup.org), which is available within the recent trunk version or next week's release. Yulup does decouple this functionality from the actual server implementation. I would be happy to help to set something up in case this would make sense for the incubator folks. Cheers Michael cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
Leo Simons wrote: On May 5, 2007, at 7:55 PM, Michael Wechner wrote: what about a CMS with a workflow, which would sit on top SVN accessing both branches (staging resp. draft and live) and hence would allow devs still accessing it through other SVN clients and also allow updating the live site as static SVN update? Ah, that's an old subject! Several people have done prototypes along these lines (I've done about one and a half in python, but in python the most promising codebase is probably (still) SubWiki), and I'll argue something like this (edit this page links backed by subversion) is what we really really want. Mozilla has (or had) it for their site. [EMAIL PROTECTED] was set up with this in mind, ages ago, and there's still some requirements/designs lying around for how it would work. David Crossley is a good person to ask about it. I think one of the problems why this effort has stalled has been that apache has so many CMS or CMS-ish tools that it is really hard to come up with a common way to do things that satisfies enough people to make setting it up worthwhile, so you get into loads of arguing. well, it seems to me that SVN is the common denominator at the ASF and only a tool which is able to connect to SVN will satisfy enough people within the ASF. That's one of the reasons I have spent time how a CMS can use SVN as a data repo. We have implemented versioning and workflow into Yulup (http:// www.yulup.org), which is available within the recent trunk version or next week's release. Yulup does decouple this functionality from the actual server implementation. I would be happy to help to set something up in case this would make sense for the incubator folks. I'd rather not see a tool like this for a project-specific setup -- anything that writes to SVN needs to be very carefully evaluated for security and stability reasons and be maintained and supported by [EMAIL PROTECTED] I understand, but I would assume writing to draft/staging SVN on a dedicated zone would be less an issue and then allow dedicated people to merge from there into the live SVN as you describe it above. If you're interested in signing up for the bigger job, please work with site-dev@ (and infrastructure@). I can tell you right now that something off of trunk of a non- Apache project that's in a 0.x release series, doesn't document how it uses SVN, and is licensed under the GPL is not that likely to receive a warm welcome immediately. I could set something up will also probably receive a healthy amount of scepticism; I wrote a blog post about why that is ages ago: http://www.jroller.com/page/lsd/20050717#why_we_say_no_to all that said, don't let me discourage you (too much)! We could definitely use this, but you'll have to volunteer for (quite) a bit more work and get some others to help out ;-) I very well understand what you are saying ;-) and I don't want to impose anything, but I believe that I finally have the tools at hand to do this and I am currently working on this for my own needs. Hence I wanted to ask and see how big the skepticism is and I don't mean this cynical, but just would like to be constructive. Anyway I will start with http://incubator.apache.org/guides/website.html and will see how far I will get and will hopefully come back within reasonable time :-) Cheers Michael cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] add Dominique Pfister to Jackrabbit committers
Stefan Guggisberg wrote: Naturally, only the votes coming from the incubator PMC and Jackrabbit committers currently listed on our project status page will be counted as binding. +1 which is certainly non-binding. Just a note from the Lenya-Wyona experience: It seems to me that Dominique should try to become more transparent on the mailing list, especially since he is also working for Day Software (some are more equal ;-). Also I think it is important to differentiate between PMC and committer. I am not sure if Jackrabbit does this at the moment. I think somebody should become quite easily a committer if providing useable code on a regular basis, but political decisions are another thing and it normally takes longer to build trust so that one is able to recognize how independent one's mind is. Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updating incubated projects page
Dear incubator Can you please update http://incubator.apache.org/projects/index.html re Apache Lenya. Thanks a lot Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: STATUS: Jackrabbit
Roy T. Fielding wrote: task from now to graduation is to get the community more involved in development, planning features, integrating with some of the DB projects, as Rolf was stating, it would help a lot to have a get started page, or a Wiki where people can note their findings, even if certain things might seem to be very obvious to the current committers. Also is there a Roadmap or something similar like that? and scoping out interesting applications to build on top maybe one could insert links to the various projects (e.g. Slide, Cocoon, Lenya, etc.) how they actually use Jackrabbit. Thanks Michi of the interface. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for graduation and Lenya TLP
Greg Stein wrote: In any case, the Board passed the resolution :-) cool :-) Thanks Michi I'll be sending out a summary of our meeting which will also mention it, but figured that I'd let you guys know sooner rather than later :-) Cheers, -g -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ready for Lenya Release 1.2.1
The Lenya Devs are actually ready to release 1.2.1 which has a lot of bugfixes. Do you think it makes sense to wait a bit more for the board report from August 18 (Lenya as TLP?) or shall we rather do another incubator release? Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summary on Lenya vote?
Noel J. Bergman wrote: Stefano Mazzocchi wrote: Ok, less formal: did Lenya pass the vote or not? As I wrote last week, yes. Assuming that we don't get negative votes between now and when the Board approves TLP status for Lenya. ok, then I will try to prepare the charter in order to submit to the board, and hope that no negative votes show up in the meantime ;-) Thanks Michi --- Noel -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summary on Lenya vote?
Noel J. Bergman wrote: I assumed that no votes would be counted as positive silent votes Nope. There is a notion of Lazy Consenus, but silence is not a vote. Please apologize if I don't fully understand, but how do you define lazy consensus? Does it make sense if I try to encourage the PMC members http://incubator.apache.org/whoweare.html#PMC+%28Project+Management+Commitee%29 to cast their vote? Thanks Michi --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: summary on Lenya vote?
Noel J. Bergman wrote: It seems that everyone agrees to release Lenya from the incubator. Can we do a summary on that, such we can use the summary for applying as TLP. Actually, I just went back through the vote thread, and from what I can see, we have votes from Leo Simons, Steven Noels and myself. I did look further and found Nicola Ken's vote at http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .orgmsgId=1760664, so that's four. I cannot find one from Stefano, and I'm not particularly keen to ever infer someone's vote just because they started the thread. No one else seems to have voted. ref: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] che.orgby=threadfrom=822879 Please feel free to correct me if you find any other votes in the archives. I guess you are right, whereas I assumed that no votes would be counted as positive silent votes, because the thread was phrased as a positive one. But I am not sure what the policy of the incubator is re voting. As for applying for TLP status, I had indicated in a message to Steven Noels earlier that, yes, the Lenya PPMC should prepare a proposal to the Board for TLP status. If no one objects to Lenya being promoted between now and the Board meeting, you should be good to go. ok Thanks Michi --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lenya exiting incubation
Stefano Mazzocchi wrote: Both Nicola and I are aligned in indicating that there is not much else that we can teach to those guys and that nobody here seems to have a problem with it, I would ask for a vote. I'm not completely up-to-date with the procedures, so, please, don't flame me if this is not the right way of doing it, but I would like to start a vote on exiting incubation. can we start one or does the silence of the incubator list mean just do whatever we feel like ;-) ? Or is it currently discussed on the incubator PMC list? Michi Should it be done here or on the PMC? -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Steven Noels wrote: Lenya has an awkward history IMHO. It has been force-fed into the bowls of the ASF upon the idea that a community was more important than code, and because of pet-peeves of people: the ASF needed a CMS project, and Lenya would be a community seed for that - regardless of the community aptness to serve as one. The original Lenya folks were clueless about the Apache Open Source Way, but felt so much invited into the ASF that they figured they were doing a good job. The original number of committers was bloated, and their communication about the incubation status of Lenya was tendencious at best. Wyona didn't do a great job at opening up the project to the outside world (other than dumping code into public CVS), and there wasn't much direction or shared project ownership. well, I think it was and is quite different, but it doesn't make sense to argue about perceptions. I am not saying that none of us didn't make mistakes, but my perception is nevertheless quite different, especially since I see ourselves as individuals and not as a company within the Lenya community. It certainly makes sense to learn from concrete mistakes, but not from assumptions or perceptions, because we will probably never stop argueing. Also I think all of us acted very promptly on requests from various sides. So, I think the important thing is to look ahead and see the positive side as Steven is stating below. What I see now is people empowering themselves and caring only about the project, not about all the peripheral dreams or company ambitions. This is a tremendous shift in project governance. I think the ASF needs to acknowledge and endorse this shift and give these people the ability to continue their course. agreed Whether this course will be successful, we will only know within a year or so. I hope these folks will be able to attract new committers and continue what they started. I am very optimistic on this, but I guess you know that ;-) Michi I'll be carefully looking after ASF brand abuse however in the forthcoming months. This entire incubation episode has left me with dubious feelings: for a long time, I've been thinking that Lenya would be a sad example of premature ASF donation. It is good to see that some volunteers finally stepped up and managed to create real momentum, and I can only hope they will last for a long time. Lenya will still need to acquire more external contributors to help them with this effort. I'm glad to hear about the latter part of that paragraph, but you have to admit that the first part of the paragraph is enough to give one pause. So please explain why we should have a incubator release while there are still so many questions regarding the viability of the community? Yes, you are indicating that there are new members within the Lenya community who are focused on doing everything properly. Great, but I'm still trying to understand why there is a need to put out a distribution rather than put all of the energy into helping Lenya conclude incubation and then release. As I said, it's just a matter of the community maturing, and feeling two urges at the same time. Order isn't very important here. I hope this clarifies things a bit, feel free to nag me with other questions. Cheers, /Steven -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Leo Simons wrote: In this case, Noel has raised some perfectly valid concerns about files living on http://www.apache.org/dist/ without a PMC putting them there (which is a *big thing*, for legal and other reasons). If I were lenya, I wouldn't complain about constraints, but just address those concerns. well, IIRC then concerns have been addressed promptly. As a general note I would like to say, that future concerns should be addressed to individuals and not to Wyona as a company. Also I think it would be of great help if issues are being sent to the Lenya community directly and or the individuals involved. Thanks Michi You will see constraints vanishing in smoke. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Steven Noels wrote: I think it is only decent to expect that developers of incubating projects are subscribed to the incubator mailing list and have an interest in the overall incubation process. agreed Part of the little things I did during this incubation is proxying back- and forward, and this becomes very boring after a while I certainly understand that and this why I suggested that the communication should be more direct - at the verge of starting to think people are dispassionate about incubation status. Sorry, no problem ;-) Michi /Steven -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Steven Noels wrote: On 14 Jun 2004, at 12:02, Michael Wechner wrote: Of course not, and I hope I've been careful enough to talk only from my own private perception - something I can and will not change even if I know the people behind the voices on the mailing lists. I think it's necessary that you don't change that, but I just wanted to let people know that there are also other perceptions possible And as you acknowledge, I have seen plenty of change during the recent months, something I am very happy about. I am very optimistic on this, but I guess you know that ;-) I am happy to see you happy. :-) vice versa :-) Michi /Steven -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Steven Noels wrote: On 14 Jun 2004, at 14:29, Michael Wechner wrote: I am not sure about this. I think it would be better if people would view us as individuals. I try to do so in the case of other projects with various companies involved, and I think it works well, at least for myself. I understand your subtle hint and agree with what you say about yourself. ;-) It's nice to hear that :-) Michi Frankly: it is because of this apparent shift in attitude that I'm feeling Lenya is finally getting ready. /Steven -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubating Lenya for Cocoon
Nicola Ken Barozzi wrote: The Cocoon project has voted to accept the Lenya proposal, thus Lenya is officially in the Incubator :-) First of all, we need to get the legal stuff straight. 1) License grant We need to recieve papers that transfer rights to the ASF. It is necessary to transfer rights for the package, the core code, and any new code produced by the project. Attached is the software grant, and an example that has been used for another project. It has to be printed, signed, and faxed into the ASF (+1-410-803-2258) or mail to: The Apache Software Foundation 1901 Munsey Drive Forest Hill, MD 21050-2747, U.S.A. 2) Committers We need a list of all active committers that will work on the project. They will have to sign a contributors agreement and send it to the ASF as for the above license grant. http://incubator.apache.org/forms/ASF_Contributor_License_2_form.pdf Welcome! :-) Thanks a lot for the friendly welcome :-) Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Lenya
Andreas Kuckartz wrote: snip / Sure thing. Since Lenya does publishing too, what is the future of Forrest in your scenario? To be honest, I am not very familiar with Forrest yet. But from out of the belly I would characterize Forrest as a specific publication type, with an information architecture suited for software projects, with various skins/layouts to choose from and a specific set of functionalities, such as for instance to create the site automatically out of CVS (right?). Hence I guess Lenya could be used to manage an instance of the Forrest publication type whereas Forrest could be considered as a best practice publication type. But maybe I am totally wrong, because as I said above I am not very familiar with Forrest and I am sure there are many other people which are much better able to steer collaboration into the right direction. Thanks Michael I would like to see close collaboration between this projects. Andreas - 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]
