Re: PMC is a committee
Well, every time I see “PMC” and it appears from the context that one person is meant, I’m confused, and I have doubts about whether the author knows what they mean. I applaud Greg for complaining. What’s wrong with “PMCM” for an individual? David Jencks Sent from my iPhone > On Jul 7, 2024, at 8:47 PM, Joe Witt wrote: > > Greg > > It isnt wrong to correct improper usage particularly when there is a > specific case that caused actual confusion. > > That should be done by the person that was confused and with the person > that caused confusion. > > Joe > > >> On Sun, Jul 7, 2024 at 10:31 PM Greg Stein wrote: >> >> I have witnessed actual confusion, approximately of the form "a PMC >> approved this request". Digging in, it turned out that it was a single >> person on a PMC, not the committee approving the request. >> >> So, no ... it isn't just being a pedant. And even if it was: why is it >> wrong to correct the use of terminology? Why is it okay to misuse the >> acronym "PMC"? >> >> I do not believe that this is cultural. The acronym "PMC" is not a word in >> *any* language. So we're talking about how people are *taught* what the >> acronym means. My point is to teach people it means "committee" and it >> never means "member". That is a simple fact that has zero cultural >> implications. >> >> Cheers, >> -g >> >> >>> On Wed, Jul 3, 2024 at 10:02 AM larry mccay wrote: >>> >>> I'd be interested to know whether there is any real semantic danger here >> or >>> whether it is a flavor of Misophonia. >>> I've personally never misunderstood someone in the context of their >>> conversation. >>> >>> If there is a real danger like a decision being made for a whole >> community >>> based on someone calling themselves a PMC and it is misunderstood to mean >>> they are speaking as the entire PMC then perhaps we should rename it and >>> make it more explicit. Of course, no one will stop using PMC either >>> correctly or incorrectly - at least for a very long time. >>> >>> I'd also note that if a lot of folks are referring to themselves as an >>> inappropriate acronym that perhaps there is a missing acronym for what >> they >>> mean. >>> It seems folks are looking for something more precise and important >>> sounding. >>> >>> "Member" may be too generic and overloaded (even within Apache itself) to >>> express what they are trying to say. >>> ICM - Individual Committee Member? >>> PCM - Project Committee Member? Too close... >>> >>> Anyway, my opinion is that we either accept it and move on or add >> something >>> else. Trying to shove some semantic minutiae down everyone's throats >> isn't >>> likely worth the effort. >>> >>> >>>> On Wed, Jul 3, 2024 at 10:19 AM Dave Fisher wrote: >>> >>>> >>>> >>>>> On Jul 2, 2024, at 11:52 PM, Christofer Dutz < >>> christofer.d...@c-ware.de> >>>> wrote: >>>>> >>>>> I mean … I think I have never really been confused if someone used >>> “PMC” >>>> or “PMC member” as from the context it was clear. >>>>> What however I really hate to see in emails is people using short >> forms >>>> LMAA, WTF, IANAL, STFU, … this list is long and obviously I listed the >>> ones >>>> I knew. >>>>> Quite often when people use these short forms, I feel a bit excluded >>> and >>>> have to search or ask what they mean, so if we freak out about people >>> using >>>> the short form PMC, then I would also argue to freak out on using other >>>> short forms ;-) >>>> >>>> No disrespect but doesn’t Deutsch combine words to make longer words so >>>> that PMC Member should according to Google Translate be "Mitglied des >>>> Projektmanagementausschusses”?! Acronyms nein! Composition ja! >> Verzeihen >>>> Sie mir meine kleine aber! >>>> >>>> Best, >>>> Dave >>>>> >>>>> Chris >>>>> >>>>> Von: Yuanbo Liu >>>>> Datum: Mittwoch, 3. Juli 2024 um 05:24 >>>>> An: general@incubator.apache.org >>>>> Betreff: Re: PMC is a committee >>>>> Also it's driving me crazy to see native speakers saying "...not...n
Re: [IP CLEARANCE] Apache AsterixDB - JDBC Driver
I’m watching from the sidelines…. IIUC you are saying that if AsterixDB started over with a history-free tarball for this donation this whole question of validating the source origin would not arise and we’d just trust the SGA? While some history is nice to have, I’m not sure it’s worth this conversation. David Jencks > On Sep 7, 2021, at 5:42 PM, John D. Ament wrote: > > Hi Till > > fwiw I think the donation is fine though the AsterixDB PMC will need to do > some due diligence in verifying ownership of code before forming a release. > This is likely what Justin is trying to refer to as well. > > Some background on possible issues…. > > Before GitHub became the popular place to do this when a donation was > received a tar ball without any history was the preferred method to receive > it. Since the donation was put on GitHub it leaves some ambiguity with the > actual history of the code. The ASF headers already applied create some > additional cautiousness here - no one can validate 100% that the code being > donated can actually be claimed by couchbase. No way to see if some code > was lifted via stack overflow or taken from a GPL library. > > So here’s my +1 with the cautionary note about validating the original > source of each line of code. > > John > > > On Tue, Sep 7, 2021 at 19:01 Till Westmann wrote: > >> Hi Justin, >> >> On 3 Sep 2021, at 0:46, Justin Mclean wrote: >> >>>> Please help me understand why >>>> - the software grant from Couchbase and >>>> - the acceptance from the AsterixDB project >>>> are not sufficient to approve this donation. >>> >>> Because IMO the information provided doesn’t give sufficient detail >>> to determine who has contributed to the codebase, the history of >>> contributions has been hidden, the IP ownership of files can't really >>> be determined from what has been provided and previous questions by >>> the IPMC on this donation went unanswered. >> >> On our "Contributor Agreements" page [1] we say: >> >> "When an individual or corporation [in this case a corporation] decides >> to donate a body of existing software or documentation to one of the >> Apache projects, they need to execute a formal Software Grant Agreement >> (SGA) with the ASF [which has been executed and recorded]. Typically, >> they do this after negotiating approval with the ASF Incubator or one of >> the PMCs [in this case the AsterixDB PMC], since the ASF does not accept >> software unless there is a viable community available to support it as >> part of a collaborative project." >> >> The code has been developed by developers working for Couchbase and the >> IP is owned by the corporation. Couchbase has executed the SGA and has >> specified which code is contributed to the ASF under the terms of the >> SGA. As the AsterixDB PMC has voted to accept the donation it seems that >> all requirements to accept the donation are met. >> >> Wasn't the SGA design for cases like this where a corporation (and not >> an individual) contributes code to an Apache project? >> >> On your questions: >> Q: Where was this code original developed and who worked on it? There is >> only a couple of commits in that repro, so it doesn’t seem to have >> been developed there. >> A: This code was originally developed by multiple developers working for >> Couchbase. The names of current and former developers at Couchbase who >> have worked on it (and who largely do not have an ICLA on file) seem to >> be immaterial for the IP question as an SGA is recorded. >> >> Q: Why does the code have ASF headers on it before being donated? Were >> any 3rd party headers removed? >> A: The repository with the Apache license headers was created with the >> purpose of being donated to the ASF. Couchbase's copyright notices were >> removed from the source files and corresponding NOTICE files were added. >> ASF headers were added to files that did not have license headers and >> regular Apache License headers were replaced with the ASF headers. >> >> Q: Have all contributors signed ICLAs and/or do we have a SGA from >> CouchBase? >> A: A SGA has been executed and recorded. Not all contributors have >> signed an ICLA, but that also seems immaterial as the SGA is available. >> >> Regards, >> Till >> >> [1] https://www.apache.org/licenses/contributor-agreements.html#grants >> >> - >> 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: [VOTE] Release Apache DataSketches-java 1.3.0-incubating-RC1
FWIW (not much) Michael Martin’s statements match my understanding. What he says is stated from a different point of view or with different emphasis than most posts here, but doesn’t differ AFAICT. The only point that remains unclear to me is the end date of Verizon’s explicitly asserted copyright. I’d expect it to have an end date as of the code donation, since after that not all the code will be copyright Verizon because presumably there are non-Verizon-employee contributors. IIUC Michael is saying all ongoing contributions from Verizon employees are still copyright Verizon, which is the normal state of affairs for employees in the US. I don’t think he is claiming Verizon copyright on code contributed by others. David Jencks > On May 4, 2020, at 4:00 PM, Justin Mclean wrote: > > Hi, > >> I find no record of Verizon Media or its predecessors (including Yahoo and >> Oath) having assigned copyright to Apache, either with respect to the code >> that existed at the time the project joined the incubator or with respect >> to the authorized contributions made by Lee and others since then. And to >> be clear, pursuant to the terms of their employment agreements, neither Lee >> nor any of the other Verizon Media employees contributing to the project >> actually own copyright to their contributions. Verizon Media owns that >> copyright. > > If this is the case that as per section 4 in the ICLA my understanding (and I > may be mistaken) is we something more from Verizon Media ie, ether they waive > rights or sign a CCLA. I do see we have a CCLA on file from Verizon Media but > I’m not 100% if it was for this project and employees as I can't find any > discussion of it on your mailing list. > > From a project point of view this is slightly concerning in other ways, I > suggest you read [1][2][3][4] > > Thanks, > Justin > > 1. https://www.apache.org/foundation/faq.html#corporate-membership > 2. https://www.apache.org/foundation/how-it-works.html#hats > 3. http://community.apache.org/projectIndependence.html > 4. https://www.apache.org/theapacheway/ (independence) > > > > - > 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: [DISCUSS] NLPCraft Proposal
Is there perhaps a language problem? I often have trouble saying what I mean in a way that can be understood… even by me, a few minutes later. https://www.datalingvo.com now seems to redirect to https://nlpcraft.org, perhaps the company changed it’s name but it’s the same organization? I could have written the below and meant “The original code for the proposed NLPCraft project was written when the NLPCraft company was called DataLingvo”. Hope this is not just noise… david jencks > On Feb 5, 2020, at 1:20 PM, Justin Mclean wrote: > > HI, > >> The original code for NLPCraft was developed under DataLingvo. > > So wouldn’t they be the copyright owner? If soyou can’t change headers or > remove copyright statements without permission from them, do you have that? > > Can you point me to the original repos? It may be that that are other people > that we need ICLAs from or a software grant from DataLingvo is also required. > > Thanks, > Justin > - > 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: Some interesting incubator stats
Nice to see, thanks! If you automate this or do it again I’d like to see e.g. … - Of the podlings that joined in 2017 4 have graduated and 1 has retired Thanks again David Jencks > On Nov 14, 2019, at 6:02 PM, Justin Mclean wrote: > > Hi, > > Here’s some interesting incubator stats: > - Of the 315 projects that have gone through the incubator 205 have > graduated, 61 have retired and 49 are currently undergoing graduation. > - That means that overall 77% of projects graduate. The ones that do not do > so for a wide variety of reasons and may still exist elsewhere. > - The average time in incubation is 1.9 years > - The average time to graduate is 1.6 years > - The average time seems to be getting a little shorter. It's 1.6 years for > 2015 and 1.2 years for 2016 (although this will increase as more projects > from those years graduate) > - The shortest time to graduate was 58 days (way back in 2003) > - 66 projects have graduated (and another 12 retiring) in under a year > - Of the podlings that joined in 2019 so far none have graduated or retired > yet > - Of the podlings that joined in 2018 1 has graduated and 1 has retired > - Of the podlings that have joined in 2017 4 have graduated and 1 has retired > - Of the podlings that joined in 2016 15 have graduated and 6 have retired > - Of the podlings that joined in 2015 20 have graduated and 5 have retired. > - The oldest project yet to graduate is from 2013 (but that will soon be 2014) > - Over the life time of the incubator there has been 1044 podling mentors[1] > - Some people mentor many projects so that’s 339 different people[1] > - One person has mentored 29 projects > - 20 people have mentored 10 or more projects [1] > - One person has been the champion for more than 10 projects > > I find it amazing that the incubator have been involved with more than 300 > communities and involved so many mentors. > > Thanks, > Justin > > 1. Probably more as mentors have changed over time. > > > - > 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
What’s a “vanity mentor“? How do I recognize one before a podling has a significant history? Who is currently accepting these vanity mentors and how would they stop doing so? Hindsight is 20-20... I have no crystal ball. David Jencks Sent from my iPhone > On Aug 13, 2019, at 5:10 PM, Justin Mclean wrote: > > Hi, > >> Here's an idea... The IPMC focuses on supporting mentors to do their job >> rather than forcing project developers and their mentors to jump through >> arbitrarily defined hoops. > > What "arbitrarily defined hoops” are you referring to? ASF policy or > something else? > >> The IPMC doesn't need to enforce policy of any kind, except at the point of >> graduation. > > That seems less than ideal to me, why would a IPMC volunteer want to do that > job? And again IMO it introduces a hard gate that podlings are going to > dislike, probably more so than they do now. > >> When things change for individuals and they can no longer be good mentors >> then the IPMC needs to make it a priority to help find a new, truly >> dedicated mentor. It's a problem that needs to be solved, but let's worry >> about that when it's actually a problem rather than a hypothetical one. > > It’s currently a problem, not a hypothetical, see for instance votes coming > to this list without 3 mentors +1 votes, or the missing reports or missing > sign-offs on the current incubator report to the board. This problem isn’t > going unrecognised either, you’ll also note that recently nearly every month > new mentors have been found and added to podlings that need them. > > Thanks, > Justin > > > > - > 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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking
I don’t understand how obstructing people from becoming mentors is going to increase their involvement. In the unlikely event that I got interested enough in an incoming project to want to mentor it, no matter what rules are in place, my doing so depends on my commitment to actually mentoring. Putting additional hoops in place to jump through would just make me think that there’s too much bureaucracy not related to actually mentoring. I think you want a way of asking potential mentors, “Are you sure you want to do this? Really? Truly? If you sign up to mentor and disappear you will be dragging the project down and pushing it away from Apache. Are you still sure?” Why not just ask them directly? David Jencks > On Aug 12, 2019, at 3:34 PM, Justin Mclean wrote: > > Hi, > >> Is there a problem we are trying to solve or is this just a concern that >> it might become a problem as we scale? > > It’s already a problem. I suggest you look at the missing mentors / mentors > who don’t sign off report and look at how they were appointed. I can post the > stats if you want, but perhaps not to this list. > > Changing this would also mean people who want to be IPMC members need to do a > little work at the IPMC (and it should be a low bar), that hopefully means > more a bit more knowledge transfer / active mentors self select and a few > more people helping the IPMC out. > > Plus it’s different to how every other PMC appoints people, I don't see why > the incubator needs to be special in this regard. > > Thanks, > Justin > - > 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: New disclaimer text
To me, v2 implies an improvement over its predecessor and an expectation that eventually it will universally replace said predecessor. Perhaps DISCLAIMER-b.txt DISCLAIMER-x.txt might avoid this implication? David Jencks Sent from my iPhone > On Jul 15, 2019, at 7:40 AM, Jim Jagielski wrote: > > > >> On Jul 13, 2019, at 9:49 PM, Craig Russell wrote: >> >> DISCLAIMER.txt for the current standard disclaimer and some other name for >> the new disclaimer. >> > > This seems less confusing, I think. DISCLAIMERv2.txt for the other? > > > - > 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: Voting on releases with serious unaddressed issues
Personally, I’d appreciate it if everyone involved in this discussion decided that all parties are equally correct and expanded the scope of what they were paying attention to so as to dissolve any apparent contradictions. All i know about this situation I’ve learned from this thread, but, for example… Justin reviewed this release candidate and found a lot of files that appear to not adhere to normal apache standards for license headers. Apparently this has been discussed extensively in the past, including with Justin, but for this review apparently he wasn’t appreciating that context. Project members think these files are just fine for various reasons, apparently documented in Jira and the mailing lists. If I put myself in Justin’s place, I think, perhaps,…. I’d like to review this release candidate, perhaps as an introduction to getting more involved in the project…. hmmm this is odd, this appears to violate what I expect for what appears to be source code even it’s for tests…. what’s going on? If I put myself in a long-time project member’s place, I think,…. we’ve dealt with all these licensing issues, it’s right there in lira, let’s try a relasse…. From my own point of view, I think it would be nice to be able to review a release candidate without being a long-term project member with extensive historical knowledge. Perhaps a review guide pointing out deviations from what most people expect from apache projects and why they are fine would help. Thanks David Jencks > On Mar 30, 2019, at 10:42 AM, Geertjan Wielenga > wrote: > > On Sat, Mar 30, 2019 at 6:26 PM Wade Chandler <mailto:wadechand...@apache.org>> > wrote: > >> On Fri, Mar 29, 2019, 22:34 Justin Mclean >> wrote: >> >>> Hi, >>> >>> The Netbeans RC is an interesting one as they: >>> - Have made several releases before. >>> - Have been given advice from the IPMC on serious issues and what to fix. >>> - Looks like nothing has been done to correct those issues. >>> >>> Now I know we’re trying to be more lenient on releases but we still have >>> to draw the line somewhere and this is not their first release. The the >>> binary in source code, license issues copyright issues on the cute cat >> and >>> rabbit photos [1] probably mean that they cannot put that release in the >>> ASF distribution area even if they do get 3 +1s without legal and infra >>> approval. >>> >>> What do other IPMC members think? >>> >> >> Interestingly though there is a Jira issue related to these items of which >> you speak, and there has been mentor input on them; have you covered these >> with our mentors as an example? > > > > +1. Indeed, this "looks like nothing has been done to correct these issues" > is false, insulting, and misleading. > > I believe I need to explicitly need to say these things since Justin so > explicitly calls out the NetBeans RC here. > > I could equally well say a couple of other things, but won't, since I > respect Justin and we're all striving for the same goals and this kind of > tone isn't what I want to be involved with. > > Gj > > > > >> This thread seems a little (maybe quite) >> premature; maybe some disconnect. This discussion actually seems more >> appropriate in the NetBeans channels, and in fact please see the referenced >> issues and comments in those channels including release 10 and the one this >> is related to, 11, where addressing these issues has been specifically >> discussed with you Justin. >> >> Thanks >> >> Wade
Re: Feedback requested: New committer invitation template
I like this couchdb text a lot except please actually invite the recipient instead of indicating a desire to perhaps do so at some indefinite time. E.g. > The Apache CouchDB Project Management Committee (PMC) hereby invites you to > become a committer. David Jencks Sent from my iPhone > On Dec 30, 2018, at 11:22 AM, Joan Touzet wrote: > > Nice work, Daniel - that should definitely be incorporated. It's a big > improvement over a template that a human has to review before > > In addition to this, we over at CouchDB found the intro text a bit too > forceful for our tastes - too much guilt tripping and expectation > setting. It's also in our opinion premature to start talking about ICLAs > until the candidate actually accepts. > > Here's how we adapted this email to be friendlier (including links to our > project bylaws and CoC): > > 8<8<8<8<8<8<8<8<8<8< > > Dear %NAME%, > > The Apache CouchDB Project Management Committee (PMC) would like to invite > you to become a committer. Committers are given a binding vote in certain > project decisions, as well as write access to public project infrastructure. > > We value your contributions to date, and believe that you are committed to > the project. We mean this in the sense of being loyal to the project and its > interests. It is a position of trust, not an expectation of activity level. > > You can read more about the role in our bylaws: > >http://couchdb.apache.org/bylaws.html#committers > > Please also familiarise yourself with our code of conduct: > >http://couchdb.apache.org/conduct.html > > While these documents apply to all community members, by accepting this > invitation you are indicating that you have read and agree to them. > > Accepting this invitation does not obligate you to contribute. The ASF is a > volunteer organisation and it is normal for people's contribution levels to > vary. We welcome more contributions from you, but there is no expectation, > and this position of trust will not expire through inactivity. > > Of course, you can decline and continue to contribute as you do now. If you > do decline, it will be kept private, unless you say otherwise. > > Either way, please let us know in reply to the priv...@couchdb.apache.org > list only. If you accept, we will announce your new position on the > d...@couchdb.apache.org list after your account is created. > > On behalf of the CouchDB PMC, > %YOURNAME% > 8<8<8<8<8<8<8<8<8<8< > > Once this is accepted by the candidate, we then send through instructions to > sign an ICLA, which I'm now updating to use Humbedooh's lovely online > generator. > > You can see all of our PMC form letters here: > > https://github.com/apache/couchdb-admin/tree/master/email > > -Joan > > - Original Message - >> From: "Daniel Gruno" >> To: d...@community.apache.org, general@incubator.apache.org >> Sent: Sunday, December 30, 2018 1:24:20 PM >> Subject: Re: Feedback requested: New committer invitation template >> >>> On 12/30/18 6:41 PM, Matt Sicker wrote: >>> I like this template suggestion. It may also be helpful to note >>> that the >>> Apache ids must be letters and numbers only as some people request >>> special >>> characters in their ids. >> >> Not to toot my own horn too much, but we also have >> https://asf.icla.online/ which simplifies the >> print-type-sign-scan-email >> routine for Apache ICLAs (and does verify that user ID is both >> available >> and matches our syntax). Could be an idea to point to that for easy >> ICLA >> work :) >> >> >>> >>> On Sun, Dec 30, 2018 at 09:24, Craig Russell >>> wrote: >>> >>>> Hi Hugo, >>>> >>>> The intent is for the PMC member sending the invitation to do the >>>> check >>>> before sending the mail and edit the mail so the candidate only >>>> sees the >>>> appropriate option. >>>> >>>> I'll try to make this more clear in the instructions on the page >>>> that >>>> contains the sample email. [I originally had three different >>>> sample emails >>>> but they were all the same except for the paragraph B.] >>>> >>>> Thanks for the feedback. >>>> >>>> Craig >>>> >>>>> On Dec 29, 2018, at 9:32 PM, Hugo Louro >>>>> wrote: >>>>>
Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc3
Since the pull request was made about 8 hours ago, am I correct in thinking that the rc3 candidate still includes the jar with unknown contents and provenance? Mark, how could an EPL 1.0 jar with an AL 2 patch applied be uploaded to maven central? For one thing, what would the maven coordinates be? Thanks David Jencks Sent from my iPhone > On Feb 13, 2018, at 5:23 AM, Mark Struberg <strub...@yahoo.de.INVALID> wrote: > > I think this is reasonably enough for this release. > > We should keep an eye on it and probably someone can upload a fixed release > to maven.central. > > I've also checked the other parts and found no obvious problem > > So > > +1 (binding) > > > txs and LieGrue, > strub > > > >> Am 13.02.2018 um 08:32 schrieb Geertjan Wielenga >> <geertjan.wiele...@googlemail.com>: >> >> Proposed solution is in the issue -- >> >> https://issues.apache.org/jira/browse/LEGAL-361 >> >> https://github.com/apache/incubator-netbeans/pull/421 >> >> Gj >> >>> On Sun, Feb 11, 2018 at 8:55 PM, David Jencks <david.a.jen...@gmail.com> >>> wrote: >>> What happened to >>> LEGAL-361 <https://issues.apache.org/jira/browse/LEGAL-361> >>> ? >>> >>> My impression from this issue is that the previous RC included a binary jar >>> that was mostly EPL 1.0 but had at least one file that no one knew the >>> origin, contents, or license of. I don’t see that any progress has been >>> made on this issue, has the jar been removed from the new RC? I just >>> scanned a couple of the links below but didn’t see any mention of this. >>> >>> david jencks >>> >>>> On Feb 9, 2018, at 1:36 PM, Geertjan Wielenga >>>> <geertjan.wiele...@googlemail.com> wrote: >>>> >>>> Hi all, >>>> >>>> The Apache NetBeans community has voted on and approved a proposal to >>>> release Apache NetBeans 9.0 Beta (incubating) rc3. >>>> >>>> We now kindly request that the Incubator PMC members review and vote >>>> on this incubator release candidate. >>>> >>>> Apache NetBeans 9.0 Beta (incubating) constitutes all the modules >>>> currently in the Apache NetBeans Git repo, which together provide the >>>> NetBeans Platform (i.e., the underlying application framework), which >>>> was released as Apache NetBeans 9.0 Alpha (incubating), as well as all >>>> the modules that provide the Java SE-related features of Apache >>>> NetBeans. In short, Apache NetBeans 9.0 Beta (incubating) is a full >>>> IDE for Java SE development. >>>> >>>> Just like the Alpha release, the Beta release is focused specifically >>>> on IP clearance. With Beta, everything in Apache NetBeans Git complies >>>> with Apache IP clearance requirements: >>>> >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Beta >>>> >>>> Changes between rc1 and rc2 -- binaries wrongly included in source zip >>>> have been removed: >>>> >>>> https://issues.apache.org/jira/browse/NETBEANS-276 >>>> >>>> Changes between rc2 and rc3 -- problems identified by the rc2 IPMC >>>> vote by IPMC members Justin Mclean and John D. Ament have been solved >>>> or issues have been created: >>>> >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Beta+rc3 >>>> >>>> https://lists.apache.org/thread.html/8e9520d5e1e365ed2337940fb629c209c63efae24b0a2e44d50412a3@%3Cgeneral.incubator.apache.org%3E >>>> >>>> How to try out the Beta release: >>>> >>>> 1. Download the artifact to be voted on and unzip it. >>>> 2. Build it using the README provided by the artifact. >>>> 3. Look in nbbuild/netbeans for the NetBeans installation created by >>>> the build process. >>>> 4. Run the NetBeans executable and (if you're running on JDK 8) you'll >>>> be prompted to install nb-javac, after agreeing to its licensing >>>> terms, and (if you're running on JDK 9), you'll be able to use javac >>>> directly from JDK 9 and, optionally, you'll be prompted to install >>>> nb-javac, after agreeing to its licensing terms. >>>> >>>> Take note of the Apache Rat exclusions, which are now in a separate file: >>>> >>>> https://github.com/apache/incubator-netbeans/
Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc3
What happened to LEGAL-361 <https://issues.apache.org/jira/browse/LEGAL-361> ? My impression from this issue is that the previous RC included a binary jar that was mostly EPL 1.0 but had at least one file that no one knew the origin, contents, or license of. I don’t see that any progress has been made on this issue, has the jar been removed from the new RC? I just scanned a couple of the links below but didn’t see any mention of this. david jencks > On Feb 9, 2018, at 1:36 PM, Geertjan Wielenga > <geertjan.wiele...@googlemail.com> wrote: > > Hi all, > > The Apache NetBeans community has voted on and approved a proposal to > release Apache NetBeans 9.0 Beta (incubating) rc3. > > We now kindly request that the Incubator PMC members review and vote > on this incubator release candidate. > > Apache NetBeans 9.0 Beta (incubating) constitutes all the modules > currently in the Apache NetBeans Git repo, which together provide the > NetBeans Platform (i.e., the underlying application framework), which > was released as Apache NetBeans 9.0 Alpha (incubating), as well as all > the modules that provide the Java SE-related features of Apache > NetBeans. In short, Apache NetBeans 9.0 Beta (incubating) is a full > IDE for Java SE development. > > Just like the Alpha release, the Beta release is focused specifically > on IP clearance. With Beta, everything in Apache NetBeans Git complies > with Apache IP clearance requirements: > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Beta > > Changes between rc1 and rc2 -- binaries wrongly included in source zip > have been removed: > > https://issues.apache.org/jira/browse/NETBEANS-276 > > Changes between rc2 and rc3 -- problems identified by the rc2 IPMC > vote by IPMC members Justin Mclean and John D. Ament have been solved > or issues have been created: > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Beta+rc3 > > https://lists.apache.org/thread.html/8e9520d5e1e365ed2337940fb629c209c63efae24b0a2e44d50412a3@%3Cgeneral.incubator.apache.org%3E > > How to try out the Beta release: > > 1. Download the artifact to be voted on and unzip it. > 2. Build it using the README provided by the artifact. > 3. Look in nbbuild/netbeans for the NetBeans installation created by > the build process. > 4. Run the NetBeans executable and (if you're running on JDK 8) you'll > be prompted to install nb-javac, after agreeing to its licensing > terms, and (if you're running on JDK 9), you'll be able to use javac > directly from JDK 9 and, optionally, you'll be prompted to install > nb-javac, after agreeing to its licensing terms. > > Take note of the Apache Rat exclusions, which are now in a separate file: > > https://github.com/apache/incubator-netbeans/blob/master/nbbuild/rat-exclusions.txt > > If the above succeeds, i.e., Apache NetBeans installs and starts up, > you will have a Java SE development environment that complies with > Apache IP requirements. > > Apache NetBeans 9.0 Beta (incubating) rc3 vote thread: > > https://lists.apache.org/thread.html/f1c5a2a3077690f2c7785ed81c36f1ba1920efa01b26f3e7a5f32f2b@%3Cdev.netbeans.apache.org%3E > > Apache NetBeans 9.0 Beta (incubating) vote result thread: > > https://lists.apache.org/thread.html/079f610360463621276d6d8c99979991bded812559a34eff4458a073@%3Cdev.netbeans.apache.org%3E > > In the above, note there are two IPMC binding votes from Ate Douma and > Bertrand Delacretaz, both Apache NetBeans (incubating) mentors, and 31 > non-binding votes, from PPMC members and others in the Apache NetBeans > community. > > The source tarball, including signatures, digests, etc., as well as a > convenience binary, can be found at: > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta-rc3/ > > The tag to be voted upon is 9.0-beta-rc3: > > https://github.com/apache/incubator-netbeans/tree/9.0-beta-rc3 > > https://github.com/apache/incubator-netbeans/releases/tag/9.0-beta-rc3 > > Also note, if tag is not identical: > > https://lists.apache.org/thread.html/66daa753d25a482efecc5b86fdc00dc31250ca1448b533bfba82a51d@%3Cdev.netbeans.apache.org%3E > > The release hash is: > > 96974a6c59957fb3d8ff18b9dd8a9323ddb00968 > > ...which is found at: > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta-rc3/incubating-netbeans-java-9.0-beta-source.zip.sha1 > > KEYS file is available: > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS > > Please download the release candidate and evaluate the necessary items > including checking hashes, signat
Re: Apache Policy Quiz
I got inconsistent results from the same answer out of the same choices on the same question. It was not clear to me that many of the questions are “check all that apply”. Some of the questions are poorly worded, e.g. something like “can Apache rely on cat X software”: most of the projects I know about rely on Apache infra running Jira so it’s hard to call that an optional dependency of any kind. From the “explanations” of what we’re deemed my wrong answers I think the question was intended to be closer to “can an Apache project have a dependency on cat X software”. For many of the questions I thought there was a mismatch between my understanding of Apache policy and any of the possible answers presented, and I ended up feeling vaguely insulted. David Jencks Sent from my iPhone > On Jan 24, 2018, at 9:03 PM, Greg Stein <gst...@gmail.com> wrote: > > Every single question that I answered gave me a "not quite right". Even > when it asked if an Apache product can be distributed under Cat-X and I > said "No", it said "not quite right". That was a simple yes/no, and an > obvious "no" answer. ... That was the final straw after a series of > multiple-choice questions that I got "not quite right", thinking maybe I > missed some nuance. Not at all. When it said my "no" answer wasn't right... > Well. > > The quiz logic seems broken. > > > On Wed, Jan 24, 2018 at 7:49 PM, Justin Mclean <jus...@classsoftware.com> > wrote: > >> Hi, >> >> A while back I posted a little logo game. [1] Well after a few comments on >> the incubator list around projects possibly graduating without fully >> understanding ASF policy, and some issues with recent release got me >> thinking is there another way we can present this information. So I made a >> little multiple choice quiz on ASF policy. [2] Give it a try [3] and tell >> me what you think. (It’s probably harder and not as fun as the logo game >> but aimed at a different audience.) >> >> Currently it only has a dozen or so questions with some variation, so you >> may get the same question asked but it’s likely to have different answers >> in a different order. Anyway if people think this is useful perhaps we can >> expand it with more questions and broaden the scope to include other areas >> like the Apache Way, how the foundation works and the like. >> >> I may of made mistakes and it likely some words and sentences probably >> need correcting. Proof readers and PRs welcome. >> >> BTW it doesn’t save your scores anywhere so if you get a question wrong >> only you will know but hopefully you might learn something. Have a record >> of number of people taking the quiz and results by incubating project might >> be interesting but probably a little invasive. >> >> Thanks, >> Justin >> >> 1. https://github.com/justinmclean/ApacheLogos >> 2. https://github.com/justinmclean/ApacheQuiz >> 3. https://rawgit.com/justinmclean/ApacheQuiz/master/compiled/index.html >> - >> 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: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc2
To clarify a bit: > [snip] >> platform/modules/ext/org.eclipse.osgi_3.9.1.v20140110-1610.jar >> - I’m not sure if the OSGi license is compatible with the Apache one. It’s >> not listed in Category A/B/X you may need to ask on legal discuss. It may >> be under EPL but not 100% sure. >> > OSGI code is AL v2 licensed. If i have correctly identified the jar under discussion http://hg.netbeans.org/binaries/E5DDC5E827D3D62E7BE9F7E32927CA01F2839971-org.eclipse.osgi_3.9.1.v20140110-1610.jar <http://hg.netbeans.org/binaries/E5DDC5E827D3D62E7BE9F7E32927CA01F2839971-org.eclipse.osgi_3.9.1.v20140110-1610.jar> it contains a version of equinox, the eclipse foundation implementation of an OSGI framework; this is EPL 1.0 licensed if obtained directly from the eclipse foundation, but may be licensed differently if redistributed. It’s unclear to me what is in this jar from the discussion about it on https://issues.apache.org/jira/browse/LEGAL-361 <https://issues.apache.org/jira/browse/LEGAL-361> > Apache Felix is using those as well, I think? Apache Felix uses OSGI code packaged by OSGI and typically distributed via maven central. This is all ALv2 licensed. Some Felix subprojects can be configured to use unmodified equinox (the eclipse OSGI framework implementation) for testing as well as the Felix framework implementation. As far as I know no Felix subprojects depend on any equinox jars for non-test purposes. [snip] david jencks
Re: Machine Learning in METRON
I know nothing whatsoever about metron, but poking around the metron website I found Dev VM Install <https://cwiki.apache.org/confluence/display/METRON/Dev+VM+Install> leading to https://github.com/apache/incubator-metron/tree/master/metron-deployment/vagrant/full-dev-platform which appears to have build instructions… cd incubator-metron mvn clean package -DskipTests I tend to think that if this project actually does love its community it would make some information about how to check out the code and build really really extremely blatantly obvious from the front page of the website and also explain why the instructions I found are at GitHub rather than apache. david jencks > On Feb 18, 2017, at 6:28 PM, Martin Gainty <mgai...@hotmail.com> wrote: > > Casey/Sergio: > > > i appreciate the plethora of documentation on maintaining licenses..looking > for doc on > how to build metron? > > can i assume these preliminary steps: > > > compile? > > jar? > > build binary for vm? > > yaml deploy to vm? > > re: certs/keys to coordinate to security config.. if so where to acquire > cert(s)/key(s)? > > > Martin > __ > > > > > From: Casey Stella <ceste...@gmail.com <mailto:ceste...@gmail.com>> > Sent: Friday, February 17, 2017 9:30 AM > To: general@incubator.apache.org <mailto:general@incubator.apache.org> > Subject: Re: Machine Learning in METRON > > Oh, one more thing. There's a small, but important typo in the email > address for the mailing list by Sergio: it's > u...@metron.incubator.apache.org (subscribe by sending an email to > user-subscr...@metron.incubator.apache.org) > > On Fri, Feb 17, 2017 at 6:26 AM, Casey Stella <ceste...@gmail.com> wrote: > >> Just wanted to chime in and reinforce that you should engage with the >> Metron community as Sergio says. We love our community and are happy to >> help where we can. :) >> >> Casey >> >> On Fri, Feb 17, 2017 at 1:21 AM, Sergio Fernández <wik...@apache.org> >> wrote: >> >>> Hi, >>> >>> you can find the documentation at >>> http://metron.incubator.apache.org/documentation/ > Apache Metron (Incubating) > Documentation<http://metron.incubator.apache.org/documentation/ > <http://metron.incubator.apache.org/documentation/>> > metron.incubator.apache.org <http://metron.incubator.apache.org/> > The Quick Start installation fully automates the provisioning and deployment > of Apache Metron (Incubating) and all necessary prerequisites on a single, > virtualized ... > > > >>> >>> You should better reach the folks directly at >>> us...@metron.incubator.apache.org (subscribed sending fist a mail to >>> users-subscr...@metron.incubator.apache.org). >>> >>> Cheers, >>> >>> On Feb 17, 2017 10:13, "Savakh S" <sova...@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I saw METRON can do machine learning analysis but I didn't find this >>>> feature when I installed the product. Could you please explain me more >>>> about ML in METRON ? >>>> >>>> Many thanks. >>>> >>>> BR
Re: [RESULT][VOTE] Accept RocketMQ into the Incubator
I didn’t vote here, but I rarely indicate my vote is binding although it
usually is. Checking here which votes are binding would have taken quite a
while…. perhaps in the future asking people to indicate if their vote is
binding would help.
thanks
david jencks
> On Nov 21, 2016, at 10:30 AM, Bruce Snyder <bruce.sny...@gmail.com> wrote:
>
> Hi John,
>
> I relied on the binding count based on people stating that their vote is
> binding. Is this incorrect?
>
> Bruce
>
> On Mon, Nov 21, 2016 at 10:45 AM, John D. Ament <johndam...@apache.org>
> wrote:
>
>> Bruce
>>
>> Please double check your binding list.
>>
>> On Nov 21, 2016 12:24, "Bruce Snyder" <bsny...@apache.org> wrote:
>>
>>> The vote passes with 38 +1 votes (5 binding) and no -1 votes. Below are
>> the
>>> results:
>>>
>>> Jochen Wiedmann +1 (binding)
>>> Rob Davies +1
>>> Bertrand Delacretaz +1
>>> John D. Ament +1
>>> Myrle Krantz +1
>>> Debo Dutta +1
>>> Amol Kekre +1
>>> Leif Hedstrom +1
>>> P. Taylor Goetz +1
>>> Stian Soiland-Reyes +1
>>> Willem Jiang +1 (binding)
>>> Justin Mclean +1 (binding)
>>> 张轲 +1
>>> Zhanhui Li +1
>>> ShaoFeng Shi +1
>>> Jian Zhong +1
>>> 冀全喜 +1
>>> wei zhou +1
>>> Feng Longda +1
>>> Hust Fxj +1
>>> Quanxi Ji +1
>>> Qun Zhao +1
>>> Hao Chen +1
>>> Luke Han +1
>>> ji luo +1
>>> Chunhui Shen +1
>>> Xiaorui Wang +1
>>> Xinyu Zhou +1
>>> Huxing Zhang +1
>>> Dong Li +1
>>> Danese Cooper +1 (binding)
>>> Liang Chen +1
>>> Julian Hyde +1 (binding)
>>> Bruno Mahé +1
>>> 冯嘉 +1
>>> Liangfei Su +1
>>> zhen dong +1
>>> 金吉祥 +1
>>>
>>> Thank you to everyone who participated in the vote.
>>>
>>> Please welcome RocketMQ to the Apache Incubator!
>>>
>>> Bruce
>>>
>>> --
>>> perl -e 'print unpack("u35",
>>> "\@0G)U8V4\@4VYY9&5R\"F)S;GED97)\`87!A8VAE+F]R9PH\`");'
>>>
>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>> Blog: http://bruceblog.org/
>>> Twitter: http://twitter.com/brucesnyder
>>>
>>
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ <http://bruceblog.org/>
> Twitter: http://twitter.com/brucesnyder
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Dataflow Incubator Proposal
> On Jan 20, 2016, at 8:32 AM, James Malone <jamesmal...@google.com.INVALID> > wrote: > > The Dataflow programming model has been designed with simplicity, > scalability, and speed as key tenants. s/tenants/tenets? david jencks
Re: Concerning Sentry: A disagreement over the Apache Way and graduation
> On Nov 2, 2015, at 11:29 AM, Rich Bowen <rbo...@rcbowen.com> wrote: > > > > On 11/02/2015 09:50 AM, David Jencks wrote: >> I haven’t looked at what they are doing and don’t expect I will. However, >> I’m assuming that jira changes all get to the dev list, as in all other >> projects I’ve worked on. I don’t see the point in duplicating a proposal >> between a jira issue and a separate dev list post with the same information. >> And I don’t have a problem with people working quickly. I would like to >> see that the jira issue explains sufficiently what is proposed or >> implemented in enough detail that an interested party can see how it fits in >> with the code and the purpose of the project. So I’d be concerned if the >> jira descriptions were “fix bug” or “implement javaee7” but possibly not if >> there are reasonable explanations of what is being proposed or done. > > What has been described to me is that a ticket is filed proposing a major new > feature, and then seconds later a *large* patch lands implementing that > feature, and the ticket is closed, and discussion is shut down, because it's > a done deal. > Well, for me closing an issue by no means discussion is shut down…. I’m happy to complain years later. However irrespective of the level of detail in a jira, I’d expect it to be filed when the idea behind it is hatched, not when development on it is complete. The behavior you describe seems completely inappropriate to me, and I’m fairly shocked a mentor would support it. thanks for the clarification. david jencks - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Concerning Sentry: A disagreement over the Apache Way and graduation
pening in the first place until this community process is straightened out. > > I haven’t looked at what they are doing and don’t expect I will. However, I’m assuming that jira changes all get to the dev list, as in all other projects I’ve worked on. I don’t see the point in duplicating a proposal between a jira issue and a separate dev list post with the same information. And I don’t have a problem with people working quickly. I would like to see that the jira issue explains sufficiently what is proposed or implemented in enough detail that an interested party can see how it fits in with the code and the purpose of the project. So I’d be concerned if the jira descriptions were “fix bug” or “implement javaee7” but possibly not if there are reasonable explanations of what is being proposed or done. david jencks - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3
I thought the more-up-to-date version of the backport stuff was here: http://backport-jsr166.sourceforge.net/ david jencks On Mar 21, 2015, at 6:24 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: --089e0112c408e2ec4c0511c9d829 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 21, 2015 at 3:14 AM, Jochen Theodorou blackd...@gmx.org wrote= : Am 21.03.2015 10:47, schrieb Branko =C4=8Cibej: [...] Do you happen to know exactly which versions of those files were imported? I looked at the ConcurrentHashMap implementation and compared the current version on that site: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/ jsr166e/ConcurrentHashMapV8.java?revision=3D1.123 with the one in the Ignite release package, and the differences are far larger than just license header changes: https://paste.apache.org/p/3SAz I suggest comparing with the history of the OpenJDK8 file: http://hg.openjdk.java.net/jdk8/jdk8/jdk/log/687fd7c7986d/src/share/ classes/java/util/concurrent/ConcurrentHashMap.java There have been quite a few changes in jdk8 for this map afaik Yes, good idea, and thanks for the link! I specifically find this comment interesting there: 20 months ago psandoz 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org --089e0112c4 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenAZ as new Incubator project
It'e really unlikely I will be able to contribute in any way to this any time soon, but I think it would be awesome if this was at apache. When I tried to investigate xacml a few years ago the major stumbling block I found was not being able to look at any reasonable implementation. (I remember something about the sun implementation but for some reason it was not in a form I could learn anything from). thanks david jencks On Nov 13, 2014, at 1:14 PM, Hal Lockhart hal.lockh...@oracle.com wrote: Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantics equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface
Re: [DISCUSS] [VOTE] Graduation of Apache Spark from the Incubator
I agree with Joe, voting on a moving target is not going to produce a result anyone can look back on and understand. Chris, you may be able to understand what is happening but I'm having trouble from my attempts to follow this thread. thanks david jencks On Feb 9, 2014, at 5:29 PM, Joseph Schaefer joe_schae...@yahoo.com wrote: Chris no offense but all we can do is vote on what you put in front of us. As soon as you realized that that document was a mess the vote should have been cancelled. Right now you have no clear picture of what each vote *means* because the thing we are supposed to be approving is in flux. Right now you have people voting on the subject on moral grounds, eg whether the project deserves to graduate, all mixed in with votes cast on technical objective grounds. The only way to fix this is with a fresh start IMO. Sent from my iPhone On Feb 9, 2014, at 8:19 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Sebb, -Original Message- From: sebb seb...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Sunday, February 9, 2014 4:39 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [VOTE] Graduation of Apache Spark from the Incubator On 9 February 2014 17:11, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Thanks Matei and sebb. Starting a new thread and collecting the VOTEs all over again would be time consuming. So? I don't appreciate this tone -- what do you mean so? Better to than being confusing, as the current thread has become. The thread's not confusing to me at all -- The diligence to update the resolution to the specific Apache IDs has been performed by Matei, so that work is done. I'll make the typo fix in the pasted board resolution, so that will be done too. Also it may not be clear whether new votes are intended for the update resolution or the old one. Do the original votes even count for the amended resolution? Actually it's quite clear to me and to those who VOTEd, some multiple times. If folks have an issue as I mentioned, I've left the VOTE open for quite a long bit of time and am closing it tomorrow. That's plenty of time for folks to amend their VOTE should they have wanted to. Cheers, Chris -Original Message- From: sebb seb...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Sunday, February 9, 2014 7:10 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [VOTE] Graduation of Apache Spark from the Incubator I think it would be better to start a new thread with the updated text. Also, the two scope descriptions are slightly different: related to fast and flexible large-scale data analysis on clusters. v. related to efficient cluster management, resource isolation and sharing across distributed applications I don't know whether that is important or not. On 8 February 2014 22:46, Matei Zaharia matei.zaha...@gmail.com wrote: Thanks everyone for the votes. Since we now have accounts for everyone, I've updated the committer list below to include ASF IDs. Thanks to INFRA, we also now have both pull request postings and comments on them forwarded to the our mailing list. snip WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to fast and flexible large-scale data analysis on clusters. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Spark Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Spark Project be and hereby is responsible for the creation and maintenance of software related to efficient cluster management, resource isolation and sharing across distributed applications; and be it further RESOLVED, that the office of Vice President, Apache Spark 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 Spark Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Spark Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Spark Project: * Mosharaf Chowdhury mosha...@apache.org * Jason Dai jason...@apache.org * Tathagata Das t...@apache.org * Ankur Dave ankurd...@apache.org * Aaron Davidson a...@apache.org * Thomas Dudziak to...@apache.org * Robert Evans bo...@apache.org * Thomas Graves tgra...@apache.org * Andy Konwinski
Re: [PROPOSAL] Ivory - Hadoop data management and processing platform
Falcon is also the name of a database engine: http://en.wikipedia.org/wiki/Falcon_(storage_engine) the name of a programming language http://falconpl.org/project_docs/core/index.html and very close to the name of some kind of oracle add on vendor: http://www.falconstor.com/solutions/business-applications/oracle-database-solutions david jencks On Mar 20, 2013, at 10:02 PM, Srikanth Sundarrajan srikanth.sundarra...@inmobi.com wrote: Hi Justin, I am assuming it won't be an issue as Falcon used within the Adobe/Apache Flex isn't related to Hadoop. Regards Srikanth Sundarrajan On Thu, Mar 21, 2013 at 10:23 AM, Justin Mclean justinmcl...@gmail.comwrote: Hi, JFYI Falcon is already a name used by Adobe and Apache Flex. It's an AS compiler and an experimental AS to JS compiler (Falcon JS) - not sure if that is an issue or not. Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- _ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: UMA Implementation
A couple more points - It is likely that step (3) will involve a code grant of some kind by the current copyright owner(s). See software grants on http://www.apache.org/licenses/ and http://www.apache.org/licenses/software-grant.txt - Your contribution is much more likely to be accepted if you intend to continue working on it and in this case integrate it with the rest of the amber codebase. I'm not really familiar with what amber does or the state of the code or whether amber already implements some of the same functionality so I have no real idea what integration might mean here: it might be build integration, replacing current code, merging code bases, or something entirely different. However code dumps of an existing project with no further development work, while occasionally useful, often provide little value. If you plan to continue to contribute you'll need to provide a CLA (see http://www.apache.org/licenses/ ) and your employer may need to provide a CCLA. thanks david jencks On Jul 5, 2012, at 11:42 AM, Raymond Feng wrote: Hi, Suleman. Thank you for your interest to contribute UMA code into Apache Amber project. You cannot directly commit the code into Amber though. Here is a simple process to follow: 1) Start some discussions with Amber community to express your intention of contribution (It's glad that you are starting the thread now :-) 2) Open a JIRA and attach the code to the ticket 3) The Amber community needs to vote to take the contribution (assuming the result is YES :-) 4) The Amber PMC needs to go through IP clearance with Apache incubator PMC (assuming everything is clean) 5) One of the Amber committers check the patch into Amber SVN repo 6) UMA team will continue to work with the Amber project and the Amber community starts to vote your team members in as committers based on your ongoing contributions Thanks, Raymond On Jul 5, 2012, at 5:52 AM, Suleman Khan wrote: Hello All, In Fraunhofer AISEC, we developed UMA protocol based on OAuth 2.0 and also integrated OpenID Connect to it. We want to make this project open source under Apache license 2.0. By the suggestion of Mr. Antonio Sanso, we had a look at Apache Amber project and we think that this is the best place where we can upload our code. Details about the project is published on Kantara Initiative website. It can be checked by visiting the following link. http://kantarainitiative.org/confluence/display/uma/Fraunhofer+AISEC+Implementation+FAQ I was trying to commit our code to Apache Amber repository but I need credentials for that, which I don't have. Could you please tell how to get these credentials and what is the procedure for doing all this stuff. Any help in this regard would be really appreciated. Regards, Khan Suleman * From:* Antonio Sanso [mailto:asa...@adobe.com] *Sent:* Mittwoch, 4. Juli 2012 19:10 *To:* general@incubator.apache.org *Cc:* alam.moham...@aisec.fraunhofer.de *Subject:* Re: UMA Implementation Hi Suleman, you might want to give a look at the Amber project [0] (that is still in the incubation phase though). We have already an UMA implementation but any contribution is more than welcome :) On how to become a committer, you should be able to earn your karma by contributing the project (as any Apache project). In [1] you can find a description of Roles in Apache. Regards Antonio [0] http://incubator.apache.org/amber/ [1] http://www.apache.org/foundation/how-it-works.html#roles On Jul 4, 2012, at 5:46 PM, Suleman Khan wrote: Dear All, In Fraunhofer AISEC, we developed UMA protocol based on OAuth 2.0 and also integrated OpenID Connect to it. We want to make this project open source under Apache license 2.0. Apache website doesn't clearly tell us how to do it. I have the following questions 1). Should we add it to any existing project? if yes then how to do it? (we are not committer. how to become a committer for a project?) 2). Should we create new project for it? if yes the how to do it? Details about the project is published on Kantara Initiative website. It can be checked by visiting the following link. http://kantarainitiative.org/confluence/display/uma/Fraunhofer+AISEC+Implementation+FAQ Any help in this regard would be really appreciated. Regards, Khan Suleman - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org mailto:general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org mailto: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: [VOTE] Apache BVal as a TLP
+1 david jencks On Feb 8, 2012, at 6:39 AM, Mohammad Nour El-Din wrote: Hi... It has been discussed, since a while, about the graduation of Apache BVal, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. It also has been decided to name the project Apache BVal [6]. The resolution charter content has been discussed and reviewed here [7]. *NOTE*: As per Niall's request, his name has been removed from the proposed PMC [8]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [9] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/tY http://markmail.org/message/kzqgd7ff7t6p62va [7] - *http://s.apache.org/49R* [8] - http://s.apache.org/JYS [9] - See below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache BVal 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 Management Committee charged with the creation and maintenance of open-source software related to the Bean Validation Specification and its implementation as Apache BVal for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache BVal Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache BVal Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with the Bean Validation Specification and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache BVal 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 BVal Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache BVal Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache BVal Project: - Albert Lee allee8...@apache.org - Carlos Vara Callau carlosv...@apache.org - David Jencks djen...@apache.org - Donald Woods dwo...@apache.org - Gerhard Petracek gpetra...@apache.org - Jeremy Bauer jrba...@apache.org - Kevan Lee Miller ke...@apache.org - Luciano Resende lrese...@apache.org - Matthias Wessendorf mat...@apache.org - Matthew Jason Benson mben...@apache.org - Mohammad Nour El-Din mn...@apache.org - Roman Stumm romanst...@apache.org - Simone Tripodi simonetrip...@apache.org - Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache BVal, 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 initial Apache BVal PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache BVal Project; and be it further RESOLVED, that the Apache BVal Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Poddling new committer process
+1 (with the one required mentor/IPMC vote and notifying private@) david jencks On Nov 12, 2010, at 7:41 AM, Glen Daniels wrote: +1 from me. I also agree with Bertrand's point about notifying private@, and would be OK with requiring a (single) mentor/IPMC vote to ensure that someone is paying attention... but it would be nice if we didn't need two. --Glen On 11/12/2010 3:20 AM, ant elder wrote: I'd like to propose that the process for Incubator poddlings to make someone a new committer is simplified so that all that is needed are votes from poddling committers and that there is no longer any need for votes from Incubator PMC members or a separate Incubator PMC vote. As justification, this is the process that was in place some years ago and it worked fine like that, there is the experiment currently in place with some poddlings doing this which seems to be working ok, and the board has said they're ok with it. ...ant - 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: [VOTE] Apache SIS 0.1-incubating Release Candidate #2
I agree with ant that you should clean this up before releasing. frustrating but worthwhile. I also agree with what he thinks should be removed. thanks david jencks On Nov 10, 2010, at 2:12 PM, ant elder wrote: On Wed, Nov 10, 2010 at 9:54 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Ant, Thanks. Do you see any of the below as a blocker to the first release? What extra stuff, specifically, do you see that wasn’t present in the prior where that you +1’ed and thought was OK as a first release? Cheers, Chris In NOTICE file http://svn.apache.org/repos/asf/incubator/sis/tags/0.1-incubating/NOTICE.txt everything after the line The Apache Software Foundation (http://www.apache.org/). shouldn't be there. In the LICENSE file http://svn.apache.org/repos/asf/incubator/sis/tags/0.1-incubating/LICENSE.txt everything including and after the line APACHE TIKA SUBCOMPONENTS shouldn't be there (should it? what is using those extra licenses?). I'd not noticed the extra stuff in the LICENSE file in RC1 but its the RC2 NOTICE file that i think is the blocker - license text does not belong in the NOTICE file. ...ant - 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: podling reporting
I think they are complementary. Incubator projects (as well as all other projects) need to report periodically to the board (for incubator, these are glued together into one report). In addition each incubator project has a bunch of steps it has to progress through to graduate. The like you found relates to keeping a page tracking those steps that up to date. Maybe it would be better to call the page mentioned in the link you found the status page and the stuff that goes to the board a status report? thanks david jencks On Sep 5, 2010, at 3:32 PM, Benson Margulies wrote: There's this: http://incubator.apache.org/guides/website.html#Edit+your+project+status+report . And then the River folks got a reminder email with other instructions, as per this message from Tom Hobbs. No, that's not what I did. I followed the Confluence link in the Your report is due email and edited the wiki page. Are these dueling instructions for the same reporting process? Or dueling reporting processes? Or complementary reporting processes? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 27, 2010, at 5:22 AM, Grant Ingersoll wrote: On Aug 24, 2010, at 5:55 PM, Upayavira wrote: On Wed, 2010-08-25 at 06:41 +1000, Gav... wrote: I think the title of the name change is a little misleading. We are not Replacing 'Lucene' with 'Apache' . Apache is a given. IOW - The proposal is either: Change Apache Lucene Connectors Framework to Apache Connectors Framework or: Change Lucene Connectors Framework to Connectors Framework It should therefore be clear that the only change being proposed here is the 'dropping' of the word 'Lucene' due to the fact that Lucene is no longer its governing TLP. But people aren't going to be thinking about governing TLPs when making assumptions about a name. Does this project actually relate to Lucene or not? Apache Connectors Framework tells me it is either a generic connectors framework for connecting anything to anything, or it is for connecting httpd to something else, neither of which I suspect are what it is all about. It is, perhaps, worthwhile to give a brief description about the project, taken from the website: snip The Apache Connectors Framework (ACF) is an effort to provide build and support an open source framework for connecting source content repositories like Microsoft Sharepoint and EMC Documentum, to target repositories or indexes, such as Apache Solr. ACF also defines a security model for target repositories that permits them to enforce source-repository security policies. Currently included connectors support FileNet P8 (IBM), Documentum (EMC), LiveLink (OpenText), Patriarch (Memex), Meridio (Autonomy), Windows shares (Microsoft), and SharePoint (Microsoft). Also included are a general file system connector, a general JDBC connector, a general RSS crawler, and a general web crawler. Currently supported targets include Apache Solr and QBase (formerly MetaCarta) GTS. The complete repository compatibility list can be found here. /snip While it supports targets for Solr, it is not a Solr/Lucene only thing. The framework intends to be a generic connector framework such that if someone implements the source and the sync according to the framework design, it will work. FWIW, as was pointed out on the connector mailing list, there are also many other generic/descriptive names in Apache (disregarding the granddaddy of them all: HTTP Server, which I realize, of course, is a different story): HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML, XMLBeans, XML Graphics, Directory, Logging, OpenEJB, OpenJPA, Portals, Perl, TCL. Perhaps we should call it the Open Connector Framework? Or maybe if we remove the spaces, as in OpenConnectorFramework, then we are good? Of those at least Web Services, XML, Logging, and Portals are sort of psuedo-projects that aggregate related little projects in that area. Along with the OpenFoo family there's the ActiveFoo family :-). For me as a know-nothing outsider the suggestion of Content Connector Framework pointed me a bit towards what it does. OpenContentConnectorFramework is descriptive but a bit long. OpenCCF? To try to illustrate my thinking rather than push a name down your throat... Open ConnectorFramework/OpenConnectorFramework/OpenCF OK, since you've added a branding word. Not ideal since the purpose appears overly broad Content Connector Framework/ContentConnectorFramework/CCF OK, since you've clarified the scope. Not ideal since has no branding word. OpenContentConnectorFramework/OpenCCF better since it clarifies the scope and includes a branding word. thanks david jencks -Grant - 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: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 26, 2010, at 3:41 AM, Grant Ingersoll wrote: On Aug 25, 2010, at 10:26 AM, Upayavira wrote: On Wed, 2010-08-25 at 09:50 -0400, Grant Ingersoll wrote: So, how does this get resolved? Shall I call a formal vote for the IPMC? I rather like the name, but (somewhat) understand the objections. That being said, I'm not all that clever at naming, so... You rather like which name?? ACF My take: 1. come up with a name. 2. check for exixting uses of that name 3. if it passes #2 then get support of your PPMC 4. Propose it to IPMC. 5. Vote on the IPMC about the name. If you want, you can add #4a: discuss with IPMC whether a vote is really required for this, in which case you might be able to skip #5, but that process would probably be slower in the end! Well, I would argue we did all that, with the exception of a formal IPMC vote (although we did ask here). It seemed to pass muster until a week later, a fair amount of time after we went and made the changes. I responded within 5 hours of the proposal. AFAICT the PPMC members have not responded to that post at all. thanks david jencks Upayavira On Aug 25, 2010, at 7:42 AM, Upayavira wrote: On Wed, 2010-08-25 at 06:49 -0400, Grant Ingersoll wrote: Sure would have been nice if these objections (other than David's) would have been brought up last week before we went and changed everything (after waiting several days for feedback) b/c we were working under the assumption that no one thought it was a problem. At any rate, we'll go discuss. I apologise for that. Unfortunately it was (for me) one of those situations when it takes a resonable volume of mail before it attracts my attention enough to read what is being said. Upayavira - 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 -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8 - 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: Name change from Lucene Connectors Framework to Apache Connectors Framework
As I attempted to politely make clear earlier I find this name extremely confusing. Web connectors are just one subject area I assume this project covers. I think its generally a good idea if projects don't use their names to imply they are the only apache implementation of a certain kind of functionality. In this case it seems to me that the name is implying that it is the official sole apache implementation of at least two distinct kinds of functionality other than what it actually does. (web container connectors of which mod_jk is an example and java connector architecture). To be blunt I think this is a really bad name and feels to me a bit like a land grab. thanks david jencks On Aug 23, 2010, at 11:38 PM, Simon Willnauer wrote: On Mon, Aug 23, 2010 at 11:36 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 21, 2010, at 6:30 AM, Pid * wrote: Isn't there a risk of causing confusion with the Apache HTTPD mod_jk / Tomcat Connector? Looks pretty distinct to me. I agree, the risk that people confuse those two seems very low. Especially since the mod_jk has been around for a while and is usually referred to as mod_jk and not as Tomcat Connector AFAIK but I can be wrong about the latter. simon p On 18 Aug 2010, at 16:17, Grant Ingersoll gsing...@apache.org wrote: Do you think this requires a formal IPMC vote or can we just do it? Thankfully, I think most of our mailing lists, etc. are already generic, so we shouldn't really need to change much in terms of branding other than the primary website. On Aug 16, 2010, at 7:49 PM, Noel J. Bergman wrote: Grant Ingersoll wrote: The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? LCF is not a subproject of Lucene at the moment, since it is in the Incubator. Nothing else project wise would change other than the name at this point. Unless there is an objection, I don't see a problem. Nothing in Apache Connectors Framework smacks of a possible trademark issue. --- Noel - 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 - 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: [VOTE] Apache Shiro graduation as TLP
Dunno if it's exactly documentation but see this from Roy Fielding https://issues.apache.org/jira/browse/LEGAL-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732740#action_12732740 Based on this I've been advising projects to put the apache LICENSE and and a NOTICE file that covers the actual contents of svn (i.e. not including stuff that is added to binaries as part of the build process) at expected svn checkout roots such as, here, http://svn.apache.org/repos/asf/incubator/shiro/trunk. I don't consider this a barrier to graduation.. +1 david jencks On Aug 16, 2010, at 12:59 PM, Kalle Korhonen wrote: On Mon, Aug 16, 2010 at 11:43 AM, sebb seb...@gmail.com wrote: Also, just noticed that the SVN tree does not appear to have a copy of the LICENSE file. Normally this is stored alongside the NOTICE file at the top-level, i.e. in http://svn.apache.org/repos/asf/incubator/shiro/trunk/ Looks like the file was deleted in the following commit: r979180 | kaosko | 2010-07-26 07:45:44 +0100 (Mon, 26 Jul 2010) | 1 line Was this intentional? Yes, that was intentional, see the commit message: Follow through on the suggestions given when 1.0.0 release was made. Removed LICENSE.txt as that is added to the source distro via Apache parent pom and its remote resource plugin configuration. Renamed NOTICE.txt to NOTICE so it'll replace the default one. Note that http://www.apache.org/legal/src-headers.html#notice indicates that the LICENSE file needs to be present only in the source distro (and not in svn as Sebb claimed) so we are ok. Also note that ant suggested removing the SoftHashMap and Spring related comments completely from NOTICE file but they are regarding copyrights so look fine to me, will confirm on dev list. If you can point out any documentation that says LICENSE will is required in svn, I'll put it in otherwise I'll avoid the redundancy. In any case, thanks for taking a look! More recently, I also integrated apache-rat (the maven plugin) to our build process. Kalle - 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 Aug 17, 2010, at 3:24 PM, Kalle Korhonen wrote: On Tue, Aug 17, 2010 at 2:09 PM, David Jencks david_jen...@yahoo.com wrote: Dunno if it's exactly documentation but see this from Roy Fielding https://issues.apache.org/jira/browse/LEGAL-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732740#action_12732740 Based on this I've been advising projects to put the apache LICENSE and and a NOTICE file that covers the actual contents of svn (i.e. not including stuff that is added to binaries as part of the build process) at expected svn checkout roots such as, here, http://svn.apache.org/repos/asf/incubator/shiro/trunk. I don't consider this a barrier to graduation.. +1 Thanks (and for voting too!). Seems that I'm not only one who's been pondering about this. With 17 Maven sub-modules of Shiro seems that we'd need 17 copies of the license files scattered around our source tree. I'm with Stefano there: I do contest the view that svn is the release, but let's leave that for another thread. Unless your 17 sub-modules are under separate release cycles I wouldn't consider them expected svn checkout roots so one copy of the license at the root would be sufficient. I have somewhat mixed feelings about this policy. On the one hand it's a nuisance to include a LICENSE file in svn where it isn't part of an official apache release, thus possibly not legally required, On the other hand I think that for most projects where there only a few expected svn checkout roots it serves to greatly increase clarity and convenience for non-asf-pros who happen to check out the source tree to have a quick look. So on balance I think its a good idea. If you really want to torture yourself you can look up the discussion of this and related issues on legal-discuss :-) thanks david jencks I'm watching the issue and perhaps I'll restore the LICENSE file on top of the tree. Kalle On Aug 16, 2010, at 12:59 PM, Kalle Korhonen wrote: On Mon, Aug 16, 2010 at 11:43 AM, sebb seb...@gmail.com wrote: Also, just noticed that the SVN tree does not appear to have a copy of the LICENSE file. Normally this is stored alongside the NOTICE file at the top-level, i.e. in http://svn.apache.org/repos/asf/incubator/shiro/trunk/ Looks like the file was deleted in the following commit: r979180 | kaosko | 2010-07-26 07:45:44 +0100 (Mon, 26 Jul 2010) | 1 line Was this intentional? Yes, that was intentional, see the commit message: Follow through on the suggestions given when 1.0.0 release was made. Removed LICENSE.txt as that is added to the source distro via Apache parent pom and its remote resource plugin configuration. Renamed NOTICE.txt to NOTICE so it'll replace the default one. Note that http://www.apache.org/legal/src-headers.html#notice indicates that the LICENSE file needs to be present only in the source distro (and not in svn as Sebb claimed) so we are ok. Also note that ant suggested removing the SoftHashMap and Spring related comments completely from NOTICE file but they are regarding copyrights so look fine to me, will confirm on dev list. If you can point out any documentation that says LICENSE will is required in svn, I'll put it in otherwise I'll avoid the redundancy. In any case, thanks for taking a look! More recently, I also integrated apache-rat (the maven plugin) to our build process. Kalle - 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: Incubator Board Report - August 2010
Sorry for the lateness, as one of the Amber mentors I would like to sign off on the amber portion of this report. thanks david jencks On Aug 16, 2010, at 11:52 AM, Noel J. Bergman wrote: Matt Benson, Srinath Perera, and Michael McCandless all joined the Incubator. Several more will be joining this week. Shiro is set to graduate, and it seems that at least a couple of projects are in good shape to graduate in the near future. On to a topic for the Board's attention. There has been some lively discussion this past week, initiated by Joe Schaefer regarding making Incubator projects more self-governing. Although a valid goal, the actual proposals appear troubling in terms of ASF governance structure. A specific proposal, for which Joe would like a formal vote, amounts to whether the ASF Board approves the granting of Committer status without PMC approval, and bypassing the PMC on the matter. Individual current and past Directors have already engaged, but it is requested that the Board consider the issue, and respond. -- = Amber = Amber is a project to develop a Java library which provides an API specification for, and an unconditionally compliant implementation of the OAuth v1.0, v1.0a and v2.0 specifications. OAuth is a mechanism that allows users to authenticate and authorise access by another party to resources they control while avoiding the need to share their username and password credentials. The most important issues that must be addressed before graduation are: * attract new users and developers * making a release The Incubator PMC / ASF Board should be aware that: * Involved people have been very busy due to personal/business issues in the last month. Latest activity: * apply the API definition choices approved by the community. * started implementing the Signing algorithms. Next steps: * finalize the API definition. * implementation of different specification versions (client and server). Community: * The community is in the first stages of formation and solely consists of the developers, though a few users start to appear on the mailing lists. = Bluesky = Did not report, but has reported several months running. The only activity observed is the following e-mail: http://mail-archives.apache.org/mod_mbox/incubator-bluesky-dev/201008.mbox/% 3caanlkti=nafbwoofuu1faxkxyxaiqf2rat5zqdcl1p...@mail.gmail.com%3e = BeanValidation = Apache Bean Validation will deliver an implementation of the JSR303 Bean Validation 1.0 specification. BVAL entered incubation on March 1, 2010. A list of the three most important issues to address in the move towards graduation. * First release of artifacts - Done * Grow the community and committer base - ongoing * Decide on graduation target of TLP or subproject - TBD Any issues that the Incubator PMC or ASF Board might wish/need to be aware of? * None at this time. How has the community developed since the last report? * Committer offer was extended and accepted by Matt Benson. * A couple of new users on the dev list. How has the project developed since the last report? * Currently a 0.2-incubating RC2 release vote is underway. = Chukwa = Chukwa is a distributed log collection and processing system built on top of Hadoop. It is a former Hadoop subproject. CLAs are on file and ASF holds all copyrights. We have been in incubation since July 13, 2010. Since then, we have switched to incubation SVN naming and updated our website to reflect this change. We still need to move mailing lists to incubation. [Pending on Bernd.] We still need to move our website to incubator.apache.org [Pending on permissions]. Should bring onboard more committers; Bill Graham would be the first Chukwa commiter not originally part of the project. = Clerezza = Clerezza (incubating since November 27th, 2009) is an OSGi-based modular application and set of components (bundles) for building RESTFul Semantic Web applications and services. The are currently no issues requiring board attention. Recent activity: * Added support for roaming useres with WebId * Added support for ssl * Started support for editing own foaf-profile with cleint certificate generation * Faster ScalaServer Pages using Scala 2.8.0 * Improved User documentation Next steps: * Streamline architecture around type-handlers and type-renderer * Add ability to easily overwrite the styling in full or partially (skinning) with a bundle Top 2/3 Issues before graduation: * Improve our website with tutorials and getting started content. * Prepare some easy-to-run demos to get people interested in Clerezza. * Prepare for a first release = Deltacloud = Deltacloud is a cross-cloud RESTful abstraction API. The are currently no issues requiring board attention. Recent activity: * Grant of initial
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
The relevance of this name might seem clear to project members, but not to me. From my background I would assume this is an implementation of the j2ca connector framework at apache, kind of like (the active part of) codehaus tranql. If I'd been working on tomcat or jetty recently I'd assume it was some kind of generalization of the transport connectors for a web container. Since this now or formerly relates to lucene I kinda doubt either one of these assumptions would be particularly accurate. thanks david jencks On Aug 16, 2010, at 6:59 AM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Hi, The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? Karl - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retired/dormant projects
On Jun 11, 2010, at 11:28 AM, sebb wrote: The following podlings appear to be retired or dormant: juice - status says dormant kabuki - status says withdrawn wadi - status page has not been updated since creation as far as I can The wadi proposal was withdrawn by its creator before anything significant happened here, it has continued at codehaus. Read-only or removal would be appropriate. david jencks tell; no updates to SVN since end of 2005 Should their SVN directories be made read-only? - 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: [VOTE][PROPOSAL] Amber incubator
+1 (not yet binding?) thanks david jencks On May 4, 2010, at 3:48 PM, Simone Gianni wrote: I would like to present for a vote the following proposal to be sponsored by the Shindig PMC for a new Amber podling. The goal is to build a community around delivering a OAuth v1.0, v1.0a and upcoming v2.0 API and implementation The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/AmberProposal [] +1 to accept Amber into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Simone Gianni --- Proposal text from the wiki --- = Amber = == Abstract == The following proposal is about Apache Amber, a Java development framework mainly aimed to build OAuth-aware applications. After a brief explanation of the OAuth protocol, the following proposal describes how Apache Amber solves issues related to the implementation of applications that adhere to such specification. == Proposal == Amber will have no or negligible dependencies and will provide both an API specification for, and an unconditionally compliant implementation of, the OAuth v1.0, v1.0a and v2.0 specifications. The API specification will be provided as a separate JAR file allowing re-use by other developers and permits configuration: * by XML * by the Java JAR Services ServiceLoader mechanism * programmatically The API component specifies that an implementation must provide default classes for Provider, Consumer and Token objects making Amber easy to integrate with existing infrastructure and OAuth client interactions possible with virtually no additional configuration. The API is flexible enough to allow programmatic customisation or replacement of much of the implementation, including the default HTTP transport. Amber will provide both client and server functionality, enabling developers to deploy robust OAuth services with minimal effort. == Background == Roughly, OAuth is a mechanism that allows users to share their private resources, like photo, videos or contacts, stored on a site with another site avoiding giving their username and password credentials. Hence, from the user point-of-view, OAuth could be the way to improve their experience across different applications with an enhanced privacy and security control in a simple and standard method from desktop and web applications. The protocol was initially developed by the oauth.net community and now is under IETF standardization process. The main idea behind OAuth is represented by the token concept. Each token grants access to a site, for a specific resource (or a group of resources), and for a precise time-interval. The user is only required to authenticate with the Provider of their original account, after which that entity provides a re-usable to token to the Consumer who can use it to access resources at the Provider, on the users behalf. Moreover, the total transparency to the user, that is completely unaware of using the protocol, represents one of the main valuable characteristics of the specification. Apache Amber community aims not just to create a simple low-level library, but rather to provide a complete OAuth framework easy to use with Java code, on top of which users can build new-generation killer applications. There are currently three implementation efforts going on in ASF for OAuth v1. A stable implementation of OAuth v1 is present in Apache Shindig, but it is not actively developed and not shared with other projects. A Lab having Simone Tripodi as its PI is working on an implementation for an OAuth library that could be used by other products. Zhihong Zhang wrote an OAuth plugin for JMeter. At the same time, on the IETF OAuth v2 mailing list, other people expressed interest for a Java API and implementation, among them two Apache committers and one active contributor. Outside the ASF there are three known Java OAuth 1.0/1.0a libraries * The oauth.net reference implementation by John Kristian, Praveen Alavilli and Dirk Balfanz. * OAuth SignPost - a simple OAuth message signing client for Java and Apache HttpComponents by Matthias Kaeppler. * OAuth Scribe - a simple OAuth client by Pablo Fernandez. * asmx-oauth (on google code) - a complete open source OAuth 1.0 Consumer and Service Provider implementation provided by Asemantics Srl (Simone Tripodi was involved). == Rationale == The key role played by the OAuth specification, within the overall Open Stack technologies, jointly with its high degree of adoption and maturity, strongly suggest having an Apache leaded incubator for suitable reference implementation. Furthermore, the OAuth specification is currently gaining value due to its involvement in a standardization process within the IETF, as the actual internet draft. Having the Apache Amber as an Apache Incubator could be an opportunity to enforce the actual Apache projects that already reference other
Re: Shindig PMC sponsorship for Amber OAuth java library
Also if Amber needs more mentors I can apply to join the incubator pmc and be an additional mentor. thanks david jencks On Apr 29, 2010, at 3:43 PM, David Jencks wrote: I'm interested in implementing jaspic (jsr 196) support if practical. This should allow Amber to provide container managed authentication in any jaspic enabled servlet container. I'm not familiar enough with OAuth to know if it makes sense to have a client auth module but surely a server auth module makes sense. I've added myself to the initial committers list hopefully this is the appropriate way to express my interest :-) thanks david jencks On Apr 29, 2010, at 12:33 PM, Paul Lindner wrote: Hi Pablo, If you are considering merging Scribe with Amber I would add yourself to the initial committers list, and fax in an ICLA to get things rolling: http://www.apache.org/licenses/icla.txt http://www.apache.org/licenses/icla.pdf On Thu, Apr 29, 2010 at 11:07 AM, pablo fernandez fernandezpabl...@gmail.com wrote: Simone, Yeah, the library now supports OAuth v1.0a. I intend to add 2.0 support eventually... I added myself under other interested people. I've never participated in any apache project so I think that's the right place. Thanks On Thu, Apr 29, 2010 at 1:59 PM, Simone Gianni simo...@apache.org wrote: Hi Pablo, great, thanks for your interest. I suppose you are talking about OAuth v1? Please have a look at the current proposal on http://wiki.apache.org/incubator/AmberProposal and eventually add yourself where appropriate. Simone 2010/4/29 pablo fernandez fernandezpabl...@gmail.com Hello Everyone! I've developed a OAuth library for java that it's working pretty well, although it's still work in progress. I'd be glad to collaborate the code to Amber, modifying it to the project needs. If you want to take a look at it, please go to: github.com/fernandezpablo85/scribe http://github.com/fernandezpablo85/scribeRegards! On Thu, Apr 29, 2010 at 6:45 AM, Paul Lindner lind...@inuus.com wrote: The Shindig PMC has approved the proposal to sponsor the Amber project for the Apache Incubator. 7 +1 votes were submitted. [Henning, Chirag, Chico, Paul, Jacky, Santiago and Vincent] No 0 or -1 votes. Thanks Paul On Tue, Apr 27, 2010 at 5:54 AM, Paul Lindner plind...@linkedin.com wrote: Hi, I propose that the Shindig PMC sponsor the Amber project - which is an OAuth 1.0/2.0 library under development in Apache Labs. http://wiki.apache.org/incubator/AmberProposal Our sponsorship would allow Amber to graduate to the Apache incubator. After some time it could graduate to a subproject of Shindig or as a top level project of it's own. Vote open for 72h +1 Sponsor Amber +0 no opinion -1 Don't sponsor Amber - 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: Shindig PMC sponsorship for Amber OAuth java library
I'm interested in implementing jaspic (jsr 196) support if practical. This should allow Amber to provide container managed authentication in any jaspic enabled servlet container. I'm not familiar enough with OAuth to know if it makes sense to have a client auth module but surely a server auth module makes sense. I've added myself to the initial committers list hopefully this is the appropriate way to express my interest :-) thanks david jencks On Apr 29, 2010, at 12:33 PM, Paul Lindner wrote: Hi Pablo, If you are considering merging Scribe with Amber I would add yourself to the initial committers list, and fax in an ICLA to get things rolling: http://www.apache.org/licenses/icla.txt http://www.apache.org/licenses/icla.pdf On Thu, Apr 29, 2010 at 11:07 AM, pablo fernandez fernandezpabl...@gmail.com wrote: Simone, Yeah, the library now supports OAuth v1.0a. I intend to add 2.0 support eventually... I added myself under other interested people. I've never participated in any apache project so I think that's the right place. Thanks On Thu, Apr 29, 2010 at 1:59 PM, Simone Gianni simo...@apache.org wrote: Hi Pablo, great, thanks for your interest. I suppose you are talking about OAuth v1? Please have a look at the current proposal on http://wiki.apache.org/incubator/AmberProposal and eventually add yourself where appropriate. Simone 2010/4/29 pablo fernandez fernandezpabl...@gmail.com Hello Everyone! I've developed a OAuth library for java that it's working pretty well, although it's still work in progress. I'd be glad to collaborate the code to Amber, modifying it to the project needs. If you want to take a look at it, please go to: github.com/fernandezpablo85/scribe http://github.com/fernandezpablo85/scribeRegards! On Thu, Apr 29, 2010 at 6:45 AM, Paul Lindner lind...@inuus.com wrote: The Shindig PMC has approved the proposal to sponsor the Amber project for the Apache Incubator. 7 +1 votes were submitted. [Henning, Chirag, Chico, Paul, Jacky, Santiago and Vincent] No 0 or -1 votes. Thanks Paul On Tue, Apr 27, 2010 at 5:54 AM, Paul Lindner plind...@linkedin.com wrote: Hi, I propose that the Shindig PMC sponsor the Amber project - which is an OAuth 1.0/2.0 library under development in Apache Labs. http://wiki.apache.org/incubator/AmberProposal Our sponsorship would allow Amber to graduate to the Apache incubator. After some time it could graduate to a subproject of Shindig or as a top level project of it's own. Vote open for 72h +1 Sponsor Amber +0 no opinion -1 Don't sponsor Amber - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Branding of Incubator projects
On Jun 26, 2006, at 12:42 PM, sophitia que wrote: I would also propose: The PRC is willing to issue formal press releases for all podlings who successfully graduate from the Incubator and are interested in issuing a press release. See below... 5. Until the Incubator PMC approves a podling proposal *and* the podling initial drop code is in our source code repositories, a project or any affiliated persons SHOULD NOT issue any 'press releases' or affirmatively seek positive publicity (such as 'seeding news stories') . I would amend, as I see three stages: Podling is in proposal/or pre-code-drop process: No press whatsoever. Not allowed to call a project by Apache Foo name until project is officially in incubation and code has been submitted into repositories. Podling has been approved for incubation/podling has launched dev mailing lists / podling has dropped code into repository: Project and affiliated persons can issue press releases that reference the podling, but cannot issue press releases with the specific intent of announcing the Podling. Podling can conduct informal pr activities, such as media outreach, blog publicity, etc. I'm left very unclear about what is allowed in a press release and what isn't. Examples might be helpful. Based on my confusion, I also don't understand why a press release saying that project X is starting incubation with community members x1, x2, x3, etc would be undesirable as long is it makes the incubation status clear. thanks david jencks Podling has been approved to graduate from the incubator: Formal press release, issued by the ASF. Or jointly by the ASF and any affiliated organizations/groups. Susan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubation Process and PPMCs
I'm not sure what is going on with that, I have commtted work to AMQ although it has been quite a while. Why are you looking only at the branches? And in particular why not include amq 4? thanks david jencks On Mar 14, 2006, at 10:39 AM, Davanum Srinivas wrote: Hmmm... svn log svn://svn.activemq.org/activemq/scm/branches/activemq-3/ activemq | grep | | cut -f 2 -d | | sort | uniq gives me just 15: aco ammulder brianm chirino djcook foconer gnt jgapuz jlim jstrachan maguro pbrooke pvillacorta rajdavies rsaba -- dims On 3/14/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: IIUC, they all contributed code to the AMQ project. Regards, Alan Davanum Srinivas wrote: What i'd be interested to know is how many of the 17 Non-Apache Committers noted on the proposal[1] got Apache id's and of them how many of them actually made any commits to the Apache SVN repo. [1] http://wiki.apache.org/incubator/ActiveMqProposal On 3/14/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: I think I'm seeing too much incipient dogmatism here. A little while ago I remember reading about how it was possible for code to zip through the incubator on its way to become part of an existing project, resting only long enough for the legal/provenance questions to be resolved. I think this is still a good path to keep open, and don't see the use of a PPMC for it. Except ActiveMQ isn't just code, it's code+people. If all the people are already associated with the ASF when the podling enters incubation.. well, then why isn't it being handled as a grant of code? The need for a podling implies the presence of people new to the ASF. For instance, my understanding is that ActiveMQ is coming to be part of geronimo. Most likely, yes -- but it's not a certainty. (Just close to it.) The eventual disposition is made at graduation. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBbFR5rNPMCpn3XdAQKqOAQAtm4gWzEgdP9FZKknZWVbszAbIBafgvvn 4wfPatOdUpy577axawHnFDq3i6OG3poPqYn7OecqZkCXSimSIf3Hp7CsijzHnL/x rsluUCyPkW11/zs/lvlkXhpIWjNmpTV0T4EkiadZfIPK704qUE3CHpkKT0uYS7lk xsA1obdLoes= =3klG -END PGP SIGNATURE- --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubation Process and PPMCs
On Mar 13, 2006, at 5:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel J. Bergman wrote: -- We should require 3+ Mentors for each project -- Upon acceptance, we should establish the initial PPMC as consisting of the Mentors. I'd like to add that I think a PPMC is a requirement, not a 'nice-to-have.' We have some podlings either with no PPMCs or with PPMCs instantiated quite late. I think I'm seeing too much incipient dogmatism here. A little while ago I remember reading about how it was possible for code to zip through the incubator on its way to become part of an existing project, resting only long enough for the legal/provenance questions to be resolved. I think this is still a good path to keep open, and don't see the use of a PPMC for it. I also think that there are all sorts of paths between that and the path of incubating an entirely new project intended to become a TLP. For instance, my understanding is that ActiveMQ is coming to be part of geronimo. It comes with a lot of new committers, as well as a lot of people who are already geronimo committers. To me the main point of incubation is to basically get everyone used to working more closely together, and when we have verified that this is happening, we can bring all the activemq people on board into geronimo. I don't see how a PPMC is going to help this process: it looks to me as if it will get in the way. thanks david jencks - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBYalJrNPMCpn3XdAQJx+gQA1q4OX/iZgaySnao5515ne7/ePZgrLKGo LdNa5y4drw+aADiM3Q7GIaoyn7wvdhomcoUIKs65E0UPgyIIoq8/0AoPJcm+c930 DD3Li/eBxL+tTY/0zEcLtNOo1j0qEn7Ii6bID2PCYgtMkBlN57Jr9HlgcSlrMgC1 kIWweLAf0XU= =Xp/5 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL contribution from Sybase
After being nervous for quite a while I have come to think that the sybase bpel engine should go in as part of servicemix and if further uses outside servicemix develop we can see about splitting it off. more comments inline. On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote: Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), JBI should be available separately. To me this appears to assume that the interface between the orchestration engine and the JBI container is well defined and all parties agree on it. I haven't heard any claims that this is the case, although I'm still completely unfamiliar with the subject. Also, we already have two engines in the Incubator, with two more pending, so we may have three implementations of BPEL. I would expect to see at least one of them close down, and would like to see the orchestration communities merge, if possible. This appears to me to be a strong indication that BPEL engines cannot live an independent life and that we should try one as part of another project such as servicemix. If the BPEL part of the servicemix community turns out to be big vibrant and wanting its own project, all the better. If not, servicemix gets a component it needs. I've heard nothing to provide a reason for not bringing in the contribution as a standalone podling, which ServiceMix and others can consume. This would be in accord with Ken and Mads. Through all this I don't think I've seen anyone actually say they want to work on the code other than servicemix people. (If I've missed anyone I apologize). It's been on the table a rather long time for that not to mean that there isn't much interest outside servicemix for actually working on it. The incubation process is not a trivial amount of work and having 2 podlings rather than one pretty nearly doubles a good deal of it IMO. Since the original request was to be a part of servicemix, and AFAICT no one outside that group has said they want to work on the project over the last x weeks of stewing, what exactly can we gain by forcing a decision on this group of people who want to work together? On a related note, I believe that we need to evaluate projects for graduation based in part on how well the community collaborates with other ASF projects, and become part of the ASF community. I don't consider ghettos to be healthy for the ASF, no matter how internally successful. After looking at this for a while I don't have any idea what you mean. Could you provide some concrete examples of projects that should not have graduated based on this criterion and pre-incubator projects that would not graduate had they gone through incubation? While this appears at first to be a very nice idea I can't see any way it could mean anything but stifling innovation. I hope you can clarify what you mean. thanks david jencks --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL contribution from Sybase
I'd like to retract this email. I have doubts on both sides of this and may try to explain them in a clearer way in another message. My apologies david jencks On Feb 13, 2006, at 6:26 PM, David Jencks wrote: After being nervous for quite a while I have come to think that the sybase bpel engine should go in as part of servicemix and if further uses outside servicemix develop we can see about splitting it off. more comments inline. On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote: Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), JBI should be available separately. To me this appears to assume that the interface between the orchestration engine and the JBI container is well defined and all parties agree on it. I haven't heard any claims that this is the case, although I'm still completely unfamiliar with the subject. Also, we already have two engines in the Incubator, with two more pending, so we may have three implementations of BPEL. I would expect to see at least one of them close down, and would like to see the orchestration communities merge, if possible. This appears to me to be a strong indication that BPEL engines cannot live an independent life and that we should try one as part of another project such as servicemix. If the BPEL part of the servicemix community turns out to be big vibrant and wanting its own project, all the better. If not, servicemix gets a component it needs. I've heard nothing to provide a reason for not bringing in the contribution as a standalone podling, which ServiceMix and others can consume. This would be in accord with Ken and Mads. Through all this I don't think I've seen anyone actually say they want to work on the code other than servicemix people. (If I've missed anyone I apologize). It's been on the table a rather long time for that not to mean that there isn't much interest outside servicemix for actually working on it. The incubation process is not a trivial amount of work and having 2 podlings rather than one pretty nearly doubles a good deal of it IMO. Since the original request was to be a part of servicemix, and AFAICT no one outside that group has said they want to work on the project over the last x weeks of stewing, what exactly can we gain by forcing a decision on this group of people who want to work together? On a related note, I believe that we need to evaluate projects for graduation based in part on how well the community collaborates with other ASF projects, and become part of the ASF community. I don't consider ghettos to be healthy for the ASF, no matter how internally successful. After looking at this for a while I don't have any idea what you mean. Could you provide some concrete examples of projects that should not have graduated based on this criterion and pre-incubator projects that would not graduate had they gone through incubation? While this appears at first to be a very nice idea I can't see any way it could mean anything but stifling innovation. I hope you can clarify what you mean. thanks david jencks --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
I'm not really familiar with eclipse. Could you please explain what advantages your proposal has over building your project with maven? From your description I would guess that using maven as your build system provides all the features you want with more automation. many thanks, david jencks On May 2, 2005, at 1:00 PM, Jeffrey Liu wrote: Hi, I want to propose a centralized Eclipse update manager site for Apache projects/software. This may not be the correct place to ask this, but I can find a better place to do it, so I decided to start here. If this is not the right place, can somebody point me to the correct location? Thanks! Reason I propose an Eclipse update manager site for Apache projects/software is because Eclipse projects such as the Web Tools Platform (WTP) project often reuses software that are provided by Apache, for example, Axis, Tomcat, Derby, etc... Often times, these Apache software are not redistributed by the Eclipse projects, but instead, they are listed as prerequisites. This means, end users must first download the Eclipse project and all the Apache software prereq by the project, and configure these software in the Eclipse project before they can get started. This is error prone and hampers the out-of-the-box experience. Imagine the following scenario: A user downloads WTP. Unzip it and starts it up. S/he wants to create an Axis Web service. S/he launches the wizard that creates a Web service, but finds out s/he needs Tomcat and Axis. So s/he opens up her Web browser, goes to the Apache Web site and looks for the download page for Tomcat and Axis. S/he downloads and unzips Tomcat and Axis to the file system. Goes back to WTP and manually configures Tomcat and Axis into her workspace. S/he launches the wizard again and move on. This is easier than said. If there's an Eclipse update manager site for Apache software, then when the user finds out s/he needs Tomcat and Axis, all s/he needs to do now is launch the Eclipse update manager (URL to the Apache update site will be preloaded), select Tomcat and Axis and click Finish. The Eclipse update manager will download, install and configure Tomcat and Axis automatically. This is much better than asking the user to download and configure things manually. Also, this Eclipse update manager site is very useful when new versions of a Apache software is available. For example: Say Eclipse WTP 1.0 ships with Axis 1.2 support. If later on, Axis releases a critical fix for Axis 1.2's WSDL2Java emitter, then without an update site, we'll need to do one of the following... 1. Rebuild WTP 1.0 with the Axis fix 2. Ask users to manually update WTP 3. Wait for the next version of WTP. None of the above sound attractive. If there's an Eclipse update manager site setup for Apache, then end users can search and install new updates automatically by making just a few clicks. I believe this advances the integration between open source software that are provided in different domains (Apache, Eclipse, etc). I think this can benefit the open source community and can grow the open source ecosystem. Do I need to propose a new Apache project for something like this? Suggestions/comments are welcomed. Thanks, Jeffrey Liu IBM Rational Software - Performance Analyst IBM Toronto Lab. 8200 Warden Ave. Markham, Ontario, L6G 1C7 Internal mail: D3/R8V/8200/MKM (D3-268) T/L: 969 3531 Tel: (905) 413 3531 Fax: (905) 413 4920 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Geronimo from Incubator and recommend as top-level project
[ ] +1 - The Geronimo project has met the requirements for incubation and will be recommended to the board for TLP status +1 Many thanks for all the assistance from the Apache veterans. David Jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving JAM to org.apache.jam
On Friday, March 26, 2004, at 11:46 AM, Patrick Calahan wrote: At 01:41 AM 3/26/2004 -0500, Noel J. Bergman wrote: Patrick, Hi Noel. Thanks for the response. I'm replying to you on [EMAIL PROTECTED] The projects@ list is a catchall for projects that don't have their own list, but the place where you want to discuss a proposal is [EMAIL PROTECTED] Ok, thanks for the clarification. You basic service provider approach of using an implementation-agnostic user side, and implementations for various meta-data implementations looks like a good way to address the problem. Have you approached any of the projects, such as Geronimo? If it were Not yet, but that seems like a good idea - will do. I think adding JAM to Geronimo might create problems since geronimo uses xmlbeans rather heavily in its build process. I don't see an obvious way to sidestep the circular dependency. accepted into the Incubator, where would you expect the code to go I'm not certain, but in some ways JAM like a very good fit with Jakarta. I'm hoping you all can help me figure out the most appropriate trajectory for it, though. eventually? And how big would you say your contributor community is today? As I say, JAM has been spun out of my contributions to Xml-beans, and it really doesn't yet have it's own contributor community. Since it is in the Xml-beans repository, in a sense all current Xml-beans committers are part of its contributor community. I took a quick peek at your website on jam, and it looks very very interesting. I wonder if the xdoclet2 folks are aware of it... I would think that the best place for it now would be with the xmlbeans project, but: -moved to org.apache.jam package -compiled into a separate jar, then used by xmlbeans. Maven makes this kind of multiproject projects rather easy to set up, but mavenizing the rest of the xmlbeans build could be a challenge. Not that I am any kind of expert, but I would wait to try to make a separate project until it has more explicit contributors. thanks david jencks Thanks again, -Patrick --- Noel -Original Message- From: Patrick Calahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 15:27 To: [EMAIL PROTECTED] Subject: Fwd: moving JAM to org.apache.jam Hello. I'm a committer on the xml-beans project. As part of my work there, I've written an API called 'JAM' (Java API for Metadata) that is becoming a useful technology in its own right. JAM is distinct from xml-beans - it is used by xbean's java-to-schema compilers, but JAM does not use xbeans at all. I built JAM to solve a particular set of problems that I have relating to metadata and JSR175, and I believe that many other java developers are going to need a solution to those same problems very soon. I already have some consumers of the API who don't care about xbeans - they only want the services that JAM provides. Accordingly, I am trying to give it some more visibility. One thing I would like to do is give it a better package name; it currently is org.apache.xmlbean.impl.jam Ideally, I would like it to be org.apache.jam but I'm not sure what Apache's policies are on using top-level package names - I figured I'd better talk to someone about it first. I bounced the idea off of the xmlbeans-dev list last week, and everyone there seems ok with it (email appended). Ultimately, I really think JAM should be a separate project. I'd love for it to be an Apache project if possible, though I'm not sure what I should do to start that process. If you want to read more about JAM, I've temporarily posted the docs and some white papers here: http://www.pcal.net/jam Thanks, -p Date: Thu, 18 Mar 2004 11:22:08 -0800 To: [EMAIL PROTECTED] From: Patrick Calahan [EMAIL PROTECTED] Subject: moving JAM to org.apache.jam X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-PMX-Version: 4.1.1.86173 X-OriginalArrivalTime: 18 Mar 2004 19:22:16.0831 (UTC) FILETIME=[5324B0F0:01C40D1E] Hey all. I am exploring the possibility of moving JAM into it's own package space, e.g. 'org.apache.jam.' I'd like to bring it up out of the bowels of the xbeans impl because it is proving to be a useful technology to other projects. For example, Cedric Beust already has two open source projects which he has converted to JAM, including the widely-used EJBgen: http://www.beust.com/ejbgen http://www.beust.com/sgen It's a little awkward to ask people to keep importing 'org.apache.xmlbean.impl.jam' for something that (from their perspective) doesn't have anything to do with xbeans. I'm assuming that the powers-that-be at Apache can't have people just claiming package names at will, so I am going to bring this up with the incubator group (or whomever is appropriate). Before I do, though, I just wanted to ping everyone here to make sure they think this seems ok. Thanks, -p - To unsubscribe, e
Re: [HEADSUP] New Incubator site in CVS
This is pretty nice looking and better than what I could do in a finite
amount of time:-)
A couple of comments, I apologize that they are somewhat negative.
-- The material in the left sidebar seems to me to change randomly
depending on which page I'm on. The result is that I think the site is
a disorganized maze. I don't know how these sidebars are generated,
but if they were all the same or all the same for a given tab it would
be much less confusing for me.
--Perhaps this is covered in your request for a better boilerplate
status template, but I can't discern how the alleged STATUS file is
intended to relate to the STATUS web page linked to from the
list-of-projects page. My impression from loosely following this list
is that the STATUS file for a podling is supposed to be plain text and
confine itself to noting which of the steps shown in the STATUS web
page have been passed, which have problems, and which have not yet been
attempted. Again, my impression is that any information on the actual
development state of the project (such as most of the geronimo status
email) is supposed to be elsewhere, such as on the projects' web site.
If indeed the official cvs STATUS page is supposed to be plain text,
all the html seems redundant and confusing. If the idea is to render
an xml status document into html, putting a few answers into the html
would make the intent much clearer.
Many thanks for working to make the incubation process clearer and more
visible.
david jencks
On Thursday, October 16, 2003, at 11:17 AM, Nicola Ken Barozzi wrote:
I have finished porting all the old site to the new layout.
The site source is under the incubator CVS, and the layout has been
changed to make it shallower and all docs are under the site.
The built site is under incubator-site/build/site, as before.
I have not yet published the site, and a built site of what is now in
incubator CVS can be seen here [1].
NOTE: Current incubator site has to be rendered with the latest
Forrest from CVS, which BTW renders the docs in-place (no more copying
sources in the build dir). Till the ForrestBot is not setup, I will
take care of updating the site when needed.
All the main resources for each project are now under:
site/projects/index.cwiki
Each project has only *one* file for incubation status tracking:
site/projects/$projectname.{xml|cwiki|txt|ihtml}
TODO (please help):
1 - make a really workable project status boilerplate doc
2 - update site/projects/index.cwiki to reflect real resources
3 - start voting the RFCs
[1]
http://www.apache.org/~nicolaken/whiteboard/incubator-draft-new-site/
index.html
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
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]
