Re: [ISIS] Re: Conference call
On 11/24/10 3:18 PM, Bernd Fondermann wrote: On Wed, Nov 24, 2010 at 15:02, Benson Margulies wrote: On Wed, Nov 24, 2010 at 8:54 AM, Bernd Fondermann wrote: On Mon, Nov 22, 2010 at 16:16, Benson Margulies wrote: I am nothing if not chronically disingenuous. My first concern in responding here is a process concern. As far as I can tell, the Incubator PMC has not formally voted to forbid the use of real-time communications in podlings. Absent such a vote, the use of these technologies is permitted, and it's up to the mentors to guide, monitor, and ring alarm bells, as needed. Concluding that in the absence of a vote everything is allowed is not correct. Bernd, I never wrote that 'everything is allowed.' You said: No vote forbidding A => A is not forbidden. This reasoning is not correct. It's not all black *or* grey. In this case, IMO, even if it's not explicitly forbiden, it's strongly discouraged, and it has been a constant position, AFAICT. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] real-time communications
On 11/24/10 7:13 PM, Noel J. Bergman wrote: The premise of this discussion is that running Apache projects are *permitted* to engage in real-time communications, so long as they take due care to avoid community problems of exclusion and closed decision making. Did you see Greg's e-mail? "Just bring a summary of discussion points back to the list, along with any recommendations. The list can then sort through it and make decisions." Decisions are not made except on the mailing lists. If it starts to seem that people are being excluded from being an effective part of a decision process, curtail or modify the back-channel communications. We all want strong communities that are inclusive and open. We all recognize that real-time communications pose risks to that. +1 FWIW, ApacheDS and Geronimo had (possibly still have) *very* active IRC channels (logged) where people talked in real-time, just as they might at a Hack-a-Thon. Talking about ApacheDS, yes, we *do* use IRC actively. This is for us the main stream when we are working on some part of the server, plus a way to have a semi-F2F discussion about technical points. But this is like if you are working in an office in front of a collegue : most of the time, you don't chit-chat, you work. And when it comes to make a decision impacting the whole project, then the discussion is moved to the ML. So why are we using IRC for ? Mainly for technical discussions. As an example, here is a short snippet : ... elecharny: kayyagari: I'm wondering if we coudn't describe the tests using JSON [6:38pm] kayyagari: hmm, am thinking of automatic pdu generation in tests for sequences that use components [6:38pm] kayyagari: so only the lowest components need to be tested with hand crafted PDUs [6:40pm] kayyagari: and cause lowest components definitely be small in size [6:40pm] kayyagari: (atleast that is the case so far) [6:45pm] elecharny: what is important is to test that PDU don't crash when there are some missing optional elements [6:45pm] elecharny: the lower components have been quite well tested [6:46pm] elecharny: the main problem with test generation is to write the PUD by hand, [6:46pm] elecharny: and to compute the lengths [6:46pm] elecharny: one thing we can do is to use the DERxxx classes we have in the project [6:47pm] elecharny: you can create a PDU using them, with no issues like creating the lengths [6:47pm] kayyagari: ahah [6:47pm] kayyagari: am trying to computelength() and then encode them to a temporary buffer and later push it to the main buf [6:47pm] elecharny: you can do that [6:47pm] elecharny: otherwise, you can also do : [6:48pm] elecharny: seq = new DERSequence(); [6:49pm] elecharny: seq.add( DerInteger.valueOf( 5 ) ); [6:49pm] elecharny: etc... [6:49pm] kayyagari: aha, will try it, this is helpful [6:49pm] elecharny: and at the end do a seq.encode( outputStream ); [6:49pm] elecharny: you'll get the PDU [6:49pm] kayyagari: cool [6:50pm] kayyagari: this is the class present in shared-ldap? [6:50pm] elecharny: but you won't be able to test cornercase like Integer with no values [6:50pm] elecharny: yes [6:50pm] kayyagari: ok [6:50pm] elecharny: in asn1.der [6:50pm] kayyagari: yeah [6:51pm] elecharny: ok, I have to run, some friends have flown from Boston to paris Nothing fancy, just raw technical convos. But very useful when you have a huge code base and you want to share some informations IRT. We tried to organize Skype sessions 4 years ago, but we never succeeded to get them lasting more than 2 or 3 weeks. The reasons are simple : - with people in South Korea, France and Florida, the TZ pb is almost impossible to solve - as the schedule was very tight, being 15 minutes late just blows the session - surprisingly, no more than 15% of the world population is speaking a fluent english. That does not help when on skype - You always have to find someone to report what has been said, and trust me, a lot of input is lost in the process We decided that it was a waste of time. I still think it's a waste of time, and also a perfect way to split the community in 2 groups : - those who participate - those who are left behind and get frustrated. IRC solve some of those issues : it's easier to understand what a poor english speaker like me is typing, it's easier to get a report and move it back to the ML, and also it's easier to get the discussion on track, without the one who speak louder talking most of the time. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Wave into the incubator
[X] +1 Accept Wave for incubation -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: An idea you might call pre-incubation
On 2/11/11 5:13 PM, Benson Margulies wrote: Let's say that I have an idea for some new open source initiative. How would I proceed? http://code.google.com/a/apache-extras.org/hosting/ ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: watching the commit profile
On 5/31/11 2:57 PM, Benson Margulies wrote: Is there a quick way to check the diversity of commits to a podling? I mentor one where the ratio of commits between one individual and the rest of the universe seems to be tending toward infinity, and I'd like to check before pointing this out. http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator Useful. Simple. Just great :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Libreoffice] Proposal to join Apache OpenOffice
On 6/6/11 6:17 PM, Florian Effenberger wrote: Hi Jim, Jim Jagielski wrote on 2011-06-06 18.06: The reality is that IBM employees wearing their IBM hats, have made it > crystal clear on the general@incubator list that IBM is going to force > The Apache Foundation to take the project. > How? I am *not* saying you would be influenced or forced - I'd never doubt that you are deciding independent. However, what people may give the feeling that something's wrong are statements like these: http://www.sutor.com/c/2011/06/some-remarks-on-openoffice-going-to-apache/comment-page-1/#comment-5309 "it is a done deal" That might create wrong impressions... Should The ASF made responsible for every comments made on the Internet by people who are not even remotely connected to The ASF ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Libreoffice] Proposal to join Apache OpenOffice
On 6/6/11 6:47 PM, Florian Effenberger wrote: Hi, Emmanuel Lecharny wrote on 2011-06-06 18.40: Should The ASF made responsible for every comments made on the Internet by people who are not even remotely connected to The ASF ? no, and I didn't say that. Again, I just wanted to point out why people believe things as we heard before. Don't put words in my mouth I didn't say. And I didn't say that you suggested such thing either... I'm just saying that people are supposed to use their brain, instead of elaborate some theory based on some random sentences picked from the web. We should also be confident that people are smart enough to understand the ins and outs, otherwise we will simply waste our time explaining them again and again something they can't/don't want to get.. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Flume to join the Incubator.
On 6/8/11 6:38 AM, Jonathan Hsieh wrote: [X] +1 Accept Flume for incubation (binding) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenOffice.org for incubation
[X] +1 Accept OpenOffice.org for incubation (binding). -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 6/27/11 12:37 PM, Niklas Gustavsson wrote: Hi, I would like to propose Deft to be an Apache Incubator project. Deft is a non-blocking, asynchronous, event driven high performance web framework running on the JVM. Here's a link to the proposal in the Incubator wiki: http://wiki.apache.org/incubator/DeftProposal As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up. Needless to say, the same of course goes for committers. You'll find the initial proposal pasted below. Interesting. May be it can revive the AsyncWeb project. If this project needs a mentor, I can be one of them. Otherwise, my +1 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Bluesky Podling
On 6/28/11 7:49 AM, berndf wrote: Hi everyone, this is a vote to retire the Bluesky podling. +1 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 7/4/11 12:29 PM, Mohammad Nour El-Din wrote: Hi Mark... As they stated in "Relationships with Other Apache Products" that they would consider such reuse of some of Apache Mina components. But IMHO, this is not the a blocking issue to go forward with the proposal as such technical detail can be changed while being in Incubator phase if it is found that components of other Apache projects can be used to make things better for Deft or to eliminate the dependency on non-AL software. IMHO, MINA is not really the important part here. It seems to me that the Asyncweb subproject is somehow close to what Deft is proposing. As Asynweb is almost dormant since 2008, I would think that a merge of Deft with Asyncweb is a good approach. Now, as Mohammad said, it's up to the team to decide which part can be reused, or not. It's almost as difficult to write from scratch some piece of code than to reuse some other with lost support... Regarding MINA, You'll most certainly get all the needed support. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 7/4/11 6:04 PM, Roger Schildmeijer wrote: Thanks Mark! To continue the discussion regarding if it make sense to implement such a piece, like Deft, solely on it's own: Things that justifies Deft's existence (In my very humble opinion): * The simplicity * The learning curve (e.g compared to Apache Mina) IMO, Deft != MINA. That Deft uses MINA, or not, should not make any difference for the Deft users. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 7/4/11 4:36 PM, Roger Schildmeijer wrote: Hi Mark, This is absolutely not a dumb question. Deft is not based on Apache MINA. Instead it's using raw Java NIO (without any level of indirection/abstractions). The reason for this is basically to cut down the overhead and to keep it as simple as possible, but still offer a flexible api. I do think that the overhead would be rather minimal. Anyway, I don't think it's where the Deft value added is :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 7/4/11 6:38 PM, Roger Schildmeijer wrote: On 4 jul 2011, at 18.31em, Mark Struberg wrote: I have not looked at Deft a lot, but only from a 10.000 feet point ;) It is just that such things like Filters, etc which are available for Mina already used to be very helpful for lots of projects. Do such things exist in Deft too? There is no such corresponding feature in Deft, at least not at the moment :) In any case, I don't think that Deft *has* to use MINA, or not. It's probably something that could be discussed once the podling is accepted, and by the core developpers. Now, what is more important is to check how close are AsyncWeb and Deft, to see if those two project should be merged, or not, and if Deft has enough potential to be a TLP, or not. I'm not even sure it should be put under MINA's umbrella. I'd say it would be convenient, but has side effects. This should be discussed. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Deft for incubation
On 7/5/11 12:12 PM, Mohammad Nour El-Din wrote: Sorry to interrupt this technical discussion, but I believe that now we are ready to go for a [VOTE] ? Was thinking the same... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Deft to join the incubator
On 7/5/11 12:35 PM, Niklas Gustavsson wrote: [X] +1 Accept Deft for incubation (binding) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept ODF Toolkit for Incubation
[X] +1 Accept ODF Toolkit for incubation [ ] (binding) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Karma to asf-authorization-template
Same request that Alan : I'm part of the IPMC, and I don't have access to this file. Could someone grant me the needed karma ? Thanks ! - 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: This problem of mine
Bertrand Delacretaz wrote: On Tue, May 12, 2009 at 5:14 PM, Alan D. Cabrera wrote: ...I'd like someone to come up with a concise argument that would allow me to let this go other than "nope, it's not the same". Otherwise, I feel that I need to bring up a vote to put the issue to bed once and for all The only thing that I can say is that from the ASF's point of view your project's name is "Apache Ki", no just "Ki". About the actual risks associated with FixFlyer's considering that Apache Ki infringes on their trademarks, the best might be to ask legal-disc...@apache.org. I won't jump into the project again, but in this case, I have a bit more info to provide. The problem has been postponed to le...@a.o months ago, not with a big success. I mentioned the case during ACEU to at least 3 persons, two of them being from the board. All of them told me to send the problem to PRC (so far, no answer), mentioning that it was not worth the risk to fight Juniper or any other company if the name was already used. This is something I don't get, and I see at least two problems here : 1) there is no clear process to solve such issues. Should it be processed by legal or PRC ? Plus those two entities are not responsive, and if we receive answer, they may be contradictory. Again, we don't need opinion, we need a clear and legal position. Opinions don't pay the bill when it comes to pay a lawyer. 2) I *think* than instead bothering everyone in all those instances, the easiest way to solve this issue was to change the name. But it seems that some people don't like simple solutions... As a consequence, it lasts forever (around one year, so far). Otherwise, I totally agree with what Alan has written. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: This problem of mine
Bernd Fondermann wrote: JSecurity was deemed as a potential naming conflict risk (much in the same way Ki is now), so we dropped it, and finally came to a vote to change the name to Ki. But this resolution took over 4 or 5 months to finally come to a favorable vote, so we didn't want to go through that painful process all over again, since it seemed like no one was willing to come to consensus on other names. It is very difficult to find an even remotely-correlated name in the security space that might not infringe on another site/company/product/trademark/patent. ok, I see. At least, for JSecurity, these conflicts never came up, did they? http://www.juniper.net/security/ That's why so many project go with names from biona or mythology. Given the difficulty and the enormous amount of time spent already, we just wanted to move on to focus exactly on the things you mention, and only worry about changing the name yet again if it was absolutely required by the Incubator to do so. That being said, if the Incubator says "the Ki podling must change its name", then fine, we'll be happy to do so, but most of us didn't want to spend the effort worrying about it unless necessary. To me, it seems neccessary, but this is just my 2 eurocent. It took 4 months to move from JSecurity to Ki, just because, very like this thread, people are *discussing* for ever something which would be immediately solved if common sense was applied : avoid as much as possible any risk, and change the name if the risk is becoming a reality. It will take another 4 months to decide to switch from Ki to something more appropriate if we follow the same pattern. That's a waste of time and energy. Bernd, I'm totally on the same page with you. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache JSecurity/Ki Project Rename - VOTE RESULT
Niclas Hedhman wrote: > On Thu, Jun 11, 2009 at 12:48 AM, Les Hazlewood wrote: > >> Apache JSecurity/Ki and extended Apache Community, >> >> The final results are in for the Apache JSecurity/Ki project rename vote. >> Here are the results: >> >> Apache Shiro: 16 votes >> Apache Aseca: 7 votes >> >> The new name by majority vote is "Apache Shiro". 'Shiro' (Japanese >> character *城), means 'castle' in Japanese, and is an appropriate name for an >> application security framework. and * >> > > I would like to congratulate the Apache Shiro community for a well > exercised name change. It was brought to the Incubator as a hopeless > proposition, one that would create another 1000 mail thread, bitter > debate and a long-drawn battle for nothing. I am glad that a straight > forward approach was taken, accepted and executed, with good results. > I hope that this community and others in the ASF can look back at this > time and see that collaboration as a team, without individual egos at > play, and a willingness to succeed is a great tool to move forward. > KISS principle : it always wins ! Congrat to the team ! > > Cheers > -- -- cordialement, regards, Emmanuel Le'charny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Community readiness-when does it show?
Martijn Dashorst wrote: On Wed, Jun 24, 2009 at 5:42 AM, J Aaron Farr wrote: If a community meets all the criteria, but hasn't discovered a new committer (or two) by itself, is the community ready for graduation? If not, how can we—mentors— nudge the community to focus on this thing, without it becoming an exercise in "checking the check marks"? There are at least two scenarios: Yup, but I'd like to add a third one: - the podling has voted in a new committer, but only because the committer was 'discovered' by the mentors Whoever 'discover' the new committer is irrelevent, IMO. Now, regarding the 2 scenarii Aaron listed, the first one is probably the most problematic. The second one is likely not an issue, as a project entering incubation is generally coming from the outside with a community (somehow) as it should be accepted only with an existing codebase. So if the people are relucting to vote in a contributor, it may be the mentor's role to suggest doing so. The reason people don't want to vote some new committer, beside the contribution's quality, is this 'ownership' feeling the people have to swallow. Not easy. When you have worked years on a project, finally got it accepted in incubation, and see newcomers posting new code, it's not easy to accept the idea that you don't own the code anymore. It is hard work to keep track of contributors and identify those with enough merit, when you are busy solving licensing issues, releasing and trying to keep your project going. But OTOH, it's easy to track a new contributor, see if he/she is keeps going (just looking at the mailing list, not necessarily evaluating the technical merit), and at some point, just ask the committers about the level of quality of those contributions. Then asking for a vote, or at least proposing it. Wouldn't a community only be ready when they themselves are capable of looking beyond their own coding, contemplate what's happening in their community and take necessary action? Probably. While I understand that Mentors should prod the community into action at times, but shouldn't Mentors also take a step back and let the community become enlightened by themselves? Well, we should not consider mentors as doers, not as flies around the cake. We are shepherds, here : we give directions, try to avoid mistakes, explain 'the apache way', and help as much as we can. If we don't do that, and let the community educating itself, I guess that it will go right in some walls more often than necessary... IMHO, of course. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Community readiness-when does it show?
Scott Comer wrote: i would think that if there is someone contributing to the project that the community would recognize and add them themselves. it isn't up to the mentors to do anything except perhaps suggest they consider it if they're being really thick about it. A bit too convoluted a sentence for my English decoder ;) Do you mean that if the community is suggesting voting a new committer, then the mentors should not do anything ? Well, in this case mentors can express Joy and uncock champagne, of course, but mentors can also -1 the vote if they think that the potential committer does not fit for some reason. But it's unlikely ! it would be cool if the mentors might suggest possible relationships with other projects where there might be synergy and perhaps cross pollination? I *think* that we do that. I hope ... We are not necessarily around to drive the new project from the technical aspect, but it cost nothing to inform the podling that some choices might hurt the project, or if we know about something similar done somewhere else, we can suggest using it instead of reinventing the wheel. More important, as we are using a lot of existing component, we can give feedback about them (like, "yeah, maven 2 just do the job", or "don't write your own logging system". This kind of stuff.). -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Google Wave - anyone?
Christian Grobmeier wrote: Hi, Hi, I know my request might be a bit unusual, but is somebody here preparing an idea for implementing the Google Wave Protocol? I might want to follow, if somebody does. You may ask Bernd Fondermann about that. He has started a project called Vysper (http://mina.apache.org/vysper) which is a XMPP server -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Google Wave - anyone?
Christian Grobmeier wrote: You may ask Bernd Fondermann about that. He has started a project called Vysper (http://mina.apache.org/vysper) which is a XMPP server Unfortunatly this link leads to an quite empty page. yes. Try this one (outdated): http://cwiki.apache.org/labs/vysper.html -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Guillaume Nodet wrote: We have in this proposal a lot of people who are not felix committers and who are not even apache committers at all. They want to work on some code and create a community around it. The way the ASF works means that the incubator is the right place to do so. The only other solution is to develop it in a closed source environment and submit it at Apache when it's done, and i really don't think it's a good idea, given the willingness to do it in open source. The blueprint implementation has been developped so far inside the Geronimo TLP, part of the reason is that some of the people working on it were not felix committers, so it was way easier to work there instead of contributing patches until getting committership.It is very difficult to commit to work on a new implementation of anything when you don't even have commit priviledges. It's ok for patches, but not for a new dev. That's what we have here. We have people here wanting to work on some new OSGi spec implementation, and the only way for them to do so at Apache in to go into the incubator. Having apache committers from a project be granted commit access to another project is not really a problem, as soon as the other project's PMC decide what are the "rules". The new project can also be a Felix subproject, with specific commit access granted to a specific set of committers, if needed. I'm pretty sure that infra can deal with such a granularity. Also the felix PMC can check that the new committers are not committing in the other projects, if needed. So far, this is how we did for FtpServer, SSHd and Vysper in MINA. In fact, Vysper is still in a sandbox, but I can see the moment where it will get out, either as a MINA subproject, or as a TLP. The biggest advantage is that, as all the committers were already working on other projects, and as the MINA PMC was able to check that the project was following the rules (IP, etc), it's far easier than going through incubation. I can see how better it could be for Aries to start as a felix subproject, for many reasons. Even, if Aries was to compete against Felix in any way, it's not a good enough argument. We already have multiple projects in the ASF that do have overlap as it was pointed already multiple times in this thread: mutliple REST implementations, multiple JAX-WS implementations, etc... But the Aries podling does not aim to even provide alternative implementation to what Felix already has, it's goal is to create a community with new people who want to work on that and deliver both implementations of new OSGi specs (such as blueprint and subsystems / applications, jpa ...) and also additional extensions (such as blueprint custom namespaces for transactions, etc...). It would be better to see Felix as a OSGi aggregator (a bit like WS or DB are), with potentially many implementations. It would be so great if Buildr, Ant, Maven, Archiva, Continuum, were all embedded in a Build Tools project, instead of being one of the 70 TLP. From the user PoV, it's difficult to know what they all are doing. This is a bit more general than just Felix, here. We have more than 70 TLP, and this number will continue to grow in the next few years. Why can't we aggregate projects within categories at some point ? For the independance, the only real place I know which provides OSGi components, not tainted with a given framework are SpringSource (though it's open source, the community is not really open) and OPS4J, but I do think it's a different discussion. I restate that the goal of the Aries proposal is to foster a community around some new code implementing some OSGi specs. And I don't think we can do that inside an existing TLP, as we have non apache committers that want to create this code. That's what the incubator has been created for. I'm not sure that because a project has non apache committers, it should be started in incubator, as soon as the TLP can "educate" the project. of course, if all the peope are non apache committers, that's a different story. That being said, the best would be to first check for synergies, then think about creating the poddling if there are not too much overlap. Be pragmatic ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JSecurity, Ki, Shiro project inconsistencies
Niclas Hedhman wrote: I am calling upon the Mentors (Alan, Paul, Emmanuel, I'm not anymore a mentor of this project. I step down 5 or 6 months ago. Just FYI. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first "all hands" meeting was held, where a number of "interested people" came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or >=GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at their final l
Re: Review-Then-Commit
Matthieu Riou 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? I would bet that most of the Apache project are following the C-T-R scheme instead. IMO, it's up to the project PMC to define the correct strategy, there is nothing such a global politic regarding it, AFAIK Thanks, Matthieu -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
Michael Wechner wrote: 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. As a matter of fact, at Directory, we are using CTR since the beginning, and we have had to define those rules. It's pretty easy : - if it does not compile locally, don't commit - when you commit, always try to do it in a way a simple revert restore the previous state - when doing some heavy refactoring, do it in a branch - add some integration tests early in the process - for new committers, check their commits until they are trustable - define some code rules (syntax, comments, etc) followed by everyone. That's pretty much it, and it work quite well considering the project size (325 000 slocs as of today...) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[Proposal] JPPF : a parallel processing framework for Java
Issue Tracking * JIRA (JPPF) Others * Web site: Confluence (JPPF) == Initial Committers == * Laurent Cohen (laurent.cohen at jppf.org) * John Channing (john.channing at gmail.com) == Affiliations == None of the initial committers are paid by their employer, nor do they represent their employer in any activity related to JPPF. == Sponsors == Champion * Emmanuel Lecharny (elecharny at apache dot org) Nominated Mentors We are currently looking for mentors within the community. Sponsoring Entity * Apache Incubator -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
On 8/17/10 8:23 PM, Craig L Russell wrote: +1 You have worked hard to get to this point, having survived the release process, two name changes, and community building exercises. You also have my +1. It was a long graduation, but at the end, the team get The Apache way large and long. Go ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
On 8/18/10 12:24 AM, Kalle Korhonen wrote: I'm with Stefano there: I do contest the view that svn is the release, You can contest, but the fact is that a release is just a revision in the SVN trunk, not a package you deliver, AFAIU. I suggest that you read carefully this : http://www.apache.org/dev/release.html#what and more specifically the last paragraph : " The Apache Software Foundation produces open source software. All releases are in the form of the *source materials* needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the *same version number* as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release" In other word, the release *is* the SVN revision that has been voted. but let's leave that for another thread. I'm watching the issue and perhaps I'll restore the LICENSE file on top of the tree. Please do. If you are not convinced by the complex wording used by the Apache site, just have a look at every ASF project, you will see that the LICENSE file is present in each trunk and tag. It's also explicitly written on http://www.apache.org/legal/src-headers.html#notice. At least, I would suggest that you restore the file, then discuss the rationale for this file being present or not on another thread:) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
On 8/18/10 1:03 AM, Les Hazlewood wrote: Yes, the name changes were difficult to deal with, ... It was very interesting that the team didn't exploded after such an unpleasant experience ! But consider that it could have been much worse : what if you have picked 'Dalvik' for the project name at the origin? ;) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
On 8/18/10 1:15 AM, Joe Schaefer wrote: In other word, the release *is* the SVN revision that has been voted. Bzzt. The release package may contain files not found in svn. See httpd releases for examples. That is why the document you referenced avoids discussion of svn; it's the actual tarball that counts. Thanks for correcting my wrong understanding. Yes, release = tarball produced by any tool you may want to use (maven, ant, make, human sweat and fingers...) At least, I would suggest that you restore the file, then discuss the rationale for this file being present or not on another thread:) The reason it's good to have the LICENSE and NOTICE file appear in the base of any reasonable svn checkout is because svn is a distribution point for developers, so having license info about the collected work (represented by an svn checkout) appear in expected places is important. I buy that. Thanks for the clarification ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No dev-, user- lists for small podlings (was: Re: [PROPOSAL] Kitty to Enter the Incubator)
On 9/9/10 9:33 PM, James Carman wrote: On Thu, Sep 9, 2010 at 3:24 PM, Greg Stein wrote: The formation of your community is a BIG DEAL. Not something to casually sweep under the rug. Partitioning the community between users and devs makes it very difficult to establish a large, viable, sustainable community. If projects arrive at the Incubator with an already-built user community, then sure. Create separate lists. But small communities should (IMO) stick to a single dev@ list until you can't handle the traffic any more. If you started elsewhere with two lists, but your list traffic is still "small", then I would recommend combining them when arriving at the Incubator. It is obviously a call for each podling to make, so I'm simply recommending that all podlings consider the impact of dividing your community when you ask for separate dev/user lists. I believe it is rarely appropriate. And I'm all about consistency. Most (if not all, I haven't checked) ASF projects have separate user/dev lists. We, at Directory, created the users mailing list 2 years *after* exiting from incubation. Until then, we had mainly interaction with developers, not users. Eventually, some of those early adopters became committers. In fact, it's hard to get real users before the project is well established. In restrospect, it was a damn good idea : having an empty user list gives your potential users a bad feeling. Once you have enough real 'users' (quite unlikely if your project is just in incubation without an installed base), then creating a separate list where you actually have daily posts is good. Consistency is one thing, being pragmatic is probably a better idea. So +1 to Greg opinion. my 2 cts... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ISIS] Re: Conference call
On 11/19/10 11:52 PM, Bertrand Delacretaz wrote: Hi, On Fri, Nov 19, 2010 at 11:41 PM, Siegfried Goeschl wrote: ...if the ISIS developer/users/mentors/community decide to run a regular Skype meeting to meet each other electronically assuming +) that the meeting is announced on the dev list +) that we not exclude any interested party (apart from troll feeding) +) that no official statement/vote is circumvented than I don't see any good reason why someone could complain about it and/or impose rules how to organize such a "come together" I agree that having such calls (or any other off-list discussion/event) with the conditions that you indicate is fine - I'd just add that anything important must be relayed to the dev list. I'm sure people who cannot attend the call will appreciate a short summary sent on the list. I'll just warn you that such skype meetings every month simply don't scale as soon as you have people in different TZ, and when most of the people are participating on their free time. Also it can be very frustrating for someone in Australia to have to wake up at 7am in order to follow a meeting occurring at 5 pm in the USA and at 1 am in europ... I'm just trying to tell you what I have learned from a previous experience... It might not fail for you, but at least, you know what are the dangers you'll face :) My 2cts... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/31/12 3:06 AM, Joe Schaefer wrote: - Original Message - From: William A. Rowe Jr. To: general@incubator.apache.org Cc: Sent: Monday, January 30, 2012 9:01 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/30/2012 7:51 PM, Joe Schaefer wrote: - Original Message - From: William A. Rowe Jr. To: general@incubator.apache.org Cc: Sent: Monday, January 30, 2012 8:47 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/30/2012 7:44 PM, Dave Fisher wrote: Sent from my iPhone On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr." wrote: On 1/30/2012 6:06 PM, Joe Schaefer wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. -1 The argument is very simple, you don't allow a simple majority to tyrannize the minority. So the ASF has long held a simple standard of consensus on all committee additions and subtractions. Some majority might be irked at [insert name here]'s [actions|inaction| comments|silence] but that was never grounds to remove a committee member. If you want to propose some supermajority metric other than "unanimous", that could work (e.g. 2/3 or 3/4 in agreement In your plan then a -1 is really a -2 or -3? Sounds like a filibuster... No, I'm -1 to this proposal. I'd support his proposal if it were modified to provide for a measurable super-majority consensus. Define supermajority in a way that isn't patently absurd and perhaps I'll consider amending it. 2/3. 3/4. Take your pick. I'd argue on the high end. Consider that to defeat a 3/4 supermajority consisting of 9 votes requires more than 2 people against. This committee has an order of magnitude more voters. Simple obstructionism is easy to deal with. Oh, so you want a supermajority in terms of those who have voted, not in terms of the membership of the IPMC? Not unreasonable. Let's see what others think. I would easily +1 a proposal with a 3/4 majority of the *voters*. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 1/31/12 11:08 AM, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Sounds nice, yes. But I wonder if there is some overlap with the Apache Shiro project [1]? IMO, Syncope spectra is wider than Shiro. Actually, Syncope *could* use Shiro. I have a Q : Can't it be a bit larger than just JEE based ? Many would like a solution which extends to tomcat only... +1 for the proposal otherwise, I can help mentoring the project to some extent. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 1/31/12 11:44 AM, Francesco Chicchiriccò wrote: On 31/01/2012 11:31, Emmanuel Lecharny wrote: On 1/31/12 11:08 AM, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Sounds nice, yes. But I wonder if there is some overlap with the Apache Shiro project [1]? IMO, Syncope spectra is wider than Shiro. Actually, Syncope *could* use Shiro. Correct. I have a Q : Can't it be a bit larger than just JEE based ? Many would like a solution which extends to tomcat only... Syncope officially supports Apache Tomcat 7 as first option [1], Glassfish 3.1.1 (recently, on trunk) [2] and JBoss 7 (ongoing work, on trunk) [3]. +1 for the proposal otherwise, I can help mentoring the project to some extent. Does this mean that we can put your name on the proposal? ;-) Sure. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] PhoneGap for Apache Incubator
On 10/7/11 10:11 PM, Gianugo Rabellino wrote: On Fri, Oct 7, 2011 at 2:49 AM, Christian Grobmeier wrote: Any more questions/comments about this proposal? If not, I suggest we start the vote tomorrow. I think we're good. The one thing I'd like to do is asking to add another committer to the roster. Abu Obeida Bakhach has been following the WP7 part of Phonegap and would be happy to continue helping out at least on that front. As he was a Stonehenge committer, he should already have a CLA on file and an Apache ID. Obeida works in my team and I already checked with him - he'd be eager to help. Can I just go ahead and edit the proposal? Yes, please go ahead. Thanks - on the same line Obeida pointed out how Sergey Grebnov has been doing the bulk of the actual work, and I took the libery (after checking with Sergey) to add him to the roster. Has PhoneGap proposal totally stalled ? Or did I miss the Vote thread ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] PhoneGap for Apache Incubator
On 10/7/11 10:11 PM, Gianugo Rabellino wrote: On Fri, Oct 7, 2011 at 2:49 AM, Christian Grobmeier wrote: Any more questions/comments about this proposal? If not, I suggest we start the vote tomorrow. I think we're good. The one thing I'd like to do is asking to add another committer to the roster. Abu Obeida Bakhach has been following the WP7 part of Phonegap and would be happy to continue helping out at least on that front. As he was a Stonehenge committer, he should already have a CLA on file and an Apache ID. Obeida works in my team and I already checked with him - he'd be eager to help. Can I just go ahead and edit the proposal? Yes, please go ahead. Thanks - on the same line Obeida pointed out how Sergey Grebnov has been doing the bulk of the actual work, and I took the libery (after checking with Sergey) to add him to the roster. Forget about my last mail. I missed the rename to Callback... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 2/1/12 1:04 AM, Benson Margulies wrote: Dear Proposed Syncope mentors: Please post messages on this thread indicating your prior experience as mentors, Does mentors have to have any experience ? Is this a new policy for being a mentor on an incubator project, or something you just are interested in ? if any, and your willing to remain in place as active mentors for at least a year. Mentors are supposed to remain mentors up to graduation. It's certainly not necessary to require that a proposed mentor express a will to remain mentor for more than a year... I'm missing something here ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][PROPOSAL] Syncope join the Incubator
On 2/7/12 9:41 AM, Simone Tripodi wrote: Hi all ASF mates, I'm writing to submit a new incubator proposal, Apache Syncope. Follows below the proposal; this vote will be open for 72 hours and will be closed on February 10th (Fri) at 9:00 am CET. + 1 (binding) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mad signing and checksumming (Was: [VOTE] Release DeltaSpike 0.1-incubating)
On 2/8/12 11:41 AM, Jukka Zitting wrote:
Hi,
On Wed, Feb 8, 2012 at 3:06 AM, sebb wrote:
On 8 February 2012 01:44, Niall Pemberton wrote:
A small but annoying nit: you've gone mad signing and creating
AFAIK, this is a known bug with Nexus and/or Maven.
I know the problem with .asc.md5 and .asc.sha1 [1], but not the one
with .asc.asc and .asc.asc.*. Is this a new generic issue, or just
something specific to the DeltaSpike build?
We don't use anymore the Maven plugin to sign the package because of
this problem (asc.asc etc)
Here is a shell script we use instead for Apache Directory, and you have
to run it manually :
#!/bin/sh
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership. The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied. See the License for the
# specific language governing permissions and limitations
# under the License.
echo "PGP Key ID: "
read DEFAULT_KEY
echo "PGP Key Password: "
stty -echo
read PASSWORD
stty echo
echo ""
for FILE in $(find . -maxdepth 1 -not '(' -name "sign.sh" -or -name ".*"
-or -name "*.md5" -or -name "*.sha1" -or -name "*.asc" ')' -and -type f)
; do
if [ -f "$FILE.asc" ]; then
echo "Skipping: $FILE"
continue
fi
echo "Signing: $FILE ... "
# MD5
if [ ! -f "$FILE.md5" ];
then
openssl md5 < "$FILE" | cut "-d " -f2 > "$FILE.md5"
echo " - Generated '$FILE.md5'"
else
echo " - Skipped '$FILE.md5' (file already existing)"
fi
# SHA1
if [ ! -f "$FILE.sha1" ];
then
gpg --default-key "$DEFAULT_KEY" --print-md SHA1 "$FILE" >
"$FILE".sha1
echo " - Generated '$FILE.sha1'"
else
echo " - Skipped '$FILE.sha1' (file already existing)"
fi
# ASC
if [ ! -f "$FILE.asc" ];
then
echo "$PASSWORD" | gpg --default-key "$DEFAULT_KEY"
--detach-sign --armor --no-tty --yes --passphrase-fd 0 "$FILE"
echo " - Generated '$FILE.asc'"
else
echo " - Skipped '$FILE.asc' (file already existing)"
fi
done
In Apache Directory Studio, we also use this script, but it's called
from maven :
org.apache.maven.plugins
maven-antrun-plugin
unzip-copy-files
process-resources
includes="ApacheDirectoryStudio-*.zip"/>
file="${project.build.directory}/ApacheDirectoryStudio-macosx-x86-dmg-${version}/ApacheDirectoryStudio-macosx-x86-${version}.dmg"
todir="${release-dir}" />
file="${project.build.directory}/ApacheDirectoryStudio-macosx-x86_64-dmg-${version}/ApacheDirectoryStudio-macosx-x86_64-${version}.dmg"
todir="${release-dir}" />
file="${project.build.directory}/ApacheDirectoryStudio-win32-x86-exe-${version}/ApacheDirectoryStudio-win32-x86-${version}.exe"
todir="${release-dir}" />
file="${project.build.directory}/ApacheDirectoryStudio-win32-x86_64-exe-${version}/ApacheDirectoryStudio-win32-x86_64-${version}.exe"
todir="${release-dir}" />
dir="${project.build.directory}/ApacheDirectoryStudio-updatesite-${version}"/>
run
Ok, I can understand if it makes you puke...
I *wish* the bug is fixed in maven... All in all, it's *just* 4 years
this issue is opened...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept PDFBox for incubation
[X] +1 Accept PDFBox as a new podling A must have ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
Jukka Zitting wrote: Hi, +1 Emmanuel Lecharny (non-binding) May be I missed a step... I have been Ack'd on jan, 20 as an incubator PMC member. Any heads up ? Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Endre Stølsvik wrote: Why should this discussion be moved into a Apache-private realm, and not just stay fully public, so that I can watch the proceedings? This is an interesting discussion. Can we please keep the Incubator ML focused ??? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache CXF Graduation as TLP
+1 ! Daniel Kulp wrote: After 20 months in the incubator, 6 releases complete and 2 more on the way shortly, several new committers, and too much email traffic :-), the Apache CXF community (with support from our mentors) feels that we are ready to graduate to an official top level project at Apache as indicated by the community vote recorded at: http://www.nabble.com/-VOTE--Graduate-Apache-CXF-as-a-top-level-project-to15812722.html We would like the resolution attached to this email to be presented to the board for consideration at the next possible board meeting. For additional information, the CXF status file is here: http://incubator.apache.org/projects/cxf.html Thank you in advance for your time and consideration. [ ] +1 [ ] +0 [ ] -1 -- Dan (on behalf of the entire Apache CXF team and with permission from the CXF mentors to call this vote.) == Establish the Apache CXF project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache CXF Project", related to a framework for creating, deploying, and consuming services based on SOA design principles for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache CXF PMC be and hereby is charged with the creation and maintenance of "Apache CXF"; and be it further RESOLVED, that the office of "Vice President, Apache CXF" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache CXF PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache CXF PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache CXF PMC: * Ulhas Bhole <[EMAIL PROTECTED]> * Sean O'Callaghan <[EMAIL PROTECTED]> * Dan Diephouse <[EMAIL PROTECTED]> * Freeman Yue Fang <[EMAIL PROTECTED]> * Jarek Gawor <[EMAIL PROTECTED]> * Jeff Genender <[EMAIL PROTECTED]> * Eoghan Glynn <[EMAIL PROTECTED]> * Jim Jagielski <[EMAIL PROTECTED]> * Willem Ning Jiang <[EMAIL PROTECTED]> * Eric Johnson <[EMAIL PROTECTED]> * Peter Jones <[EMAIL PROTECTED]> * Daniel Kulp <[EMAIL PROTECTED]> * Bozhong Lin <[EMAIL PROTECTED]> * Jervis Liu <[EMAIL PROTECTED]> * Jim Ma <[EMAIL PROTECTED]> * James Maode Mao <[EMAIL PROTECTED]> * Benson Margulies <[EMAIL PROTECTED]> * Glen Mazza <[EMAIL PROTECTED]> * Guillaume Nodet <[EMAIL PROTECTED]> * Ajay Paibir <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Daniel Kulp be appointed to the office of Vice President, Apache CXF, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache CXF Project be and hereby is tasked with the migration and rationalization of the Apache Incubator CXF podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator CXF podling encumbered upon the Apache Incubator PMC are hereafter discharged. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Size of websites in incubator.apache.org
Tony Stevenson wrote: Good day, Hi 102M/x1/www/incubator.apache.org/directory we have exited the incubator 3 years ago ... This directory can be archived or removed at will. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSecurity Champion Recruitment
Les Hazlewood wrote: Hi Alex, Sounds great. The JSecurity team has had an identity management server in our heads for quite a while. Indeed much of the current framework reflects flexibility that was designed into it with the intention of making an identity server an easier task. We also plan on including nice SSO support, federated application enterprise sessions (shared state across applications if desired), and more. We welcome your feedback since this is close to your heart as well :) Thanks, Les On Thu, May 8, 2008 at 5:36 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: Count me in too - but more so as a mentor. I've mentored a few times and have some vested interest in security through Apache Directory (esp. Triplesec). Regards, Alex If more than one mentor is possible, I would like to offer some of my limited spare time for this project too :) I'm working with Alex on the Directory project he founded, and I'm totally convinced sure that there are some potential synergy with JSecurity. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security restrictions
Alan D. Cabrera wrote: On May 17, 2008, at 10:33 AM, Robert Burrell Donkin wrote: On Sat, May 17, 2008 at 6:25 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I'm beginning to regret not slogging through all those threads about the IP checks in relation to security. Ok, I'm actually glad that I didn't waste my time. WRT security...? (maybe it's just slipped my mind but i don't recall much about IP and security) Is there a check list available for me to use for a podling? a guide is being drafted in http://incubator.apache.org/guides/mentor.html Apparently OpenSAML had all sorts of these IP issues. For example, we have to worry about IDEA. The main isssue OpenSAML (if I remember what I read) was mainly about RSA (http://marc.info/?l=incubator-general&w=2&r=1&s=opensaml) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
Alan D. Cabrera wrote: On May 30, 2008, at 5:27 AM, Alex Karasulu wrote: On Fri, May 30, 2008 at 8:04 AM, James Carman <[EMAIL PROTECTED]> wrote: Isn't there something that states that an incubating project needs to be novel or provide something that's not already provided by another library (with an open-source license)? I have looked at the JSecurity proposal only briefly, but it seems to me that most of what it aims to provide is already provided by Spring Security (a.k.a. Acegi). Although, Spring Security is somewhat bound to the Spring framework (they implement InitializingBean and stuff), so that might be what JSecurity is trying to provide, a container-agnostic security framework. There's no uniqueness requirement AFAIK. Any kind of project can be proposed even if there already exist multiple implementations of a similar technology here at the ASF and abroad. Well put. Let a thousand flowers bloom. This is also what the incubator is good for ;) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
James Carman wrote: On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote: There's no uniqueness requirement AFAIK. Any kind of project can be proposed even if there already exist multiple implementations of a similar technology here at the ASF and abroad. Perhaps the uniqueness/novel restriction is for Apache Commons projects. Or, perhaps I just made it up out of thin air! :) Maven vs Ant vs Buildr ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
Les Hazlewood wrote: Sure, that sounds good to me. I'll update the proposal... Then maybe JSECURITY for Jira too might be good. Not sure... Depends if we will have many sub-projects, which might be a good idea, regarding the various funtionalities. wdyt ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
Les Hazlewood wrote: I prefer JSEC for Jira just because that is what we use now. It has grown on me ;) If any sub projects come , then JSECSUBA, JSECSUBB, JSECSUBC, etc feel a little more digestible (at least in length) than JSECURITY-SUBA, etc. Yep. We have the same on Directory : DIRSERVER, DIRTSEC, etc... Mails are somehow a different beast as you won't have more than a few ML, namely users, commits, dev, private, while you may have a dozen of JIRA names. Forget about my proposal. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate JSecurity Project
+1 Alan D. Cabrera wrote: Relevant information can be found in: http://wiki.apache.org/incubator/JSecurityProposal Regards, Alan -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jsecurity] ML moderators
Hi, we may need some moderators for the three mailing lists. I'm ok to be one of them. Anyone else (if the list is not already set ?) Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: The Maven Repository
Hi Martijn, Martijn Dashorst wrote: I would therefore continue maintaining the old jsecurity code, and release those outside the incubator, just as normal business for your project. There are options. Maintaining the old repo can be tough, as the repository will be different, and make merges difficult. Another possibility is to deploy the new jars into more than one maven repo : incubator's and current jsecurity's repo. I'd suggest also to rename the packages only when you are almost ready to graduate. This allows you to merge current development and maintenance quite easily. This is only if you intent to keep both subversion repo alive in //. But if users base their development on apache Jsecurity version, they will find it painfull to change the package at the very last moment. Don't know ... What if they release a preliminary version on Apache with the new packages, and make it the base for the incubator developments, so that users can use it straight away and benefit from the new features JSecurity will implement in the near future ? It can alleviate the burden of maintaining two different code bases, out of which one is known to be dead... THe WIcket project did have all code imported into the incubator repo, so we could easily backport features/bug fixes. We just released the artifacts on sourceforge and uploaded them ourselves to the central repo using the outside channels. We *did* make perfectly clear that even though Wicket is in the incubator, that the release wasn't endorsed by nor associated with Apache. You can look at the releases for Wicket 1.2 (http://wicketframework.org/wicket-1.2) to see how we did this. This work too. Depends on the existing user's base, I guess ? The Apache based development (org.apache.wicket) happened in parallel, but for the most part in the same namespace as the old wicket code. We did create a couple of releases inside the incubator to learn how to perform an Apache release. But iirc we never actually published those releases to the greater public. This process worked great for Wicket, but your mileage may vary. In any case, Wicket team made it solid. A valuable experience for sure ! Thanks Martijn ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: The Maven Repository
Martijn Dashorst wrote: This work too. Depends on the existing user's base, I guess ? Which was in the thousands for Wicket at the time, with numerous systems in production. and it makes perfect sense to follow your way in this case. How many users does JSecurity has ? Regarding the potential incubation failure, I would say that the cost of a double migration will be overwhelmed by the killing effect of this failure. It's a little bit like picking the lawyer to manage your divorce before the wedding :). However, with thousands existing users, like for wicket, it makes sense too (I don't know how many lawyers Bill Gates consulted before being married ;) At this point, the JSecurity team will have to make the best choice. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: The Maven Repository
Les Hazlewood wrote: I don't know the exact usage, but I'm sure it is in lower thousands - many people use our .jars directly, but probably many more use it via 3rd party plugins (Grails plugin, etc) that is built on top of JSecurity. It sounds as if waiting at the last possible second to move from org.jsecurity.* to org.apache.jsecurity.* is the best option for us. That way we can move over to the Apache SVN as soon as possible, but impact the existing community only when absolutely necessary. Sounds reasonnable too. Thanks to modern IDE, package renaming is just a matter of minutes (as soon as you don't forget to modify the Spring files - or any other container using class names - :) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to count the number of the mailing list subscriber?
Hi, I think that you can get it, as soon as a moderator of a ML or a PMC member, by requesting ezlm for a list of the subscibers and counting them. Bertrand Delacretaz wrote: Hi, On Wed, Aug 27, 2008 at 3:50 PM, Edward J. Yoon <[EMAIL PROTECTED]> wrote: ...How to count the number of the mailing list subscriber? Is there some UI based application that shows count?... I have some links to ASF stats at http://delicious.com/bdelacretaz/asf+stats I was going to point you to http://people.apache.org/~coar/mlists.html but that doesn't seem to work right now, usually that would show the number of subscribers and messages for all of our mailing lists. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Labs project promotion
Thorsten Scherler wrote: Hi all, Hi ! This move to the incubation has raised some argumentation. One reason for this expressed in [3], stating that the code is developed on ASF homeland: "...BTW, why do you need to go through incubation? All the code was developed in the ASF. It's ASL. You already have a home designated for it. Seems like incubation can be skipped." Another reason to skip incubation is the possible lost of visibility of the project expressed in [5]: "...The thing is, people looking at HC may just say "Oh, Droids. Interesting" and take a look and join the community, whereas in incubator, who knows, it's might be lost in the noise" One suggestion for this points is suggested in [6]: "I does seem to me like there should be some sort of incubation fast track for a lab project that wants to become a subproject of an existing TLP." The thing that Droids [7] needs now is more exposure, committer with different use cases and different needs for robots and plugins. This is the only way to create a truly "intelligent standalone robot framework". BTW I started an incubator proposal [8]. WDYT about either skipping or fast track incubation or doing the standard incubation? IMHO, a fast track incubation is ok. The project still need incubation, in order to meet the ASF requirements (community diversity, for one of them), but it should not take months to be promoted to a TLP/sub-project. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: September board reports!!!
Martijn Dashorst wrote: The following reports are still missing from [1]: Composer log4php Pig RAT River Shindig TripleSoup Hama Martijn [1] http://wiki.apache.org/incubator/September2008 I have added JSecurity to the list, and I also injected the monthly report for it. Thanks. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Just so everyone understands this in context, the objection above is moot because... No, it's not. Anything that creates an impetus for a podling to get out of the Incubator is goodness. Too many podlings view the Incubator as a comfy place - I believe that the Incubator PMC needs to create more of a reason for projects to get in gear and graduate. This isn't college - you don't get to stay here for the best seven years of your life. =) I would almost say we should revisit the entire policy of letting a podling release at all, but yah, I'm not really caring to reopen *that* can of worms. -- justin EXACTLY. I'm reading about 1/2 the -1 votes against Maven-releases as against *releases*. Which is absurd. The current situation of .jar distribution from people.apache.org is crap, you know it, and maven is the appropriate solution. The problem with a release injected in maven is that it will be there forever. If a release has some problems (IP issues, etc), you can't remove it from maven, as some projects might depend on it, and the users will immediately carpet bomb the maven ML to get the release back into the repo. Sounds like a possible scenario, no ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept VCL into Apache Incbator
[X] +1 Accept VCL into Incubator -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Niall Pemberton wrote: This is a slight majority (of binding votes) for accepting the proposed change, but given the clear lack of consensus and the concerns voiced about that, I unfortunately need to conclude that this issue should be tabled until better consensus is reached. If this was a release vote then I could understand it - since people judge the importance of issues differently - and fixing the issues and moving on to a new release is often easier since it maintains consensus. On this issue though, its been well debated several times - it s clear that there won't be consensus in the near future - so why should the minority get their way when they lost the vote? If this vote doesn't pass then we need to re-write the rules to define how much of a majority overturns the status quo. Perhaps two thrids, perhaps no negative votes. If this policy isn't implemented, then I think all the people who voted +1 at least deserve a definition of how short we fell of passing this vote and what the bar is. having voted -1 myself, and even if I still think that it's not a result I like, I also think that we need to move on and consider the vote as positive. If we discover after a few months that it was a bad idea, then we can vote again, and fix the problem. Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... And about the other concerns, we can also start some discussions and vote, too. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] apache-empire-db-2.0.4-incubating and apache-empire-struts2-ext-1.0.4-incubating release, 2nd round
Martijn Dashorst wrote: On Fri, Oct 3, 2008 at 1:27 PM, sebb <[EMAIL PROTECTED]> wrote: Wherever the additional license files are placed, they need to be referenced from the main LICENSE file. I'm not sure where you get this from. This is the first time I hear this requirement. there : http://www.apache.org/dev/release.html#distributing-code-under-several-licenses -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPORTS] missing: Abdera BlueSky Buildr Droids Hama JSecurity Lokahi Olio PDFBox PhotArk Tashi VCL WSRP4J XAP
Bertrand Delacretaz wrote: Please add your reports at http://wiki.apache.org/incubator/November2008 Real Soon. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hmmm... JSecurity is still due ? I thought it was ok as soon as it provided the 4 first monthly reports. If so, I will try to whip a quick report by tonite. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPORTS] missing: Abdera BlueSky Buildr Droids Hama JSecurity Lokahi Olio PDFBox PhotArk Tashi VCL WSRP4J XAP
Bertrand Delacretaz wrote: On Wed, Nov 12, 2008 at 10:02 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: ...Hmmm... JSecurity is still due ? I thought it was ok as soon as it provided the 4 first monthly reports It's still listed under "monthly" at http://wiki.apache.org/incubator/ReportingSchedule, but you're right, after 3 months a podling goes to the normal schedule. So I think you can remove it from "monthly" at http://wiki.apache.org/incubator/ReportingSchedule, and remove it from http://wiki.apache.org/incubator/November2008 Ok, done. I still have added a very short report on JSecurity this month, just to inform that we have moved the codee base to the ASF repo. Thanks Bertrand ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPORTS] missing: Abdera BlueSky Buildr Droids Hama JSecurity Lokahi Olio PDFBox PhotArk Tashi VCL WSRP4J XAP
Craig L Russell wrote: Nope, JSecurity reported from July to October 2008 and is now on three month schedule. This reminder was generated from out-of-date info. The info has been updated since then. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Cassandra into the Incubator
Ian Holsman wrote: Ian, since you are the one driving this... would you mind working with the project team on improving the proposal? ...and then consider a re-submit? at the moment we have 4 '+1's (including mine) and one -1, and another ~45 hours to go. You have my +1. Even if I understand the concerns about the fork, we will have months to see if it's a viable project. This is what the incubator is for, isn't it ? (among other things, of course ...) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ** MISSING ** January Incubator Reports
Les Hazlewood wrote: On Mon, Jan 12, 2009 at 11:40 AM, Noel J. Bergman wrote: JSecurity: I really don't need to go follow URLs into SVN (or tracking down e-mails as with some others) when assembling the report. Please follow the practice of putting your report in the Wiki. I'm happy to put it in the wiki and I will do so as soon as I can. Already done :) I did the link because we were modifying the file over the last two days. It didn't make sense to me to change the wiki every time we changed the file (all of our reports are in SVN, easily traceable and recorded). Instead, linking to HEAD ensured that the wiki always reflected the most up to date and current revision. I thought I was actually acting in the 'wiki spirit' by ensuring that the data never had the possibility of getting out of sync, i.e. link instead of replicate. Np. You did what you thought was the best. Now if it is Incubator policy that we must use the Wiki for board reports, then we'll stop using SVN. My concern is that I want to avoid the possibility of multiple editing places and the potential confusion that might arise as a result. We can still use SVN, but when the report is validated, we simply push the content into the wiki, as I said in my first mail. What is policy? I'm just trying to learn - thanks for any guidance! Just as I said : write down the report (either as a simple mail, or in SVN), and when validated by the team, then push the content to the wiki (not the link). At least, we delivered a report in time ;) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ** MISSING ** January Incubator Reports
Les Hazlewood wrote: On Mon, Jan 12, 2009 at 12:25 PM, Emmanuel Lecharny wrote: What is policy? I'm just trying to learn - thanks for any guidance! Just as I said : write down the report (either as a simple mail, or in SVN), and when validated by the team, then push the content to the wiki (not the link). Ok, cool - thanks for the clarification. I'd prefer only one 'editing mechanism' in place, so I'll stick with email for formulating the report and then pasting it into the wiki when it is agreed upon. My personal opinion is that I don't like the possibility of out-of-date changes that can occur when using both SVN and the wiki. btw, you can also use the wiki alone, as it can be modified until done. One single 'editing mechanism' :) And you have an history ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache NetBeans Incubator Proposal
Jim, I would be pleased to pass you the batton. You most certainly will be a better mentor than I could be. Le mardi 13 septembre 2016, Jim Jagielski a écrit : > If you think I would be of help as a mentor, add me too... > > Understand if we are getting to too large a number though. > > > On Sep 13, 2016, at 5:15 AM, Bertrand Delacretaz > wrote: > > > > Hi Mark, > > > > On Tue, Sep 13, 2016 at 11:11 AM, Mark Struberg > > wrote: > >> ...If you need an additional Mentor with a slight Infra background then > feel free to sign me up... > > > > Ok, I've done that, thanks! > > > > I'm not in favor of "too many" mentors but the exact number is hard to > > define and your specific infra angle is very good to have. > > > > -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 > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [DISCUSS] Apache NetBeans Incubator Proposal
On Wed, Sep 14, 2016 at 9:49 AM, Bertrand Delacretaz wrote: > Hi, > > On Tue, Sep 13, 2016 at 5:17 PM, Emmanuel Lecharny > wrote: > > Jim, I would be pleased to pass you the batton. You most certainly will > be > > a better mentor than I could be > > With all due respect to both of you guys that's hard to estimate upfront > ;-) > > Unless one of you envisions constraints like lack of time that would > prevent you from participating adequately, I suggest that you both > stay on board as mentors, you can always resign from mentorship at any > time if we find that we have too many mentors during incubation. > When I was asked to became a mentor, I accepted. That was an obvious decision. Now, I really do think that having too many mentors is not necessarily a good idea. I rather prefer having someone like Jim with a very deep knowledge on how The ASF work, especially for such a project, with potentially "political" interactions, and more important, a lot of PR to deal with. NetBeans is not one of the project we see often at Incubator, I do think it deserves hot guns. Better have a hard core set of mentors from the beginning than having a bunch of people that will quit during incubation, IMHO. Btw, I really do think that adding someone from Infra is mandatory, due to the high requirement on Infra this project will have. My 2 cts ;-) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
