Re: package names (pekko related)
Based on how Groovy joined Apache, it seems as though you can keep the same package name and work on renaming it in a major version if there's already binary compatibility concerns. On Tue, Oct 11, 2022 at 7:14 AM PJ Fanning wrote: > > Hi everyone, > > I'm creating a new thread to avoid filling the Pekko thread with emails that > are only partially related to the proposal. > > The current Akka code uses packages that start with 'akka.' and a lot of the > people involved with Pekko seem to prefer to keep the use 'pekko.' instead of > 'org.apache.pekko.' when we rename the Akka packages. > > Kafka and Netbeans are examples of Apache projects that don't use > 'org.apache' prefix in their package names. > > Is 'pekko.' a viable option or is there a strong preference within the ASF > and the Incubator PMC for 'org.apache.pekko.'? > > Regards, > PJ > > - > 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: Multiple entities of software grant agreement
And we've filed the SGA. The ICLAs are still churning as each submitter learns what data is required on the form, though. ;) On Mon, Apr 25, 2022 at 7:49 AM hulk wrote: > > Many thanks for John's help. I think we can handle it with this input, > thanks a lot. > > On Mon, Apr 25, 2022 at 8:06 PM John D. Ament wrote: > > > On Mon, Apr 25, 2022 at 5:08 AM Sheng Wu > > wrote: > > > > > SGA is not required if the project is on a personal repository, this > > > > > > > > > SGAs can apply for individuals and corporations [1]. Doesn't matter > > where it's sourced from. We have received a number of SGAs in the past > > that just represent a single individual, or non incorporated entities that > > choose to be represented by a single person (see Groovy as an example). > > > > > > > individual's employer(if have) is recommended to submit CCLA(but needs > > > to evaluate by the owner about his contract) > > > > > > > The CCLA is really for the case where the employer explicitly wants an > > agreement in place indicating the contributor can contribute the code. I'm > > not aware of any policy we have (at Apache) requiring it. [2] > > > > More comments below specific to kvrocks. > > > > > > > But this isn't the Kvrocks case. > > > > > > Sheng Wu 吴晟 > > > Twitter, wusheng1108 > > > > > > > > > > > > > > > > > > > tison 于2022年4月25日周一 16:15写道： > > > > > > > > Thanks for your inputs. > > > > > > > > Try to summarize the discussion: > > > > > > > > * Apache requires a SGA from the *current* copyright holder of the > > > software > > > > to grant permission for ASF. > > > > > > > We don't actually (at least not always but it does tend to be the easiest > > way to deal with it since most incubating projects are changing license). > > Work with your mentors/champion to figure this out, but if a large enough > > set of ICLAs is done to cover all main contributions and the source code is > > already Apache licensed then you may be fine. > > > > > > > > * If the current copyright holder is Meitu, then they should sign a > > grant > > > > with Exhibit A barely "Kvrocks". > > > > > > > > However, if the current copyright holder is "Kvrocks contributors", > > since > > > > it's a virtual entity, a certain contributor on behalf of the community > > > > should sign the SGA. > > > > > > > > Did I get it right? Is there some other proposal that got into the > > > > incubator without a SGA from a certain "company". > > > > > > > To answer this, you need to understand what the SGA is saying; IANAL. > > Section 2 makes the assumption that the grantor has permissions to be the > > grantor. When Meitu granted the source code, they gave whoever full rights > > to do whatever the grant said they can do. It wouldn't be correct to ask > > Meitu to file another grant, but whoever is filing the grant should ensure > > that what they are doing (Section 1 of the SGA) is in compliance with that > > grant, which would satisfy Section 2. I'm assuming that KvrocksLabs isn't > > a business entity, just an unincorporated group of individuals working on > > the project. It's fairly common that opensource projects merge code > > together, I'm not sure the state of KvrocksLabs before the grant that Meitu > > gave. > > > > TL;DR I believe someone representing KvrocksLabs can sign a SGA with the > > assumption that the original grant from Meitu created KvrocksLabs. Ideally > > that person should be whoever received the grant from Meitu. > > > > > > [1]: https://www.apache.org/licenses/contributor-agreements.html#grants > > [2]: https://www.apache.org/licenses/contributor-agreements.html#clas > > > > > > > > > > > > > > Best, > > > > tison. > > > > > > > > > > > > Sheng Wu 于2022年4月25日周一 15:42写道： > > > > > > > > > > but I think it's right that meitu should claim clearly about the > > > > > copyright > > > > > date since the > > > > > > > > > > Do you mean there is no single Meitu employee(s) was > > > > > working/contributed to that project ever since? > > > > > Because the org is virtual on GitHub, and meitu can't sign CCLA or > > SGA > > > > > to that virtual group back then, I think one way or another, Meitu > > > > > still need to prove the SGA from the transfer date to now. > > > > > It is better for meitu to sign the SGA to declare all > > > > > contributions(from beginning to now), others(individuals) would > > submit > > > > > their ICLA(or other companies' SGA) for some codes after the > > transfer. > > > > > > > > > > Sheng Wu 吴晟 > > > > > Twitter, wusheng1108 > > > > > > > > > > hulk 于2022年4月25日周一 15:06写道： > > > > > > > > > > > > Thanks for junping reply. > > > > > > > > > > > > Yes, we also agree that should grant the whole source code > > > repository > > > > > for > > > > > > ASF, > > > > > > but I think it's right that meitu should claim clearly about the > > > > > copyright > > > > > > date since the > > > > > > the repository was moved to another organization after then. > > > > > > > > > > > > So our question is should we need
Re: [VOTE] Release Apache Teaclave (incubating) v0.4.0-rc.1
+1 Note that the NOTICE file has a slightly outdated copyright year now and should be updated. — Matt Sicker > On Mar 26, 2022, at 17:08, Mingshen Sun wrote: > > Hi all, > > I am pleased to be calling this vote for the third release of > Apache Teaclave (incubating) 0.4.0 (release candidate 1). > > The Apache Teaclave (incubating) community has voted and approved the > release, with six +1 votes from IPMC members (Hongbo Chen, Yulong > Zhang, Ran Duan, Yu Ding, Tongxin Li, Rundong Zhou). > > Vote/result threads: > - https://lists.apache.org/thread/z3q5fhobll794x7d3o7pwzgt2bl2dlhk > - https://lists.apache.org/thread/j8lr7168yp5cfynlfz7zpk9om574d0g9 > > The release candidate to be voted over is available at: > - https://dist.apache.org/repos/dist/dev/incubator/teaclave/0.4.0-rc.1/ > > The release candidate is signed with a GPG key available at: > - https://dist.apache.org/repos/dist/dev/incubator/teaclave/KEYS > > The Git commit for this release is: > - > https://gitbox.apache.org/repos/asf?p=incubator-teaclave.git;a=commit;h=37b248b2b8a5215fed668b4e71b674ce57b0b352 > > The release note is available in: > - https://github.com/apache/incubator-teaclave/releases/tag/v0.4.0-rc.1 > > Build guide and get started instructions can be found at: > - > https://github.com/apache/incubator-teaclave/blob/v0.4.0-rc.1/docs/my-first-function.md > > The short version of building Teaclave from the source tarball: > > ``` > $ wget > https://dist.apache.org/repos/dist/dev/incubator/teaclave/0.4.0-rc.1/apache-teaclave-0.4.0-rc.1-incubating.tar.gz > $ tar zxvf apache-teaclave-0.4.0-rc.1-incubating.tar.gz && cd \ > apache-teaclave-0.4.0-rc.1-incubating > $ # Instructions to verify the source tar: > https://teaclave.apache.org/download/#verify-the-integrity-of-the-files > > $ docker run --rm -v $(pwd):/teaclave -w /teaclave \ > -it teaclave/teaclave-build-ubuntu-1804-sgx-2.14:latest \ > bash -c ". /root/.cargo/env && \ > . /opt/sgxsdk/environment && \ > mkdir -p build && cd build && \ > cmake -DTEST_MODE=ON -DSGX_SIM_MODE=ON -DGIT_SUBMODULE=OFF .. && \ > make" > ``` > > The vote will be open for at least 72 hours. Everyone is welcome to > vote. Please vote by replying to this thread explicitly. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > Best, > > Mingshen Sun > Apache Teaclave (incubating) PPMC > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
Re: [VOTE] Retire BlueMarlin
+1 On Tue, Feb 15, 2022 at 5:54 PM Furkan KAMACI wrote: > > Hi, > > +1 > > Kind Regards, > Furkan KAMACI > > On Wed, Feb 16, 2022 at 2:50 AM Sheng Wu wrote: > > > +1 > > > > Chris Lambertus 于2022年2月16日 周三上午7:35写道： > > > > > +1 > > > > > > > > > > On Feb 15, 2022, at 3:20 PM, Dave Fisher wrote: > > > > > > > > Please vote to retire BlueMarlin. This is a group that has made no > > > progress as an Apache podling. There is no interest in developing a > > > community. They’ve had multiple chances. > > > > > > > > [ ] +1 Retire BlueMarlin > > > > [ ] -1 Keep BlueMarlin and I’m willing to join to make it an Apache > > > Community. > > > > - > > > > 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 > > > > > > -- > > Sheng Wu 吴晟 > > > > Apache SkyWalking > > Apache Incubator > > Apache ShardingSphere, ECharts, DolphinScheduler podlings > > Zipkin > > Twitter, wusheng1108 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Looking for a champion: resurrect log4j 1.x
ve made the points I have >> just >>> written here abundantly clear for years. >> >> So far, we had one contributor show up with a complete hostile attitude >> who refused to engage with the PMC and explain what he wanted to do besides >> go wild with version 1. Later, Ceki came back and made his first commit in >> probably a decade attempting to do the same less than a day after we had >> completed voting on what to do with version 1, again, without ANY comments >> about what his intentions were or any engagement with the PMC. So far, >> these two people have spent most of their time trolling in other mailing >> lists on Apache or elsewhere about the situation while continuing to ignore >> the PMC’s arguments. >> >> If you have a desire to update version 1 that doesn’t boil down to “log4j2 >> bad bcuz log4shell lol get rekt n00bz”, please explain. >> >>> >>> On Sat, Jan 8, 2022 at 1:58 PM Matt Sicker wrote: >>> >>>> The problem with v1 is that it doesn’t “just work”. There are numerous >>>> dead locks and other concurrency problems that were unable to be fixed >>>> without breaking various points of compatibility which is why Logback >> and >>>> Log4j2 even exist rather than continuing v1. There would also be >> difficulty >>>> in making a new release without volunteers contributing to the existing >> PMC >>>> to eventually join the PMC to be able to more directly create releases. >>>> Apache isn’t going to allow a hostile fork at the Incubator, so it’d >> still >>>> need to work with us or create an external fork that can’t be confused >> with >>>> the Apache version (which would still require a bunch of source code >>>> changes to point to the new package name if not already using shading or >>>> similar repackaging). >>>> >>>> I think it’s been said before, but contributing to the v2 backward >>>> compatibility system is a great way to join the project in such a way >> as to >>>> eventually form new releases of v1 with a greater understanding of the >> full >>>> impact of changing anything about v1 after such a long time. A poorly >> made >>>> release still wouldn’t be a drop in upgrade for projects that haven’t >>>> bothered upgrading in several years, and one that starts to introduce >>>> incompatible API changes would further complicate backward >> compatibility in >>>> v2 as well as complicating external projects that rely on a stable >> legacy >>>> API to convert from (like Logback’s config file converter thing or the >>>> numerous custom plugins for v1). So far, we haven’t seen any reasonably >>>> serious proposals of how anyone expects to do this without causing >> further >>>> mayhem in the future. >>>> >>>> — >>>> Matt Sicker >>>> >>>>> On Jan 8, 2022, at 14:32, Rohit Yadav wrote: >>>>> >>>>> Hi Matt, >>>>> >>>>> Thanks for replying. I think the main issues I found following the >> guide >>>> [1] for Apache CloudStack (ACS) are: >>>>> >>>>> - APIs are not backward compatible fully, certainly everywhere the >>>> imports have to be fixed >>>>> - The config xml files are not fully compatible requiring some changes >>>>> - Our codebase is pretty large with several maven modules/projects >>>> enabled by certain flags, testing changes and ensuring CloudStack works >>>> post-migration adds effort and risks >>>>> - Lack of an automatic tooling that can do this reliably and >> efficiently >>>> (for example, the Go lang ecosystem has gofmt and other tooling to >> migrate >>>> codebase across std library/lang changes). >>>>> - ACS's own tech debt and dependency issues: for example, we're using >>>> log4j-extras (https://logging.apache.org/log4j/extras/) which is >>>> completely discontinued, and have code tied around gson library (for >> one or >>>> more reason, we've hesitated to upgrade both log4j and gson >> dependencies) >>>>> >>>>> Appreciate all the hard work the Log4j team is doing and we'll report >>>> issues as/when we hit them. As a consumer of the dependency, 1.x gave us >>>> enough mileage and end of the day we want logging to be boring that just >>>> works; and therefore I'm simply exploring all
Re: Looking for a champion: resurrect log4j 1.x
Answers below: > On Jan 8, 2022, at 17:34, Andrew Purtell wrote: > > Log4J 1 has known concurrency issues but many projects live with them or > work around them. For example, several "Big Data" Apache projects have been > fine with it, themselves internally highly concurrent and performance > sensitive. Log4J 1 might not be a Platonic ideal, but certainly good > enough, as evidenced by the popularity of those projects, operational in > numerous high scale and/or performance sensitive environments. It’s also a fairly common source of application performance problems that leads to reduction in logs being stored and the added difficulty of debugging problems with less context. Here are just some of the Bugzilla issues you’ve been conveniently ignoring for years: 50213 Category callAppenders synchronization causes java.lang.Thread.State: BLOCKED 46878 Deadlock in 1.2.15 caused by AsyncAppender and ThrowableInformation classes 41214 Deadlock with RollingFileAppender 44700 Log4J locks rolled log files (files can’t be deleted) 49481 Log4j stops writing to file, and then causes server to lockup 50323 Vulnerability in NTEventLogAppender 50463 AsyncAppender causing deadlock when dispatcher thread dies 50858 Classloader leak when using Log4j in a webapp container such as Tomcat, WebLogic 52141 [STUCK] ExecuteThread...Blocked trying to get lock: org/apache/log4j/Logger@0xc501e0a8[fat lock] 54009 Thread is getting Blocked 54325 Concurrency issues in AppenderAttachableImpl > In a perfect world Log4J 2 would have been API compatible and configuration > format compatible with 1, such that everyone could have migrated years ago, Can you point out any specific incompatibilities? Particularly in the current version. > but the Logging PMC/devs decided otherwise. Whether or not we assess that > as desirable, we arrive at the present, with hundreds, perhaps thousands, > of open source and internal projects stuck on Log4J 1 due to API or > operational compatibility concerns that would carry downstream to their > users. No matter what direction one might look (Log4J2, logback, etc.) > there are compatibility blockers. Staying with Log4J 1 can be very much > acceptable for this reason if the security concerns are addressed. Are you using the JMS appender? Are you using the socket receiver? If the answer is no to those questions, you don’t have security concerns besides the more glaring fact that you’re depending on end of life software that has been marked as such for going on 7 years now. > Sure, it > won't evolve much, and there will remain gotchas, but that is true with > anything... Some gotchas exceed others in concern. Compare lack of > asynchronous logging with the risks of a turing complete substitution > engine operating on untrusted user input. This is bullshit. JNDI is what leads to your Turing completeness. Not to mention that this substitution feature is meant for the configuration file, not for log messages, and the library has been updated as such regardless of downstream users possibly relying on the default behavior before it was apparent there was a security flaw. Based on how tepid you are about upgrading for even the slightest inconvenience, there’s a reason why version 2 maintains as much backward compatibility as possible by default to be least surprising. Plenty of work and security review has since been put into the library to disable and remove everything concerning related to string substitution of configuration files using JNDI, but this is also a wider problem for any library or application that uses JNDI without restricting it to only java URIs (e.g., users that use LDAP via JNDI). If the only reason you want to resurrect version 1 is due to a bug in version 2, then I suggest you leave the software industry entirely as nearly 100% of software in existence has flaws, many of them critical. > The Logging PMC is the hostile party here as far as I can tell, operating > in defiance of the community of users that have made the points I have just > written here abundantly clear for years. So far, we had one contributor show up with a complete hostile attitude who refused to engage with the PMC and explain what he wanted to do besides go wild with version 1. Later, Ceki came back and made his first commit in probably a decade attempting to do the same less than a day after we had completed voting on what to do with version 1, again, without ANY comments about what his intentions were or any engagement with the PMC. So far, these two people have spent most of their time trolling in other mailing lists on Apache or elsewhere about the situation while continuing to ignore the PMC’s arguments. If you have a desire to update version 1 that doesn’t boil down to “log4j2 bad bcuz log4shell lol get rekt n00bz”, please explain. > > On Sat, Jan 8,
Re: Looking for a champion: resurrect log4j 1.x
The problem with v1 is that it doesn’t “just work”. There are numerous dead locks and other concurrency problems that were unable to be fixed without breaking various points of compatibility which is why Logback and Log4j2 even exist rather than continuing v1. There would also be difficulty in making a new release without volunteers contributing to the existing PMC to eventually join the PMC to be able to more directly create releases. Apache isn’t going to allow a hostile fork at the Incubator, so it’d still need to work with us or create an external fork that can’t be confused with the Apache version (which would still require a bunch of source code changes to point to the new package name if not already using shading or similar repackaging). I think it’s been said before, but contributing to the v2 backward compatibility system is a great way to join the project in such a way as to eventually form new releases of v1 with a greater understanding of the full impact of changing anything about v1 after such a long time. A poorly made release still wouldn’t be a drop in upgrade for projects that haven’t bothered upgrading in several years, and one that starts to introduce incompatible API changes would further complicate backward compatibility in v2 as well as complicating external projects that rely on a stable legacy API to convert from (like Logback’s config file converter thing or the numerous custom plugins for v1). So far, we haven’t seen any reasonably serious proposals of how anyone expects to do this without causing further mayhem in the future. — Matt Sicker > On Jan 8, 2022, at 14:32, Rohit Yadav wrote: > > Hi Matt, > > Thanks for replying. I think the main issues I found following the guide [1] > for Apache CloudStack (ACS) are: > > - APIs are not backward compatible fully, certainly everywhere the imports > have to be fixed > - The config xml files are not fully compatible requiring some changes > - Our codebase is pretty large with several maven modules/projects enabled by > certain flags, testing changes and ensuring CloudStack works post-migration > adds effort and risks > - Lack of an automatic tooling that can do this reliably and efficiently (for > example, the Go lang ecosystem has gofmt and other tooling to migrate > codebase across std library/lang changes). > - ACS's own tech debt and dependency issues: for example, we're using > log4j-extras (https://logging.apache.org/log4j/extras/) which is completely > discontinued, and have code tied around gson library (for one or more reason, > we've hesitated to upgrade both log4j and gson dependencies) > > Appreciate all the hard work the Log4j team is doing and we'll report issues > as/when we hit them. As a consumer of the dependency, 1.x gave us enough > mileage and end of the day we want logging to be boring that just works; and > therefore I'm simply exploring all possible options (both migration to 2.x or > support/maintain 1.x fork) while understanding their tradeoffs. > > [1] https://logging.apache.org/log4j/2.x/manual/migration.html > >> On 2022/01/08 19:51:07 Matt Sicker wrote: >> It would be nice if you filed any issues with Log4j2 about problems with >> migration. It would have been nice to hear about these issues back when v1 >> stopped development, but this is the next best time to do so. The Log4j team >> are actively working to fill in any remaining gaps on backward >> compatibility; making new releases of EOL software with numerous >> implementation errors inherent to its architecture seems like going >> backwards. >> >> — >> Matt Sicker >> >>>> On Jan 8, 2022, at 13:45, Rohit Yadav wrote: >>> >>> Hi all, >>> >>> I agree and extend support for Andrew's remarks. Apache CloudStack too uses >>> log4j 1.x and our use case is simply a logging library that 1.x just >>> satisfies. The effort to migrate to 2.x is not quick, at least in our >>> initial investigation and a migration may likely require huge effort in >>> testing. >>> >>> Assuming this quick upgrade path doesn't exist, and I already read >>> struggles by other projects trying to migrate to 2.x - maintaining 1.x and >>> doing a 1.2.x release makes more sense than investing weeks in migration >>> and testing to 2.x, while maintaining the same artifact IDs. I'm up for >>> volunteering and supporting 1.x maintenance. >>> >>> Regards, >>> Rohit Yadav >>> PMC, Apache CloudStack >>> >>> On 2021/12/21 21:54:34 Andrew Purtell wrote: >>>>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, >>>> users who haven’t bothe
Re: Looking for a champion: resurrect log4j 1.x
It would be nice if you filed any issues with Log4j2 about problems with migration. It would have been nice to hear about these issues back when v1 stopped development, but this is the next best time to do so. The Log4j team are actively working to fill in any remaining gaps on backward compatibility; making new releases of EOL software with numerous implementation errors inherent to its architecture seems like going backwards. — Matt Sicker > On Jan 8, 2022, at 13:45, Rohit Yadav wrote: > > Hi all, > > I agree and extend support for Andrew's remarks. Apache CloudStack too uses > log4j 1.x and our use case is simply a logging library that 1.x just > satisfies. The effort to migrate to 2.x is not quick, at least in our initial > investigation and a migration may likely require huge effort in testing. > > Assuming this quick upgrade path doesn't exist, and I already read struggles > by other projects trying to migrate to 2.x - maintaining 1.x and doing a > 1.2.x release makes more sense than investing weeks in migration and testing > to 2.x, while maintaining the same artifact IDs. I'm up for volunteering and > supporting 1.x maintenance. > > Regards, > Rohit Yadav > PMC, Apache CloudStack > > On 2021/12/21 21:54:34 Andrew Purtell wrote: >>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, >> users who haven’t bothered to upgrade in 10 years will have to end up >> paying astronomical costs for consultants who can still work on ancient >> software effectively to help modify their systems. >> >> I have to take some exception to this. If the log4j 2.x configuration files >> were compatible _enough_ with 1.x then taking this position would be >> understandable. However, because they are not compatible in the way that >> users require -- and the backwards compatibility is still marked as >> 'experimental', even -- it is not great to blame users "who haven't >> bothered to upgrade in 10 years". Turning this around, why is backwards >> compatibility still experimental after 10 years? I am involved with several >> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and >> have been talking about it for _years_. However, we have not been able to >> easily do so because we actually care about operational cross-version >> compatibility for our users. On some of these projects we are still stuck >> on log4j 1. >> >> I also support continuing releasing for log4j 1.x, and would volunteer some >> of my time to assist in the effort. >> >> >> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker wrote: >> >>> Nobody in the Logging PMC is blocking a release here. What we don’t want >>> is to falsely advertise that v1 is still under development. We already have >>> a huge increase in mailing list, PR, and other traffic ever since >>> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to >>> keep up with all the activity given the size of the PMC. If any non-trivial >>> work is to be done in v1, we’d prefer to see more than one person working >>> on that, especially if we want to add more PMC members to oversee v1 in the >>> first place. >>> >>> And as for the v1 :: COBOL analogy, that’s not a bad comparison. >>> Basically, users who haven’t bothered to upgrade in 10 years will have to >>> end up paying astronomical costs for consultants who can still work on >>> ancient software effectively to help modify their systems. Was Maven even >>> widely used back when v1 was popular? Or were people still using a mix of >>> make or Ant? >>> -- >>> Matt Sicker >>> >>>> On Dec 21, 2021, at 07:13, Romain Manni-Bucau >>> wrote: >>>> >>>> Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli a >>>> écrit : >>>> >>>>> Vladimir, >>>>> I totally support this proposal. >>>>> >>>>> Which are actually the steps we need to cut a release of log4j 1.x ? >>>>> - establish an Apache project ? >>>>> >>>> >>>> 1. Send a patch to apply on >>>> http://svn.apache.org/repos/asf/logging/log4j/trunk >>>> >>>> >>>>> - do the fix >>>>> >>>> >>>> 2. Get it applied >>>> >>>> >>>>> - cut a release >>>>> >>>>> Can this be done inside another Apache Project who "adopts" the log4j >>>>> sources if the Logging Project doesn't want to do it ?
Re: Looking for a champion: resurrect log4j 1.x
The Commons approach isn’t likely to work. Besides sharing several PMC members, it already deprecated Commons Logging in favor of Log4j2 as a logging API. — Matt Sicker > On Dec 22, 2021, at 12:59, Dave Fisher wrote: > > Have the initial committers for this effort been identified? > >> On Dec 22, 2021, at 10:28 AM, Vladimir Sitnikov >> wrote: >> >> Matt>Attaching patches to Jira is exactly how v1 was developed back in the >> day. V2 did it for some time as well before migrating to git >> >> Matt, let us please refrain from off-topic discussions here? (at the end of >> the day, this is "Looking for a champion" thread) > > IMO - this effort would not benefit from Incubation. Incubation will slow > down this effort as graduation requirements won’t fit a small and compact > community that has in mind a singular effort. > > Alternatives ways to organize this: > > (1) Get at least 3 Apache Members together (IPMC members are almost all > Apache Members) and make a Board Resolution to form a new PMC. Fork the > resources, or Logging turns them over. > > (2) Work within the Logging PMC > > (3) Ask the Commons PMC if they would take back Log4J 1.x. > > Regards, > Dave > >> >> If you have objections or comments regarding LOG4J2-3272, would you please >> comment there? >> (I truly do not understand why is it important to know how v1 or v2 >> accepted fixes back in the days) >> >> Vladimir > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
Re: Looking for a champion: resurrect log4j 1.x
Attaching patches to Jira is exactly how v1 was developed back in the day. V2 did it for some time as well before migrating to git. — Matt Sicker > On Dec 22, 2021, at 01:42, Vladimir Sitnikov > wrote: > > Romain, > > Romain>for now the thread is looking for options which are not needed from > my window > > It was the Logging PMC team who suggested I should re-incubate log4j 1.x. > > Romain>1. where is the patch needed to fix the desired CVE? - must be > compatible > with current SVN trunk > > The current SVN trunk is NOT buildable. > It uses outdated build tools, so build system healing > is needed before ANY other patches. > > Romain>2. please attach it to a ticket > > I have just created https://issues.apache.org/jira/browse/LOG4J2-3272 > "Enable Git and GitHub for log4j 1.2 repository" > > Every patch to 1.x must be well-tested, so attaching patch files to JIRA > is a recipe for disaster. > > I already asked Logging PMC to enable Git and GitHub for 1.x, and they > rejected it: > https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2 > > I do not see why filing the same thing as JIRA would work any better than > sending mail to dev@logging list. > > Vladimir
Re: Looking for a champion: resurrect log4j 1.x
Nobody in the Logging PMC is blocking a release here. What we don’t want is to falsely advertise that v1 is still under development. We already have a huge increase in mailing list, PR, and other traffic ever since Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to keep up with all the activity given the size of the PMC. If any non-trivial work is to be done in v1, we’d prefer to see more than one person working on that, especially if we want to add more PMC members to oversee v1 in the first place. And as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, users who haven’t bothered to upgrade in 10 years will have to end up paying astronomical costs for consultants who can still work on ancient software effectively to help modify their systems. Was Maven even widely used back when v1 was popular? Or were people still using a mix of make or Ant? -- Matt Sicker > On Dec 21, 2021, at 07:13, Romain Manni-Bucau wrote: > > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli a > écrit : > >> Vladimir, >> I totally support this proposal. >> >> Which are actually the steps we need to cut a release of log4j 1.x ? >> - establish an Apache project ? >> > > 1. Send a patch to apply on > http://svn.apache.org/repos/asf/logging/log4j/trunk > > >> - do the fix >> > > 2. Get it applied > > >> - cut a release >> >> Can this be done inside another Apache Project who "adopts" the log4j >> sources if the Logging Project doesn't want to do it ? >> > > The PMC of log4j2 is logging project so it should be done there, if not the > project can be forked inside Apache but should change of package until we > get the perms to reuse the same one which means likely as much work as just > getting it done at logging project so hope it is not needed ;). > > >> >> Enrico >> >> >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> ha scritto: >> >>>> Just wondering, is it even fulfilling the criteria of incubation? >>> >>> I believe, the world does not need "active development in log4j 1.x" >>> nowadays. >>> What everybody needs from log4j 1.x is to fix security issues, fix >>> outstanding issues (if any), >>> keep the project buildable (e.g. avoid using outdated build systems), >> etc. >>> >>>> it doesn't seem that sustainability is proven. >>> >>> The problem is log4j 1.x is like COBOL of logging. There are apps that >> are >>> just stuck with log4j 1.x. >>> The proof of sustainability is that lots of existing apps will never >>> upgrade to 2.x because 2.x is incompatible. >>> If the compatibility layer of 2.x would be improved to handle 99.999% of >>> apps, >>> then we could indeed move 1.x to the attic. >>> >>> The Incubator Cookbook says: >>>> The ASF provides software for the public good, >>> >>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and >>> there are **lots** of applications >>> that can't easily be upgraded to 2.x due to testing, configuration, and >>> implementation issues. >>> >>> The current Logging PMC is focused on log4j 2.x only, and they have no >>> desire to release 1.x >>> >>>> active development but focus only on CVE fixes >>> >>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs, >> and >>> keep the project buildable and testable. >>> However, it might be the case, that certain fixes or features would >> appear. >>> >>> The sad story is that the industry is using 1.x A LOT, and what Logging >> PMC >>> did was >>> they ignored the community, and they just stopped maintaining 1.x and >>> focused on an incompatible 2.x >>> >>> Not only do they stop maintaining 1.x, but they also deny others to pick >> up >>> the maintenance task. >>> >>> What I am trying to do now is to pick up that maintenance activity. >>> >>> Vladimir >>> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Liminal (incubating) 0.0.2rc1-INCUBATING
LGPL is only allowed in optional dependencies. On Tue, Apr 20, 2021 at 08:31 Lior Schachter wrote: > We can't just remove this dependency as it comes from the Airflow package > deoendencies. > > On Tue, Apr 20, 2021, 15:51 JB Onofré wrote: > > > Did it change about LGPL ? I’m pretty sure LGPL was cat B and GPL was cat > > X. > > Maybe it changed (or I’m wrong). > > > > Anyway I would cancel this vote to remove this dependency. > > > > Regards > > JB > > > > > Le 20 avr. 2021 à 14:20, Lior Schachter a écrit : > > > > > > Hi Justin, > > > chardet is indeed LGPL (https://pypi.org/project/chardet/). > > > > > > However, from a quick analysis it seems it is installed as Apache > Airflow > > > project dependency. > > > See below the dependency analysis of this package. > > > > > > (apache-liminal-002rc1) lior.schachter@liors-mac > > liminal-getting-started % > > > pipdeptree --reverse --packages chardet > > > > > > chardet==4.0.0 > > > > > > - requests==2.25.1 [requires: chardet>=3.0.2,<5] > > > > > >- apache-airflow==1.10.12 [requires: requests>=2.20.0,<3] > > > > > > - apache-liminal==0.0.2rc1 [requires: apache-airflow==1.10.12] > > > > > >- docker==4.2.0 [requires: requests>=2.14.2,!=2.18.0] > > > > > > - apache-liminal==0.0.2rc1 [requires: docker==4.2.0] > > > > > >- kubernetes==12.0.1 [requires: requests] > > > > > > - apache-liminal==0.0.2rc1 [requires: kubernetes==12.0.1] > > > > > >- requests-oauthlib==1.3.0 [requires: requests>=2.0.0] > > > > > > - kubernetes==12.0.1 [requires: requests-oauthlib] > > > > > >- apache-liminal==0.0.2rc1 [requires: kubernetes==12.0.1] > > > > > > Please advise how to proceed, > > > Lior > > > > > >> On Tue, Apr 20, 2021 at 11:53 AM Hans Van Akelyen < > > >> hans.van.akel...@gmail.com> wrote: > > >> > > >> Aren't both (L)GPL Category X [1]? > > >> > > >> Cheers, > > >> Hans > > >> > > >> [1] https://www.apache.org/legal/resolved.html > > >> > > >> On Tue, 20 Apr 2021 at 10:48, Jean-Baptiste Onofre > > >> wrote: > > >> > > >>> Good catch. AFAIR chardet is LGPL based (not GPL), and LGPL is Cat B > > (not > > >>> X). > > >>> > > >>> @Liminal team, do you confirm LGPL license for chardet (on Pypi) ? > > >>> > > >>> Regards > > >>> JB > > >>> > > Le 20 avr. 2021 à 08:43, Justin Mclean a > > >>> écrit : > > > > Hi, > > > > Sorry it’s -1 (binding) form me. If issue re the dependancy is > > >> clarified > > >>> I’ll change my vote. > > > > I checked: > > - incubating in name > > - signatures and hashes are fine > > - DISCLAIMER exists > > - LICENSE and NOTICE fine > > - no expected binary files > > - All source files have ASF headers > > > > I was looking the dependancies and noticed one with Category X GPL > > >>> license - chardet > > > > 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: JPMS Projects?
I did find one small library that shows some of the useful possibilities of adding proper module info to something for 9+ runtimes (especially when using modules): https://github.com/cryptography-cafe/curve25519-elisabeth On Thu, 18 Mar 2021 at 09:36, wrote: > > Agree, and if you want to check some Apache projects related to OSGi you > can take a look to: > > - Apache Karaf : https://karaf.apache.org > > - Apache Felix : https://felix.apache.org > > regards, > > François > fpa...@apache.org > > Le 18/03/2021 à 15:25, Serge Huber a écrit : > > I was also going to mention OSGi. It enforces better lifecycle management > > than JPMS. If you can do it with OSGi you can certainly use it with JPMS > > > > Regards, > > Serge... > > > > On Thu, Mar 18, 2021 at 3:19 PM Matt Sicker wrote: > > > >> Perhaps the various OSGi-related projects here might be similar to what > >> you’re looking for since those have enforced modularity for a long time. > >> That module system is more advanced than JPMS, but the concepts are fairly > >> similar. > >> > >> We’ve also been looking into this for log4j 3.0, but that’s not out yet. > >> > >> On Thu, Mar 18, 2021 at 01:06 Daniel Widdis wrote: > >> > >>> After considering this email I wrote, I regret sending it and want to > >>> apologize if I have overstepped any bounds. > >>> > >>> I am not a member of the IPMC or associated in any formal way with Apache > >>> and am certainly not in any position to make any judgments regarding code > >>> quality or your wise choice to begin your search with such projects. > >>> > >>> I'll back out of this conversation now and let others answer or redirect > >>> you to other resources. > >>> > >>> Dan > >>> > >>> > >>> On 3/17/21, 10:21 PM, "Daniel Widdis" wrote: > >>> > >>> Thanks for your clarifications. > >>> > >>> Regarding "Apache" = "Quality", I'd be careful. Apache asserts [1] a > >>> maxim of "Community over code". While certainly a broad community > >>> inevitably leads to better code, and Apache is a good starting point, > >> given > >>> the specificity of your request I might start there but not exclude other > >>> established projects (not random code) which follow many of the same > >>> principles. > >>> > >>> I do hope those on this list are aware of some projects they can > >>> recommend to you! > >>> > >>> As for the technical specifications, I'd also recommend you'd > >> separate > >>> those out as well. Some of your concerns seem to deal with native code > >>> access which seems a separate issue than modular design of code. I have > >>> also been looking around for good Panama/FMA examples and haven't seen > >>> anything non-trivial yet. But even those can be done with/without the > >> Java > >>> Module System (JPMS). > >>> > >>> Looking forward to any other replies with interest. > >>> > >>> Dan > >>> > >>> [1] - https://www.apache.org/theapacheway/ > >>> > >>> On 3/17/21, 10:08 PM, "leerho" wrote: > >>> > >>> Daniel, > >>> Thank you for your reply. > >>> > >>> > >>> > Can you clarify what you mean by an "Apache Java project"? > >>> > >>> > >>> I would prefer to examine a project that has a formal release > >>> process and > >>> an active community. So a TLP or incubating project would be > >>> great. In > >>> this case I was equating "Apache" = "Quality" :) > >>> > >>> I'm not so interested in random code on the Internet that just > >>> happens to > >>> be Apache licensed :) > >>> > >>> Is there a particular use case you are interested in? > >>> > >>> > >>> I am seriously looking at *redesigning* our JDK8 Library using > >>> Java Modules > >>> leveraging JDK16+/Panama/FMA and completely replacing the need > >> for > >>> Unsafe, > >>> etc. (Not just adapting our JDK8 code to run on JDK9+ and > >>>
Re: JPMS Projects?
Perhaps the various OSGi-related projects here might be similar to what you’re looking for since those have enforced modularity for a long time. That module system is more advanced than JPMS, but the concepts are fairly similar. We’ve also been looking into this for log4j 3.0, but that’s not out yet. On Thu, Mar 18, 2021 at 01:06 Daniel Widdis wrote: > After considering this email I wrote, I regret sending it and want to > apologize if I have overstepped any bounds. > > I am not a member of the IPMC or associated in any formal way with Apache > and am certainly not in any position to make any judgments regarding code > quality or your wise choice to begin your search with such projects. > > I'll back out of this conversation now and let others answer or redirect > you to other resources. > > Dan > > > On 3/17/21, 10:21 PM, "Daniel Widdis" wrote: > > Thanks for your clarifications. > > Regarding "Apache" = "Quality", I'd be careful. Apache asserts [1] a > maxim of "Community over code". While certainly a broad community > inevitably leads to better code, and Apache is a good starting point, given > the specificity of your request I might start there but not exclude other > established projects (not random code) which follow many of the same > principles. > > I do hope those on this list are aware of some projects they can > recommend to you! > > As for the technical specifications, I'd also recommend you'd separate > those out as well. Some of your concerns seem to deal with native code > access which seems a separate issue than modular design of code. I have > also been looking around for good Panama/FMA examples and haven't seen > anything non-trivial yet. But even those can be done with/without the Java > Module System (JPMS). > > Looking forward to any other replies with interest. > > Dan > > [1] - https://www.apache.org/theapacheway/ > > On 3/17/21, 10:08 PM, "leerho" wrote: > > Daniel, > Thank you for your reply. > > > > Can you clarify what you mean by an "Apache Java project"? > > > I would prefer to examine a project that has a formal release > process and > an active community. So a TLP or incubating project would be > great. In > this case I was equating "Apache" = "Quality" :) > > I'm not so interested in random code on the Internet that just > happens to > be Apache licensed :) > > Is there a particular use case you are interested in? > > > I am seriously looking at *redesigning* our JDK8 Library using > Java Modules > leveraging JDK16+/Panama/FMA and completely replacing the need for > Unsafe, > etc. (Not just adapting our JDK8 code to run on JDK9+ and > accessing Java > internals using JVM args.) > > This is a major undertaking so being able to look at projects that > have > already gone through that process would be helpful. > > Thank you, > > Lee. > > On Wed, Mar 17, 2021 at 3:42 PM Daniel B. Widdis > wrote: > > > Can you clarify what you mean by an "Apache Java project"? > > - A TLP? > > - An incubating project? > > - A project anywhere that is released under the Apache license? > > > > There's actually no need to "migrate code" in many cases, just > add some > > files. Is there a particular use case you are interested in? > > > > On Wed, Mar 17, 2021 at 3:11 PM leerho wrote: > > > > > Folks, > > > Is anyone aware of an Apache Java project that has actually > migrated > > their > > > code from Java 8 to the Java Platform Module System (JPMS)? > > > > > > Thanks, > > > Lee. > > > > > > > > > -- > > Dan Widdis > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Teaclave (incubating) v0.2.0-rc.1
Alright, finally finished building and running tests. All passed after upping the memory limits to 8 GB, thought that might be overkill. +1 On Sun, 28 Feb 2021 at 16:43, Yiming Jing wrote: > > +1 approve > > On 2021/02/26 18:26:28, Mingshen Sun wrote: > > Dear community, > > > > This is a call for a vote to release Apache Teaclave (incubating) > > version 0.2.0. This is the second Apache release since Teaclave > > entered the incubator. > > > > The Apache Teaclave (incubating) community has voted and approved the > > release, with four +1 votes from IPMC members (Pei Wang, Yulong Zhang, > > Rundong Zhou, Tongxin Li). > > > > Vote/result thread: > > - > > https://lists.apache.org/thread.html/rd0ca1591578bcc60d73ce8722908d5001bd81dffe7a33e205bd28184%40%3Cdev.teaclave.apache.org%3E > > > > The release candidate to be voted over is available at: > > - https://dist.apache.org/repos/dist/dev/incubator/teaclave/0.2.0-rc.1/ > > > > The release candidate is signed with a GPG key available at: > > - https://dist.apache.org/repos/dist/dev/incubator/teaclave/KEYS > > > > The Git commit for this release is: > > - > > https://gitbox.apache.org/repos/asf?p=incubator-teaclave.git;a=commit;h=0d1a001bb4741e3c652d121d2dfafa5d9361f84c > > > > The release note is available in: > > - https://github.com/apache/incubator-teaclave/releases/tag/v0.2.0-rc.1 > > > > Build guide and get started instructions can be found at: > > - > > https://github.com/apache/incubator-teaclave/blob/v0.2.0-rc.1/docs/my-first-function.md > > > > The short version of building Teaclave from the source tarball: > > > > ``` > > $ wget > > https://dist.apache.org/repos/dist/dev/incubator/teaclave/0.2.0-rc.1/apache-teaclave-0.2.0-rc.1-incubating.tar.gz > > $ tar zxvf apache-teaclave-0.2.0-rc.1-incubating.tar.gz && cd > > apache-teaclave-0.2.0-rc.1-incubating > > $ # Instructions to verify the source tar: > > https://teaclave.apache.org/download/#verify-the-integrity-of-the-files > > > > $ docker run --rm -v $(pwd):/teaclave -w /teaclave \ > > -it teaclave/teaclave-build-ubuntu-1804-sgx-2.9.1:latest \ > >bash -c ". /root/.cargo/env && \ > > . /opt/sgxsdk/environment && \ > > mkdir -p build && cd build && \ > > cmake -DTEST_MODE=ON DSGX_SIM_MODE=ON -DGIT_SUBMODULE=OFF .. && \ > > make" > > ``` > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > > > Best, > > > > Mingshen Sun > > http://mssun.me > > > > - > > 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] Release Apache Teaclave (incubating) v0.2.0-rc.1
Alright, I'll try compiling with more resources allocated to Docker and report back. On Sun, 28 Feb 2021 at 14:10, Mingshen Sun wrote: > > Hi Matt, > > For your case, I believe it is because of the memory limit > (out-of-memory) of Docker for macOS. The Rust compiler needs more > memory than others. > > Best, > Mingshen > > > On Sun, Feb 28, 2021 at 11:57 AM Matt Sicker wrote: > > > > I tried building on macOS as well, and it got fairly far and ended up > > failing at this point: > > > > Scanning dependencies of target sgxlib-teaclave_authentication_service > > [ 37%] Building sgxlib-teaclave_authentication_service, enclave info > > to > > /teaclave/build/intermediate/teaclave_authentication_service_enclave_info.toml > >Compiling crc v2.0.0 > > (https://github.com/mesalock-linux/crc-rs-sgx#86696be0) > >Compiling teaclave_proto v0.2.0 > > (/teaclave/build/cmake_tomls/sgx_trusted_lib/services/proto) > >Compiling integer-encoding v1.0.7 > >Compiling snap v0.2.5 > >Compiling jsonwebtoken v6.0.1 > > error: could not compile `crc`. > > > > Caused by: > > process didn't exit successfully: > > `/teaclave/cmake/scripts/rustc_wrapper.sh --crate-name crc > > --edition=2018 > > /teaclave/build/cmake_tomls/sgx_trusted_lib/third_party/crates-sgx/vendor/crc/src/lib.rs > > --error-format=json --json=diagnostic-rendered-ansi,artifacts > > --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C > > metadata=39ca99cb54d77a3c -C extra-filename=-39ca99cb54d77a3c > > --out-dir /teaclave/build/target/trusted/debug/deps -L > > dependency=/teaclave/build/target/trusted/debug/deps --cap-lints allow > > --cfg test_mode` (signal: 9, SIGKILL: kill) > > /usr/bin/ld: cannot find -lteaclave_authentication_service_enclave > > collect2: error: ld returned 1 exit status > > CMakeFiles/sgxlib-teaclave_authentication_service.dir/build.make:57: > > recipe for target 'CMakeFiles/sgxlib-teaclave_authentication_service' > > failed > > make[2]: *** [CMakeFiles/sgxlib-teaclave_authentication_service] Error 1 > > CMakeFiles/Makefile2:301: recipe for target > > 'CMakeFiles/sgxlib-teaclave_authentication_service.dir/all' failed > > make[1]: *** [CMakeFiles/sgxlib-teaclave_authentication_service.dir/all] > > Error 2 > > Makefile:83: recipe for target 'all' failed > > make: *** [all] Error 2 > > > > Full build log output here: > > https://gist.github.com/jvz/b214f28b788f6459b8e511149781e52a > > > > Signatures, notice, license, disclaimer all good. > > > > On Sun, 28 Feb 2021 at 13:37, Mingshen Sun wrote: > > > > > > Thanks Furkan, > > > > > > I just tried to download and compile it in a clean Linux environment, > > > and can successfully compile the code. > > > > > > Are you working on macOS? Because of the case-insensitive file system > > > of macOS, Git cannot distinguish the KEYS file and keys directory. > > > That may cause the keys directory is not checkout. > > > > > > I'll fix this in the next release. > > > > > > Best, > > > Mingshen > > > > > > On Sat, Feb 27, 2021 at 12:30 AM Furkan KAMACI > > > wrote: > > > > > > > > Hi, > > > > > > > > +1 from me (I have notes below). > > > > > > > > I checked: > > > > > > > > - Incubating in name > > > > - DISCLAIMER-WIP exists > > > > - LICENSE is fine > > > > - NOTICE has *incorrect* *year* which should be fixed > > > > - No unexpected binary files > > > > - Checked PGP signatures > > > > - Checked checksums > > > > > > > > I got that error while compiling the project: > > > > > > > > Digest: > > > > sha256:cb80cb3da4ddb15713ecd7ea8b6f4eab144c402644ece8116e762a19886d7ada > > > > Status: Downloaded newer image for > > > > teaclave/teaclave-build-ubuntu-1804-sgx-2.9.1:latest > > > > -- The C compiler identification is GNU 7.5.0 > > > > -- Check for working C compiler: /usr/bin/cc > > > > -- Check for working C compiler: /usr/bin/cc -- works > > > > -- Detecting C compiler ABI info > > > > -- Detecting C compiler ABI info - done > > > > -- Detecting C compile features > > > > -- Detecting C compile features - done > > > > -- Found Git: /usr/bin/git (found version "2.27.0") > > > > -- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so
Re: [VOTE] Release Apache Teaclave (incubating) v0.2.0-rc.1
I tried building on macOS as well, and it got fairly far and ended up failing at this point: Scanning dependencies of target sgxlib-teaclave_authentication_service [ 37%] Building sgxlib-teaclave_authentication_service, enclave info to /teaclave/build/intermediate/teaclave_authentication_service_enclave_info.toml Compiling crc v2.0.0 (https://github.com/mesalock-linux/crc-rs-sgx#86696be0) Compiling teaclave_proto v0.2.0 (/teaclave/build/cmake_tomls/sgx_trusted_lib/services/proto) Compiling integer-encoding v1.0.7 Compiling snap v0.2.5 Compiling jsonwebtoken v6.0.1 error: could not compile `crc`. Caused by: process didn't exit successfully: `/teaclave/cmake/scripts/rustc_wrapper.sh --crate-name crc --edition=2018 /teaclave/build/cmake_tomls/sgx_trusted_lib/third_party/crates-sgx/vendor/crc/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=39ca99cb54d77a3c -C extra-filename=-39ca99cb54d77a3c --out-dir /teaclave/build/target/trusted/debug/deps -L dependency=/teaclave/build/target/trusted/debug/deps --cap-lints allow --cfg test_mode` (signal: 9, SIGKILL: kill) /usr/bin/ld: cannot find -lteaclave_authentication_service_enclave collect2: error: ld returned 1 exit status CMakeFiles/sgxlib-teaclave_authentication_service.dir/build.make:57: recipe for target 'CMakeFiles/sgxlib-teaclave_authentication_service' failed make[2]: *** [CMakeFiles/sgxlib-teaclave_authentication_service] Error 1 CMakeFiles/Makefile2:301: recipe for target 'CMakeFiles/sgxlib-teaclave_authentication_service.dir/all' failed make[1]: *** [CMakeFiles/sgxlib-teaclave_authentication_service.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 Full build log output here: https://gist.github.com/jvz/b214f28b788f6459b8e511149781e52a Signatures, notice, license, disclaimer all good. On Sun, 28 Feb 2021 at 13:37, Mingshen Sun wrote: > > Thanks Furkan, > > I just tried to download and compile it in a clean Linux environment, > and can successfully compile the code. > > Are you working on macOS? Because of the case-insensitive file system > of macOS, Git cannot distinguish the KEYS file and keys directory. > That may cause the keys directory is not checkout. > > I'll fix this in the next release. > > Best, > Mingshen > > On Sat, Feb 27, 2021 at 12:30 AM Furkan KAMACI wrote: > > > > Hi, > > > > +1 from me (I have notes below). > > > > I checked: > > > > - Incubating in name > > - DISCLAIMER-WIP exists > > - LICENSE is fine > > - NOTICE has *incorrect* *year* which should be fixed > > - No unexpected binary files > > - Checked PGP signatures > > - Checked checksums > > > > I got that error while compiling the project: > > > > Digest: > > sha256:cb80cb3da4ddb15713ecd7ea8b6f4eab144c402644ece8116e762a19886d7ada > > Status: Downloaded newer image for > > teaclave/teaclave-build-ubuntu-1804-sgx-2.9.1:latest > > -- The C compiler identification is GNU 7.5.0 > > -- Check for working C compiler: /usr/bin/cc > > -- Check for working C compiler: /usr/bin/cc -- works > > -- Detecting C compiler ABI info > > -- Detecting C compiler ABI info - done > > -- Detecting C compile features > > -- Detecting C compile features - done > > -- Found Git: /usr/bin/git (found version "2.27.0") > > -- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version > > "1.1.1") > > SGX_SDK=/opt/sgxsdk > > SGX_MODE=HW > > RUSTUP_TOOLCHAIN=nightly-2020-04-07 > > DCAP=OFF > > BUILD_TYPE=debug > > TEACLAVE_SYMLINKS=/tmp/teaclave_symlinks.Dvayr2ejnVKi > > -- == /teaclave/build/environment GENERATED == > > -- Configuring done > > -- Generating done > > -- Build files have been written to: /teaclave/build > > Scanning dependencies of target prep > > cp: cannot stat '/teaclave/keys/dcap_server_cert.pem': Not a directory > > CMakeFiles/prep.dir/build.make:57: recipe for target 'CMakeFiles/prep' > > failed > > make[2]: *** [CMakeFiles/prep] Error 1 > > CMakeFiles/Makefile2:819: recipe for target 'CMakeFiles/prep.dir/all' failed > > make[1]: *** [CMakeFiles/prep.dir/all] Error 2 > > Makefile:83: recipe for target 'all' failed > > make: *** [all] Error 2 > > > > Kind Regards, > > Furkan KAMACI > > > > On Fri, Feb 26, 2021 at 10:42 PM Yu Ding wrote: > > > > > +1 approve > > > > > > On 2021/02/26 18:26:28, Mingshen Sun wrote: > > > > Dear community, > > > > > > > > This is a call for a vote to release Apache Teaclave (incubating) > > > > version 0.2.0. This is the second Apache release since Teaclave > > > > entered the incubator. > > > > > > > > The Apache Teaclave (incubating) community has voted and approved the > > > > release, with four +1 votes from IPMC members (Pei Wang, Yulong Zhang, > > > > Rundong Zhou, Tongxin Li). > > > > > > > > Vote/result thread: > > > > - > > > https://lists.apache.org/thread.html/rd0ca1591578bcc60d73ce8722908d5001bd81dffe7a33e205bd28184%40%3Cdev.teaclave.apache.org%3E > > > > > > > > The
Re: Travis job on github
It's probably simpler to write some sort of LCOV format converter to something supported by your destination build system than it would be to rewrite the rest of your toolchain, but that's just conjecture. On Sun, 31 Jan 2021 at 20:25, leerho wrote: > > Sorry, I must be missing something. I don't see LCOV format in the list :) > Doesn't this mean a complete rework of our toolchain ? > > On Sun, Jan 31, 2021 at 1:19 PM Matt Sicker wrote: > > > Using https://github.com/jenkinsci/warnings-ng-plugin (already > > installed) combined with the github integration (also installed), you > > can get that in our CloudBees CI instance. They support a lot of > > formats: > > https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md > > > > On Sun, 31 Jan 2021 at 00:53, leerho wrote: > > > > > > I am trying to move from Travis to GitHub actions for exactly this > > reason, > > > but in that process discovered that our coverage reporting chain of > > > Maven/Java/Jacoco/Coveralls does not port to GHA because the current GHA > > > adapter for Coveralls only supports LCOV format which Jacoco doesn’t > > > generate. Converting to CodeCov is a nonstarter because CodeCov is $$! > > > > > > If anybody has any ideas, please let me know! > > > > > > Lee. > > > > > > On Thu, Jan 28, 2021 at 10:02 PM Weiwei Yang wrote: > > > > > > > Oh, that's good. Then we have no problem at all. > > > > Thank you Daniel for pointing this out : ) > > > > > > > > On Thu, Jan 28, 2021 at 9:48 PM Daniel Widdis > > wrote: > > > > > > > > > The quota is for private repos. Public/open-source repos are > > essentially > > > > > unlimited. > > > > > > > > > > On 1/28/21, 9:44 PM, "Weiwei Yang" wrote: > > > > > > > > > > Thank you all for the suggestions. > > > > > Looks like github action is an option, we'll give a try. > > > > > Noticed they offer 2000 action minutes/month[1] for free, I think > > > > that > > > > > should be enough for most cases. > > > > > > > > > > [1] > > > > > > > > > > > > > > > > https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions > > > > > > > > > > On Thu, Jan 28, 2021 at 6:36 PM Matt Sicker > > > > wrote: > > > > > > > > > > > There's also some hosted CI services here like Jenkins, > > BuildBot, > > > > > > etc., which may have less queueing issues depending on which > > > > service > > > > > > attracts the most build minute usage. > > > > > > > > > > > > On Thu, 28 Jan 2021 at 20:23, Jon Malkin > > > > > > > wrote: > > > > > > > > > > > > > > There was an issue a few months ago where the GitHub Actions > > > > queue > > > > > was > > > > > > very > > > > > > > laggy for Apache jobs, so just make sure you're trying to be > > > > > efficient > > > > > > > about it. It's also a shared resource. > > > > > > > > > > > > > > That said, (part of) our recently graduated project uses > > GitHub > > > > > Actions > > > > > > and > > > > > > > we've been happy overall. Another part is currently moving > > to it > > > > > from > > > > > > > Travis for the exact same reason. > > > > > > > > > > > > > > jon > > > > > > > > > > > > > > On Thu, Jan 28, 2021, 6:15 PM Juan Pan > > > > wrote: > > > > > > > > > > > > > > > Hi Weiwei, > > > > > > > > > > > > > > > > > > > > > > > > +1 for Jeff’s suggestion. > > > > > > > > We also transfer to GitHub Action, and It generally works > > well > > > > > so far. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Travis job on github
Using https://github.com/jenkinsci/warnings-ng-plugin (already installed) combined with the github integration (also installed), you can get that in our CloudBees CI instance. They support a lot of formats: https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md On Sun, 31 Jan 2021 at 00:53, leerho wrote: > > I am trying to move from Travis to GitHub actions for exactly this reason, > but in that process discovered that our coverage reporting chain of > Maven/Java/Jacoco/Coveralls does not port to GHA because the current GHA > adapter for Coveralls only supports LCOV format which Jacoco doesn’t > generate. Converting to CodeCov is a nonstarter because CodeCov is $$! > > If anybody has any ideas, please let me know! > > Lee. > > On Thu, Jan 28, 2021 at 10:02 PM Weiwei Yang wrote: > > > Oh, that's good. Then we have no problem at all. > > Thank you Daniel for pointing this out : ) > > > > On Thu, Jan 28, 2021 at 9:48 PM Daniel Widdis wrote: > > > > > The quota is for private repos. Public/open-source repos are essentially > > > unlimited. > > > > > > On 1/28/21, 9:44 PM, "Weiwei Yang" wrote: > > > > > > Thank you all for the suggestions. > > > Looks like github action is an option, we'll give a try. > > > Noticed they offer 2000 action minutes/month[1] for free, I think > > that > > > should be enough for most cases. > > > > > > [1] > > > > > > > > https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions > > > > > > On Thu, Jan 28, 2021 at 6:36 PM Matt Sicker > > wrote: > > > > > > > There's also some hosted CI services here like Jenkins, BuildBot, > > > > etc., which may have less queueing issues depending on which > > service > > > > attracts the most build minute usage. > > > > > > > > On Thu, 28 Jan 2021 at 20:23, Jon Malkin > > > wrote: > > > > > > > > > > There was an issue a few months ago where the GitHub Actions > > queue > > > was > > > > very > > > > > laggy for Apache jobs, so just make sure you're trying to be > > > efficient > > > > > about it. It's also a shared resource. > > > > > > > > > > That said, (part of) our recently graduated project uses GitHub > > > Actions > > > > and > > > > > we've been happy overall. Another part is currently moving to it > > > from > > > > > Travis for the exact same reason. > > > > > > > > > > jon > > > > > > > > > > On Thu, Jan 28, 2021, 6:15 PM Juan Pan > > wrote: > > > > > > > > > > > Hi Weiwei, > > > > > > > > > > > > > > > > > > +1 for Jeff’s suggestion. > > > > > > We also transfer to GitHub Action, and It generally works well > > > so far. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Juan Pan (Trista) > > > > > > > > > > > > Senior DBA & PMC of Apache ShardingSphere > > > > > > E-mail: panj...@apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 01/29/2021 08:00，Jeff Zhang wrote： > > > > > > Hi Weiwei, > > > > > > > > > > > > May you can consider to use github action for CI > > > > > > > > > > > > > > > > > > > > > > > > Weiwei Yang 于2021年1月29日周五 上午7:58写道： > > > > > > > > > > > > Hi, > > > > > > > > > > > > The Apache YuniKorn (Incubating) team leverages Travis to run > > > > pre-commit > > > > > > checks, but recently the Travis Job stays in the queue for long > > > hours > > > > (6+ > > > > > > hours, sometimes more than 10 hours) . This is highly impacting > > > the > > > > > > productivity. I have reached the Travis support and the > > response > > > I got > > > > was > > > > > > the jobs got rate limited under Apache repo. Is there any > > > suggestion > > > > how to > > > > > > fix this issue? > > > > > > > > > > > > Thanks > > > > > > Weiwei > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best Regards > > > > > > > > > > > > Jeff Zhang > > > > > > > > > > > > > > > > - > > > > 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 > > > > > > > > > -- > From my cell phone. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Travis job on github
There's also some hosted CI services here like Jenkins, BuildBot, etc., which may have less queueing issues depending on which service attracts the most build minute usage. On Thu, 28 Jan 2021 at 20:23, Jon Malkin wrote: > > There was an issue a few months ago where the GitHub Actions queue was very > laggy for Apache jobs, so just make sure you're trying to be efficient > about it. It's also a shared resource. > > That said, (part of) our recently graduated project uses GitHub Actions and > we've been happy overall. Another part is currently moving to it from > Travis for the exact same reason. > > jon > > On Thu, Jan 28, 2021, 6:15 PM Juan Pan wrote: > > > Hi Weiwei, > > > > > > +1 for Jeff’s suggestion. > > We also transfer to GitHub Action, and It generally works well so far. > > > > > > > > > > > >Juan Pan (Trista) > > > > Senior DBA & PMC of Apache ShardingSphere > > E-mail: panj...@apache.org > > > > > > > > > > On 01/29/2021 08:00，Jeff Zhang wrote： > > Hi Weiwei, > > > > May you can consider to use github action for CI > > > > > > > > Weiwei Yang 于2021年1月29日周五 上午7:58写道： > > > > Hi, > > > > The Apache YuniKorn (Incubating) team leverages Travis to run pre-commit > > checks, but recently the Travis Job stays in the queue for long hours (6+ > > hours, sometimes more than 10 hours) . This is highly impacting the > > productivity. I have reached the Travis support and the response I got was > > the jobs got rate limited under Apache repo. Is there any suggestion how to > > fix this issue? > > > > Thanks > > Weiwei > > > > > > > > -- > > Best Regards > > > > Jeff Zhang > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] EventMesh Proposal
It's typically a good idea to figure out your project name early on. If you have to change the name before graduation in order to get a trademark, then that wastes the momentum gathered under the old name. That can always happen after the podling boots up, though. On Wed, 27 Jan 2021 at 07:44, Sheng Wu wrote: > > This is just a reminder, not an instruction. > The naming search and approval will officially happen when you are powerful > enough to graduate. > Personally, I would like to see this as a potential risk, not just > regarding Solace. > > Of course, this is your option. you should know, if you can't get approval > in the future, you will have a much bigger branding hurt. > (You don't need to convince me) > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > ShannonDing 于2021年1月27日周三 下午9:23写道： > > > > > > > I would like to make a comments about this serious problem too, > > In order not to cause unnecessary trouble in the future, we also request > > the infra member from apache to help check whether this name is > > appropriate[1]. > > For us, we have used the name EventMesh for a long time, and we want to > > keep it so that users can get better product positioning from this name. > > According to this document[2], we also searched in the US Patent Office[3] > > and found no non-compliance. > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-21353 > > [2] https://incubator.apache.org/guides/names.html > > [3] https://www.uspto.gov/trademark > > > > > > > > > > On 01/27/2021 21:11，Eason Chen wrote： > > @Sheng Wu > > thank you for your kindly reminder. I would like to clarify this concerns. > > > > As @Duane Pauls clarified this before: > > “*I work for Solace and have consulted internally to confirm that we do not > > have any copyright or trademark on the term “Event Mesh”. It’s true it is > > something our products are closely aligned with。 Solace does not oppose the > > term being used in other applicable products or projects.*” > > Solace do not have any copyright or trademark on the term “Event Mesh”. > > > > On Wed, Jan 27, 2021 at 5:17 PM Sheng Wu > > wrote: > > > > Hi > > > > I want to send a reminder for your project name chosen. > > Event Mesh is widely used as a concept and term, you could find it through > > Google search, https://www.google.com/search?q=event+mesh=event+mesh > > > > Sheng Wu 吴晟 > > Twitter, wusheng1108 > > > > > > 于2021年1月27日周三 下午5:12写道： > > > > Hi, > > > > Yes, it looks very promising. > > > > I will be very happy to help in the incubation process and integrate the > > project into Karaf with JB ;) > > > > regards, > > > > François > > fpa...@apache.org > > > > Le 27/01/2021 à 10:07, vongosling a écrit : > > Hi, > > > > This is a very young but promising project. The team attached great > > importance to this project according to the feedback given by > > communities. > > Through the efforts of the last five months, I am glad to see positive > > changes in the project and community. > > > > @Jean-Baptiste Onofré EventMesh really need > > to improve its lighter plugin modules, karaf may be a good optional > > > > Best Regards, > > Von Gosling > > > > Jean-Baptiste Onofre 于2021年1月27日周三 下午4:43写道： > > > > Hi Eason, > > > > That’s an interesting proposal, indeed. > > > > I would rewrite some part of the proposal, but overall good. > > > > I will check if the EventMesh architecture is "pluggable", meaning > > that > > we > > "could" replace RocketMQ with another messaging/async provider. > > > > Anyway, if you need some help on the project, please let me know, it’s > > interesting and could be a good extend to Apache Karaf for instance. > > > > Regards > > JB > > > > Le 27 janv. 2021 à 09:32, Eason Chen a > > écrit : > > Good time of the time to all! > > > > I'd like to bring this new interesting project for the discussion, > > comments > > and feedback with the aim of starting a formal [VOTE] of its > > acceptance > > into Incubator. > > > > People behind this project aren't new to Apache: some of them were > > behind > > the Apache RocketMQ, which I consider a huge success(especially in > > China) > > as the community is literally thriving almost 5 years after the > > graduation. > > I have been involved a little bit with this project when it just > > started > > in > > WeBank a few years ago. And I'd like to emphasize that the community > > however small it might look so far, has been aligned with Apache ways > > of > > doing things. Von Gosling is very instrumental in tirelessly helping > > this > > group to learn what it means to be a truly open source project. > > > > The code is already under ALv2 and is publicly available. As you will > > see > > it has a lot of dependency connections with the rest of Apache > > ecosystem > > and IMO will fit very well here and continue to grow the community. > > > > By the way, we still need 1 to 2 mentors, please let me know if you > > are > > interested. > > > > With best regards, > > > > The project's proposal is
Re: [DISCUSS] Apache TVM Graduation
Makes sense. Do you think the recent changes to Docker Hub will affect this? It might be a good idea to move the images into the Apache org, even if they’re not for end users. On Fri, Aug 28, 2020 at 20:52 Tianqi Chen wrote: > Thanks Matt! > > > > That was indeed the approach we used before. The main problem of this > > approach is > > - There could be certain upstream changes (say tensorflow get updated) that > > may not retrigger the rebuild > > - The CI instance itself can quickly get crowded by the historical cached > > images and causes disk overflow problems. > > - Overall we find it is very hard to reproduce the CI error when there is a > > problem because of the potential mismatch(due to stale build) > > > > So the community switched to using a stable binary tag as for more stable > > env without blocking the CI, while periodically updating > > these images when this is a dependency change. > > > > TQ > > > > On Fri, Aug 28, 2020 at 6:47 PM Matt Sicker wrote: > > > > > Is there even a need to upload the Docker images for CI? Docker > recognizes > > > layers by checksums, so CI build agents will cache the image layers > > > regardless of whether or not you upload them to Docker Hub. Layers get > > > rebuilt when the Docker file changes or you force an update. > > > > > > On Fri, Aug 28, 2020 at 20:12 Tianqi Chen wrote: > > > > > > > Thanks Justin and Henry for the discussion thread. > > > > > > > > > > > > > > > > Please allow me to dissect and summarize again some of the discussion > > > > > > > > points:) > > > > > > > > > > > > > > > > C0: Docker Image > > > > > > > > - There was a mis-understanding that the docker image like ci-gpu > > > > > > > > contains tvm. They do not, and instead contain an environment to > > > > > > > > build and run test cases. > > > > > > > > - The thirdparty binary cache is used to speed up the test build. > Anyone > > > > > > > > could build these binaries from a TVM source. > > > > > > > > - To avoid confusion about the branding, we have renamed the docker hub > > > > > > > > name to > > > > > > > > a different name that does not contain tvm so that it is clear as a > > > > > > > > thirdparty. > > > > > > > > > > > > > > > > C1: Pointing to Apache Release > > > > > > > > - The PPMC 100% agree that we should produce high-quality Apache > > > > > > > > compatible releases, and refer to them in the documents. > > > > > > > > - The installation documentation points to the official release > download > > > > > > > > page [1]. > > > > > > > > - There is a for developer section, which gives instructions to > > > developers > > > > > > > > about > > > > > > > > how to clone the code from the git repo. > > > > > > > > > > > > > > > > C2: Number of releases > > > > > > > > - The PPMC wants to produce high quality releases according to feature > > > > > > > > plan coordinated with the community, rather than creating more > > > releases. > > > > > > > > - The release process is well documented[2], > > > > > > > > - Per incubator policy[2], number of releases is not a hard bar for > > > > > > > > graduation. > > > > > > > > "Podlings do not need to actually publish a release...". Instead the > > > most > > > > > > > > important > > > > > > > > thing is the demonstration of being able to cut apache release. > > > > > > > > - Besides the release process being well documented and there are > already > > > > > > > > two high-quality releases(without WIP). The PMC contains several > Apache > > > > > > > > members > > > > > > > > who have previous experiences in cutting releases in TLP projects. > > > > > > > > We are very confident that the PMC can continue to do so. > > > > > > > > > > > > > > > > C3: The discourse forum > > > > > > > > - The discourse for
Re: [DISCUSS] Apache TVM Graduation
; - [1] > > https://tvm.apache.org/docs/install/from_source.html#install-from-source > > - [2] https://incubator.apache.org/guides/graduation.html > > - [3] > > > https://lists.apache.org/thread.html/c34b728f01d1030146594e47e0706cd1990ed731d06e3c179b7d501a%40%3Cdev.tvm.apache.org%3E > > - [4] https://www.apache.org/theapacheway/ > > > > On Fri, Aug 28, 2020 at 5:15 PM Henry Saputra > > wrote: > > > > > Sure, that is easy to fix and good suggestion. But, hope it is not a > > > blocker issue. > > > > > > On Fri, Aug 28, 2020, 5:09 PM Justin Mclean > > > wrote: > > > > > > > Hi, > > > > > > > > The "install from source” page should probably point people to the > source > > > > releases rather than the latest code in GitHub. > > > > > > > > Thanks, > > > > Justin > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > -- Matt Sicker
Re: Giving our PMs and contributors triage rights on GitHub
s part of the ethics of “fiduciary responsibility” taught at business > > > school; many PMs see themselves as potential officers of their company > > > someday, and act accordingly. > > > > > > > > > > Again just to reiterate. It's the same with engineers/developers. Most of > > > them can do this, but a few cannot. I see no reason whatsoever why > > > "business" people would be inferior here. It's all matter of personal > > > integrity in my opinion, not the role people have in organisation. > > > > > > > Also beware establishing this model in a project where a majority of > > > committers are employed by one company. The business people at such a > > > company, even if they are entirely invisible on the dev list, have huge > > > influence over the project by what development efforts they choose to > fund, > > > and how much time they give committers to review patches from outside the > > > organization. > > > > > > True - but those kind of projects are already in a bad shape. I think if > > > that's the case, the company (not business people!) has already enough > > > influence on the project. And again - I do not feel comfortable with > > > "business people" from the company being inferior than "developers". So > for > > > me this whole point is rather superficial. > > > > > > > Julian > > > > > > > > > > > > > > > > > On Aug 13, 2020, at 9:27 AM, Maxime Beauchemin < > > > maximebeauche...@gmail.com> wrote: > > > > > > > > > > xposting from d...@superset.apache.org - what's the right place to > > > post this > > > > > for ASF-infra's attention? > > > > > > > > > > --- > > > > > > > > > > Hi all, > > > > > > > > > > It just came to my attention that GitHub added a new "triage" access > > > level > > > > > at the repo level. > > > > > > > > https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/ > > > > > > > > > > In the past, we've identified that it was impossible for > non-committers > > > > > (especially our PMs and contributors-that-are-not-yet-committers) to > > > help > > > > > us triage issues, apply labels, assign reviews, close and reopen > > > issues as > > > > > needed. It's really clear to me that we really need all the help we > > > can get > > > > > in this area, and that not being able to involve more people into > this > > > > > process hurts us, and is a clear operational downside of using the > ASF > > > > > infra. > > > > > > > > > > More technically, I think the way to make that easy and painless > would > > > be > > > > > to add a new entry to the `.asf.yaml` file that would enable > > > maintainers to > > > > > assign the "triage" role to whoever they see fit. For reference, > here's > > > > > more context on that piece of automation I'd like to latch this onto > > > here: > > > > > > > > > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features > > > > > > > > > > Max > > > > > > > > > > > > - > > > > 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 > > > > > > > > -- Matt Sicker
Re: Problems with Committer Invite Documentation
t;>> let us know in reply to the [priv...@project.apache.org] > >>>>> address only. > >>>>> > >>>>> This is a potential disaster, since the candidate will not have read or > >>>> write privileges to the private mail list, the candidate's reply will > >>>> simply disappear into the bit-bucket! I would recommend changing this > >>>> paragraph to: > >>>> > >>>> A. Please reply directly to me if you wish to accept (or not accept) > >> this > >>>>> invitation. > >>>> > >>>> > >>> No. Why do you think it will disappear into the "bit-bucket"? The > >>> candidate would have the email in their inbox and would be able to > >> archive > >>> it/save it for reference however they choose fit. private mailing lists > >>> may have moderation in place, but since it's a legitimate email the > >>> moderators of the list should moderate it through if it does get > >>> moderated. The acceptance should also be on the podling's private list > >> to > >>> allow the ASF to have a permanent record of the acceptance. > >> > >> I have moderated numerous such requests in the past. Usually within 24 > >> hours, but occasionally within 104 hours. > >> > >> I have a Smart Mail filter to make sure that I see all moderation emails > >> even though the vast majority are spam. > >> > >>> > >>> > >>>> > >>>> Presumably the person sending this message will be someone from the PMC > >> / > >>>> PPMC that the candidate already has had some contact with. Also, > >> hopefully, > >>>> the sender has enough good sense to not CC non-private mail lists or > >> other > >>>> people on the invite, which will make the exchange as private as > >> possible. > >>>> > >>>> > >>> Yes, the person sending the invite needs to be on the PMC/PPMC. > >> Typically > >>> this is done by whoever actually did the nomination but there is no > >> formal > >>> rule about who must or must not send it (in some TLPs I think they expect > >>> the chair to do it, podlings don't have chairs). > >> > >> Typically a response is required in 30 days and the PPMC and Mentors will > >> need to track the result. > >> > >> Sometimes a nominee has to ask their company if they can sign an ICLA and > >> not every one can. > >> > >> Regards, > >> Dave > >> > >>> > >>> > >>>> > >>>> > >>>> - The next problem is the wording of the first sentence of the > >>>> 2nd paragraph: > >>>> > >>>> Being a committer enables you to more easily make > >>>>> changes without needing to go through the patch > >>>>> submission process. > >>>>> > >>>>> > >>>> This is basically recommending bad programming practice! We encourage > >> all > >>>> our committers to use the PR and review process on all but the most > >> trivial > >>>> commits (e.g., documentation typos). I would recommend simplifying this > >>>> sentence to: > >>>> > >>>> Being a committer grants you write access to the project repositories. > >>>> > >>>> > >>>> > >>> That's a fair point, but not all projects follow this pattern. In > >>> addition, the template is free to be modified by each project, you're > >> under > >>> no obligation to follow the published format verbatim; so if your project > >>> chooses to invite someone and wants to reword the text you can. > >>> > >>> > >>>> > >>>> > >>>> - This next issue is somewhat a matter of style, but I would recommend > >>>> replacing the entire section "B" with: > >>>> > >>>> B. If you accept, you will receive a follow-up message with the next > >> steps > >>>>> for establishing you as a committer. > >>>> > >>>> > >>>> > >>>> The above changes will make the invite letter simpler and more > >>>> straightforward. > >>>> > >>>> > >>> Once you've invited the person to be a committer, they should be able to > >>> submit the ICLA on their own. Someone on the PMC/PPMC shouldn't need to > >>> tell them how to do it, but the instructions included in B are pretty > >> clear > >>> and help that committer figure out how to submit the forms as needed. > >>> > >>> > >>>> I would be happy to submit these changes as a PR but someone will have > >> to > >>>> tell me where to do this. > >>>> > >>>> Cheers, > >>>> > >>>> Lee. > >>>> > >> > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Rainbow into Apache Incubator
Ooh, and that allows you to make puns like subliminal and superliminal messaging. Sounds cool! On Wed, 6 May 2020 at 04:06, lior.schachter wrote: > > Hi all, > We have decided on a new name for the project - *Liminal*. > lim·i·nal > /ˈlimənl/ > adjective > 1.relating to a transitional or initial stage of a process. > 2.occupying a position at, or on both sides of, a boundary or threshold. > > Please let us know if we can proceed with the voting process with this name. > > Lior & the Liminal Team :) > > --- > Following the results we have found in Github & Trademarkia on this name: > > I. GitHub search: > https://github.com/search?o=desc=in%3Aname+liminal=stars=Repositories > Total of 102 repositories. Below is a list of notable repositories : > > 1. psibr/LiminalityPowerful idiomatic state machines for .NET 8 C#. 8 > stars. Updated 13 days ago > 2. jonathanlilly/liminalA theme for scientific presentations using > Remark.js 5 HTML. 5 stars. Updated on Jan 9 > 3. rohailahmedkhan/LiminalVR-TribeSIT764/SIT782 3 C#. 3 stars. Updated on > May 26, 2019 > 4. sa-lee/liminal 3 R. 8 stars. Updated yesterday. > The goal of liminal is to provide diganostics and visual analytics for > understanding embedding algorithms such as tSNE > > II. Trademark > search:https://www.trademarkia.com/trademarks-search.aspx?tn=liminal > 11 active entries. > > > > -- > Sent from: http://apache-incubator-general.996316.n3.nabble.com/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Consultation]Some questions about incubation steps
Software grants and other legal paperwork aren’t required until the project has been voted to join the Incubator. On Wed, Mar 4, 2020 at 04:10 wrote: > Hi, Wu Sheng, > > Thank you for your quick reply and kind help. > > The source code of the HBlock project all comes from the contributions of > regular employees of our company. > There has been no open source project and no community of us before. > > In addition, at what point do we have to open all the source code? When do > we need to sign any agreement with Apache / IPMC? > > Regards. > Guochen. > > -邮件原件- > 发件人: Sheng Wu > 发送时间: 2020年3月4日 17:29 > 收件人: general@incubator.apache.org > 主题: Re: [Consultation]Some questions about incubation steps > > Hi Guochen > Answer inline. > > > 于2020年3月4日周三 下午5:16写道： > > > Hi, all, > > > > I am a new man here. Nice to see you. > > > > We are China Telecom Corporation Limited Cloud Computing Branch > > Corporation. We hope to contribute one of our projects name 'HBlock' > > to Apache. > > Now we hope to get into the incubation steps. > > > > We have prepare a proposal for this project, and before we propose it > > to the this mailing list, would you please let me know: > > 1. How long usually it takes from we propose it to the vote step? > > > > Vote process usually started by your mentor or champion, which should be > an incubator PMC member. > > > > 2. During this process, do we need to provide any source code relate > > to the project? > > > > Usually yes, could you explain a little about the context of this question? > In the incubator, we usually expect at least a small community established > already. So if there is not open source yet, then all members should only > come from your company internal. The IPMC and potential mentors only could > read your proposal. > > > > 3. During this process, do we need to add more members of this project > > to this mail list to answer questions from the incubator professors or > > only an interface person is enough? > > > > Before the vote, that is up to you. But during the incubating(if vote > pass), discussion and decision should be made in the mail list, your > project ml mostly. > > > > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > > > > Best wishes. > > Guochen. > > > > > > > > - > > 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 > > -- Matt Sicker
Re: [VOTE] Accept NuttX into the Apache Incubator
+1 On Wed, 4 Dec 2019 at 09:32, Xiang Xiao wrote: > > +1 (non-binding) > > Thanks > Xiang > > On Wed, Dec 4, 2019 at 9:40 PM Michael Wall wrote: > > > > +1 binding > > > > Interesting project and interested to watch how this progresses. If you > > need more mentor, I am happy to help. > > > > Mike > > > > On Wed, Dec 4, 2019 at 7:48 AM Bertrand Delacretaz < > > bdelacre...@codeconsult.ch> wrote: > > > > > On Wed, Dec 4, 2019 at 6:30 AM 俊平堵 wrote: > > > > ...I would like to call a VOTE to accept NuttX into the > > > > Apache Incubator... > > > > > > Enthusiastic +1 (binding) > > > > > > -Bertrand > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > ----- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept TubeMQ into the Apache Incubator
ttps://github.com/spring-projects/spring-framework > > > > spring-orm4.1.6.RELEASE > > > > https://github.com/spring-projects/spring-framework > > > > servlet-api2.5 > > > > http://central.maven.org/maven2/org/mortbay/jetty/servlet-api > > > > jackson-mapper-asl 1.9.13 > > > > http://www.java2s.com/Code/JarDownload/jackson-mapper > > > > Metamorphosis metamorphosis-all-1.4.4 > > > > https://github.com/killme2008/Metamorphosis > > > > > > > > > > > > ==External dependencies licensed under the MIT License== > > > > > > > > datatables 1.10.7 > > > https://github.com/DataTables/DataTables > > > > JustWriting 1.0.0 > > > https://github.com/GingJan/JustWriting > > > > jquery 1.11.3 > > > https://github.com/jquery/jquery > > > > slf4j 1.6.2 > > > https://github.com/qos-ch/slf4j > > > > mockito 2.0.2-beta https://github.com/mockito/mockito > > > > > > > > ==External dependencies licensed under the New BSD License== > > > > > > > > protobuf 2.5.0 > > > https://github.com/google/protobuf > > > > > > > > ==External dependencies licensed under the Eclipse Public License > 1.0== > > > > > > > > junit 4.11 > > > > https://github.com/junit-team/junit4 > > > > > > > > ==Cryptography== > > > > > > > > Not applicable. > > > > > > > > > > > > =Initial Committers= > > > > > > > > Goson Zhang > > > > Guangxu Cheng gxch...@apache.org > > > > Jerry Shao js...@apache.org > > > > Jie Jiang > > > > Junjie Chen > > > > Junping Du junping...@apache.org > > > > Kayne Wu > > > > Lamber Liu > > > > Osgoo Li > > > > Peng Chen > > > > Sijie Guo > > > > Xiang Li xian...@apache.org > > > > Yiheng Wang > > > > Yuhong Liu > > > > Zak Wu > > > > Zili Chen ti...@apache.org > > > > > > > > =Sponsors= > > > > > > > > Champion and mentor: David Nalley ke4...@apache.org (ASF Member, > > > Incubator PMC) > > > > Mentors: Junping Du junpin...@apache.org (ASF Member, Incubator PMC) > > > > Justin Mclain jmcl...@apache.org (ASF Member, VP of > > > Incubator) > > > > Sijie Guo si...@apache.org (ASF Member, Incubator PMC) > > > > Zhijie Shen zjs...@apache.org (ASF Member, Incubator > > PMC) > > > > Jean-Baptiste Onofre jbono...@apache.org (ASF Member, > > > > Incubator PMC) > > > > > > > > =Sponsoring Entity= > > > > > > > > The Apache Incubator > > > > > > > > > > > > > > > > [1] > > > https://cwiki.apache.org/confluence/display/INCUBATOR/TubeMQ+Proposal > > > > - Side note that the wiki page has an informative graphic, which is > > > > not present in this email. > > > > > > > > - > > > > 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 > > > > > > -- > > Sheng Wu 吴晟 > > > > Apache SkyWalking > > Apache Incubator > > Apache ShardingSphere, ECharts, DolphinScheduler podlings > > Zipkin > > Twitter, wusheng1108 > > > -- Matt Sicker
Re: Omid and Tephra
https://svn.apache.org/repos/private/documents/grants/caskdata-tephra On Wed, 30 Oct 2019 at 15:16, Alan Gates wrote: > > Regarding SGAs, here's the JIRA for Omid: > https://issues.apache.org/jira/browse/OMID-2 > According to > https://svn.apache.org/repos/private/foundation/officers/grants.txt Cask > (original creators of Tephra) submitted a SGA for it and it's one file, but > I don't know where the referenced file is kept. > > Alan. > > On Wed, Oct 30, 2019 at 10:32 AM Alan Gates wrote: > > > Bertand, thanks for bringing this up. I'll chase those down. > > > > Alan. > > > > On Wed, Oct 30, 2019 at 8:46 AM Bertrand Delacretaz < > > bdelacre...@codeconsult.ch> wrote: > > > >> Hi, > >> > >> On Wed, Oct 30, 2019 at 3:55 PM Josh Elser wrote: > >> > ...My current expectation is that we'd just rename the existing Git > >> > repositories and change the LDAP group which are used to determine write > >> > access... > >> > >> From the Incubator's point of view, I think an additional step is to > >> confirm and document if any Software Grants were needed for these > >> projects code and if yes if they've been filed as needed. > >> > >> This can be just a jira or other ticket documenting the move and > >> including this info. > >> > >> -Bertrand > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] TubeMQ Proposal
Kafka is one of the most well known Apache projects right now; I don’t think that’s a fair comparison. On Mon, Oct 21, 2019 at 10:07, Sheng Wu wrote: > Hi > > I don't see the competition among different MQ solutions is an issue. This > happens among all OSS projects, inside or outside ASF. > We are using the Apache Way to help the project to build the community. > If(only if) it is not better than Kafka in all fields(an assumption only), > it will/could end with a lack of contributors/committers. But this should > not be a block for starting the incubating process. > > Sheng Wu 吴晟 > > Apache SkyWalking > Apache Incubator > Apache ShardingSphere, ECharts, DolphinScheduler podlings > Zipkin > Twitter, wusheng1108 > > > Justin Mclean 于2019年10月21日周一 下午5:31写道： > > > Hi, > > > > > The first one is if we are able to mentor the project well enough (old > > discussion). > > > > You might be right about that the project currently I believe there's > only > > one mentor with recent mentoring experience, and while all proposed are > ASF > > members, not all of them are active on the IPMC general list. It might be > > better for the project to have at least one other mentor with executive > and > > is more active in the IPMC. What do others think? > > > > > As the project comes from Tencent I assume that the community is mostly > > Chinese and due to the language barrier (and probably a different > culture) > > we have seen that these projects tend to be "more challenging" (this does > > not describe it accurate enough but I hope that readers understand what I > > mean). > > > > While projects in this group do have some challenges, I don’t believe > it’s > > anymore than other projects from different background. In some ways the > ASF > > model is a good cultural fit - see Sharan’s thesis on that. > > > > Thanks, > > Justin > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > -- Matt Sicker
Re: [PROPOSAL] sparklyr
A lot of core R libraries seem to be under GPL. If we build more R projects at Apache, it seems like we may need more Apache-licensed (or compatible) libraries in R. On Mon, 21 Oct 2019 at 03:12, Justin Mclean wrote: > > Hi, > > I also concerned that the initial committer list only contains 3 committers. > Why have you not included others in the community that have made > contributions? > > I don’t know if this is an issue or not but bring it up just in case you not > aware. I can see that some of the tidyverse packages are under GPL2, the GPL > license is not compatible with the ALv2. I’m not 100% sure what license dplyr > is under. I can see that sparkly depends on several (10+) GPL licensed pieces > of software. Do you see this causing any issue as GPL code can’t be included > in an Apache source release and can’t be a non-optional dependancy of an ASF > project. Have you discussed this with your champion or proposed mentors and > have they flagged this as a possible issue? > > I can see that one of the proposed mentors is not an IPMC member (which is > required) and another seems not very active in signing off reports or voting > on releases. Did you think the existing mentors will provide your project > with enough support? > > Thanks, > Justin > > 1. https://github.com/tidyverse/dplyr/blob/master/LICENSE > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters
Secretary received both a CCLA and software grant for this. All docs are fine. On Wed, Oct 16, 2019 at 12:20, 申远 wrote: > + 1 > > Much better. > > Take your time and no need to hurry, you have 72 hours after. > > Eric Barboni 于2019年10月17日 周四00:16写道： > > > Maybe I should had sentence like that: > > > > Identify name recorded for software grant: Dukehoff GmbH > > And transmitted to the pmc via this link > > > > > https://lists.apache.org/thread.html/5fb0512323d0e12725141d68eb65f6affa8d99d8025c7ea0bd345474@%3Cprivate.netbeans.apache.org%3E > > > > Best Regards > > Eric > > PS > > No time today to regenerate the form, will append ASAP if that's what is > > needed > > > > -Message d'origine- > > De : 申远 > > Envoyé : mercredi 16 octobre 2019 14:16 > > À : general@incubator.apache.org > > Objet : Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters > > > > > > > > Dukehoff GmbH Anton Epple is the inceptor of thoose utilities and > > > employee of Dukehoff GmbH > > > > > > Does this mean the company of Dukehoff GmbH hold the IP and do we need > SGA > > here? > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > York Shen 于2019年10月16日周三 下午7:06写道： > > > > > If my memory was right, you could disclose the link of your reception > > > as individuals without the proper right will not be able to open the > > link. > > > Everything is safe. > > > > > > Correct me if I am wrong. > > > > > > Best Regards, > > > York Shen > > > > > > 申远 > > > > > > 2019年10月16日 18:52，Eric Barboni 写道： > > > > > > Hi > > > Not sure if I have to do something. > > > But secretary give us feedback on our private list for reception of > > files. > > > But should not be disclose I guess. > > > I have no access to secretary ml, so cannot help. > > > > > > Best Regards > > > Eric > > > -Message d'origine- > > > De : Matt Sicker > > > Envoyé : mercredi 16 octobre 2019 06:30 À : > > > general@incubator.apache.org Objet : Re: [IP CLEARANCE] Apache > > > NetBeans - dukescript presenters > > > > > > There should be an automatic email receipt of the secretary filing the > > doc. > > > > > > On Tue, Oct 15, 2019 at 23:02, 申远 wrote: > > > > > > Not sure SGA is required in this situation as it seems like there is > > > an employment in Dukehoff GmbH. > > > > > > FYI: Add the link about the communication with secretary would be a > > > great, which gives an individual to look into what's happening if > > > he/she has the privilege in secretary@asf mailing list. > > > > > > Best Regards, > > > YorkShen > > > > > > 申远 > > > > > > > > > Eric Barboni 于2019年10月15日周二 下午10:49写道： > > > > > > Hi community > > > > > > Apache NetBeans received a donation called dukescript presenters. > > > This donation goes in the Apache NetBeans html4j subproject. > > > > > > Form for ip clearance is here : > > > > > > > > > https://incubator.apache.org/ip-clearance/netbeans-dukescript-presente > > > rs.htm > > > > > > l > > > I had issue to regenerate the page please note that PR link is the > > > following > > > > > > https://github.com/apache/netbeans-html4j/pull/23 > > > Commit id if needed > > > > > > > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > > > 810c26 > > > > > > e7596fa0672d0 > > > < > > > > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > > > 810c26e7596fa0672d0 > > > > > > > > > > > > > > > Please vote to approve this contribution. Lazy consensus applies: If > > > no > > > > > > -1, > > > > > > votes are being cast within the next 72 hours, the vote passes. > > > > > > Best Regards > > > Eric > > > > > > > > > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > > - > > > 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 > > > > -- > Best Regards > York Shen > 申远 > -- Matt Sicker
Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters
There should be an automatic email receipt of the secretary filing the doc. On Tue, Oct 15, 2019 at 23:02, 申远 wrote: > Not sure SGA is required in this situation as it seems like there is an > employment in Dukehoff GmbH. > > FYI: Add the link about the communication with secretary would be a great, > which gives an individual to look into what's happening if he/she has the > privilege in secretary@asf mailing list. > > Best Regards, > YorkShen > > 申远 > > > Eric Barboni 于2019年10月15日周二 下午10:49写道： > > > Hi community > > > > Apache NetBeans received a donation called dukescript presenters. This > > donation goes in the Apache NetBeans html4j subproject. > > > > Form for ip clearance is here : > > > > > https://incubator.apache.org/ip-clearance/netbeans-dukescript-presenters.htm > > l > > I had issue to regenerate the page please note that PR link is the > > following > > > > https://github.com/apache/netbeans-html4j/pull/23 > > Commit id if needed > > > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1810c26 > > e7596fa0672d0 > > < > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1810c26e7596fa0672d0 > > > > > > > > Please vote to approve this contribution. Lazy consensus applies: If no > -1, > > votes are being cast within the next 72 hours, the vote passes. > > > > Best Regards > > Eric > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > -- Matt Sicker
Re: [MENTORS] Podling reporting groups
That’d make sense to me. On Sat, Oct 12, 2019 at 19:51, Justin Mclean wrote: > Hi, > > > MesaTEE > > As you missed your first report (as you’re just getting set up) I think it > would be best if you moved to group 1. Any objections? > > Thanks, > Justin > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [IP CLEARANCE] Apache Pulsar - Pulsar Manager
+1 On Wed, 11 Sep 2019 at 02:47, Sijie Guo wrote: > > Hi all, > > Apache Pulsar received a donation which adds a new web UI - Pulsar Manager > to Pulsar. Pulsar Manager is a web-based GUI management and monitoring tool > that helps > administrators and users manage and monitor tenants, namespaces, topics, > subscriptions, brokers, clusters, and so on, and supports dynamic > configuration of multiple environments. > > The IP clearance form can be found at: > http://incubator.apache.org/ip-clearance/pulsar-manager.html > > The contribution can be found at: > https://github.com/streamnative/pulsar-manager > The git repo will be transferred to apache at the end of the process. > > Please vote to approve this contribution. Lazy consensus applies: if no -1 > votes are being cast within the next 72 hours, the vote passes. > > Thanks, > Sijie -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance Process for Incubating projects
Don’t forget to file the forms with the secretary. On Mon, Sep 2, 2019 at 04:53, York Shen wrote: > > Just to be clear the ICLAs need to be be from all the contributors, not > just one person. > > Understood, that’s why I use plural form of ICLAs. > > I shall collected ICLAs/SGAs and send them to the mailing list by the end > of this weekend if everything is fine. But I’m confused about what I shall > do next to transfer those Git repo to ASF, maybe creating a JIRA issue to > INFRA? > > Best Regards, > York Shen > > 申远 > > > 在 2019年9月2日，17:43，Justin Mclean 写道： > > > > Just to be clear the ICLAs need to be be from all the contributors, not > just one person. > > -- Matt Sicker
Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin
I would think that if the person who submits the PR has the rights to make that contribution, then their ICLA should cover that. See https://www.apache.org/licenses/contributor-agreements.html for more info. On Wed, 21 Aug 2019 at 11:49, Roy Lenferink wrote: > > > Given it was already had a ASF license header and from a ASF project why > was IP clearance even needed? I assume the person involved has signed a > ICLA? > > The individual contributors all submitted an ICLA and a CCLA for the > company is already present. We were following IP clearance > because the written software was developed outside of the ASF version > control system (company internal VCS). After that, we squashed everything > into a single commit and submitted it as a PR to Celix. > > Would IP clearance be necessary in this case (duplication of an already > existing component)? Would IP clearance be necessary for new components > which already have ASF headers in place? -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin
Thales has been sending SGAs for all their Celix PRs lately. On Wed, 21 Aug 2019 at 05:35, Justin Mclean wrote: > > Hi, > > > The donation was developed by duplicating an existing Celix component > > (pubsub_admin_zmq)[1] to a new component (pubsub_admin_websocket)[2]. > > Then the contents of the files has been changed to use websockets instead > > of ZeroMQ. All this time the ASF header was kept in place. > > > Given it was already had a ASF license header and from a ASF project why was > IP clearance even needed? I assume the person involved has signed a ICLA? > > Thanks, > Justin > > 1. https://github.com/apache/celix/blob/master/NOTICE > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin
+1 On Tue, 20 Aug 2019 at 00:39, Furkan KAMACI wrote: > > Hi, > > +1 > > Kind Regards, > Furkan KAMACI > > 20 Ağu 2019 Sal, saat 08:04 tarihinde Roy Lenferink > şunu yazdı: > > > Hi all, > > > > Apache Celix received a donation which adds an additional pubsub admin > > to Celix. This pubsub admin uses websockets as communication technique > > and can be used next to the existing ZeroMQ, TCP or UDP multicast pubsub > > admins. No new third party dependencies are added. > > > > The IP clearance form can be found at: > > http://incubator.apache.org/ip-clearance/celix-pubsub-admin-websocket.html > > > > The pull request containing the donation can be found at: > > https://github.com/apache/celix/pull/39 > > > > Please vote to approve this contribution. Lazy consensus applies: > > if no -1 votes are being cast within the next 72 hours, the vote passes. > > > > Greetings, > > Roy > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept MesaTEE into Apache Incubator
/Apache-2.0 > > * image, 0.21.0, MIT > > * inflate, 0.4.5, MIT > > * inventory, 0.1.3, MIT > > * inventory-impl, 0.1.3, MIT > > * iovec, 0.2.0, MIT/Apache-2.0 > > * itertools, 0.8.0, MIT/Apache-2.0 > > * itoa, 0.4.4, MIT > > * jpeg-decoder, 0.1.15, MIT > > * lazy_static, 1.3.0, MIT/Apache-2.0 > > * libc, 0.2.59, MIT > > * linked-hash-map, 0.5.2, MIT/Apache-2.0 > > * log, 0.4.7, MIT > > * lzw, 0.10.0, MIT/Apache-2.0 > > * matrixmultiply, 0.2.2, MIT/Apache-2.0 > > * md5, 0.6.1, Apache-2.0/MIT > > * memchr, 2.2.1, Unlicense/MIT > > * memory_units, 0.3.0, MPL-2.0 > > * net2, 0.2.33, MIT/Apache-2.0 > > * num, 0.2.0, MIT/Apache-2.0 > > * num-bigint, 0.2.2, MIT/Apache-2.0 > > * num-complex, 0.2.3, MIT/Apache-2.0 > > * num-integer, 0.1.41, MIT/Apache-2.0 > > * num-iter, 0.1.39, MIT/Apache-2.0 > > * num-rational, 0.2.2, MIT/Apache-2.0 > > * num-traits, 0.2.8, MIT/Apache-2.0 > > * parity-wasm, 0.31.3, MIT/Apache-2.0 > > * png, 0.14.1, MIT/Apache-2.0 > > * proc-macro2, 0.4.30, MIT/Apache-2.0 > > * profiler_builtins, 0.1.0, profiler_builtins > > * quick-error, 1.2.2, MIT/Apache-2.0 > > * quote, 0.3.15, MIT > > * quote, 0.6.13, MIT > > * rand, 0.6.5, MIT/Apache-2.0 > > * rand_core, 0.4.0, MIT/Apache-2.0 > > * rand_hc, 0.1.0, MIT/Apache-2.0 > > * rand_pcg, 0.1.2, MIT/Apache-2.0 > > * rawpointer, 0.1.0, MIT/Apache-2.0 > > * regex, 1.1.9, MIT/Apache-2.0 > > * regex-syntax, 0.6.8, MIT/Apache-2.0 > > * ring, 0.14.6, ISC-style > > * rulinalg, 0.4.2, MIT > > * rustls, 0.15.2, Apache-2.0/ISC/MIT > > * rusty-machine, 0.5.4, MIT > > * ryu, 1.0.0, Apache-2.0 > > * sct, 0.5.0, Apache-2.0/ISC/MIT > > * serde, 1.0.94, MIT > > * serde_cbor, 0.10.0, MIT/Apache-2.0 > > * serde_derive, 1.0.94, MIT > > * serde_json, 1.0.40, MIT > > * sha1, 0.6.0, BSD-3-Clause > > * sha2, 0.8.0, sha2 > > * spin, 0.5.0, MIT > > * syn, 0.11.11, MIT > > * syn, 0.15.39, MIT > > * synom, 0.11.3, MIT/Apache-2.0 > > * termcolor, 1.0.5, Unlicense > > * thread_local, 0.3.6, Apache-2.0/MIT > > * tiff, 0.3.1, MIT > > * toml, 0.5.1, MIT/Apache-2.0 > > * typetag, 0.1.3, MIT > > * typetag-impl, 0.1.3, MIT > > * ucd-util, 0.1.3, MIT/Apache-2.0 > > * unicode-xid, 0.0.4, MIT/Apache-2.0 > > * unicode-xid, 0.1.0, MIT/Apache-2.0 > > * utf8-ranges, 1.0.3, Unlicense/MIT > > * uuid, 0.7.4, Apache-2.0 > > * wabt, 0.6.0, Apache-2.0 > > * wasmi, 0.5.0, MIT/Apache-2.0 > > * wasmi-validation, 0.1.0, MIT/Apache-2.0 > > * webpki, 0.19.1, ISC-style > > * webpki-roots, 0.16.0, MPL-2.0 > > * winapi, 0.3.7, MIT/Apache-2.0 > > * winapi-i686-pc-windows-gnu, 0.4.0, MIT/Apache-2.0 > > * winapi-util, 0.1.2, Unlicense/MIT > > * winapi-x86_64-pc-windows-gnu, 0.4.0, MIT/Apache-2.0 > > * wincolor, 1.0.1, Unlicense/MIT > > * yasna, 0.3.1, MIT/Apache-2.0 > > > > Note that this is not an exhaustive dependency list and only direct > > dependencies > > of MesaTEE's trusted libs are included. > > > > == Cryptography == > > > > MesaTEE uses following cryptographic libraries: > > > > * ring (https://github.com/briansmith/ring): a Rust crypto library > > based on BoringSSL > > * rustls: a Rust TLS library > > * sgx_tcrypto in Intel SGX SDK ( > https://software.intel.com/en-us/sgx/sdk) > > > > = Required Resources = > > > > == Mailing lists == > > > > * priv...@mesatee.incubator.apache.org (with moderated subscriptions) > > * d...@mesatee.incubator.apache.org > > * comm...@mesatee.incubator.apache.org > > * u...@mesatee.incubator.apache.org > > > > == Git Repositories == > > > > Upon entering incubation, we want to transfer the existing repos from > > https://github.com/mesalock-linux/mesatee and > > https://github.com/baidu/rust-sgx-sdk to Apache organization in GitHub > like: > > > > * https://github.com/apache/incubator-mesatee > > * https://github.com/apache/incubator-mesatee-rust-sgx-sdk > > > > == Issue Tracking == > > > > MesaTEE currently uses GitHub to track issues. Would like to continue > doing > > so. > > > > == Continuous Integration Service == > > > > MesaTEE currently uses self-hosted continuous integration (CI) service > > which can > > help developers to automatically test commits. The CI service involves > > several > > nodes which support Intel SGX. We would like to continue doing so. > > > > = Initial Committers = > > > > The list is sorted alphabetically: > > > > * Mingshen Sun > > * Pei Wang > > * Rundong Zhou > > * Tao Wei > > * Tongxin Li > > * Yiming Jing > > * Yu Ding > > * Yulong Zhang > > * Zhaofeng Chen > > > > = Sponsors = > > > > == Champion == > > > > * Zhijie Shen > > > > == Nominated Mentors == > > > > * Jianyong Dai > > * Luciano Resende > > * Matt Sicker > > * Furkan Kamaci > > > > == Sponsoring Entity == > > > > The Incubator PMC > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Recommend 'Apache Druid graduation to Top Level Project' resolution to the board
+1, sounds great! On Tue, Aug 13, 2019 at 04:58, Justin Mclean wrote: > Hi, > > +1 good luck on your journey! > > Thanks, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] IPMC votes on releases
This observer IPMC role sounds interesting. That would make it less intimidating for people who can help verify a generic release but are unfamiliar with the domain itself. On Mon, Aug 12, 2019 at 03:37, Julian Feinauer wrote: > Hi, > > I'm answering to this (old) thread as the new one branched up with a > different topic. > Personally, during my time in the first podling I learned a lot by doing > Apache Releases. > First, as contributor, then as PPMC and finally as RM. > And this is something valuable and if a project wants to become a TLP > something people have to learn. > And not only one or two but better every PPMC member (and some even able > to RM). > > So I suggest to encourage Podlings as much as possible to to ASF releases. > I would suggest to solve all the current issues by setting the rules up in > a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC > Vote which are then carried over and make the IPMC Vote basically "lazy > consensus". > > To do this I would suggest to set up / change the "Mentor Guideline" that > a Mentor "should" vote on PPMC releases. > Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 > "assessors" or "observers" (from the IPMC) who do not help actively but are > on the list and whos dutie is to support Releases. > That would make a pool of 5-6 IPMC members for each podling which should > be encouraged to VOTE on releases. > > Then, we could, step by step, tackle podlings to bring their Vote to the > IPMC only if they have 3 +1 votes. > > This would allow us to keep all global rules of the ASF as is and only > change Incubator "internals". > I think we should really start to see Mentoring as something which needs > time and work and which people should only call in if they feel like they > can do. > For everything else we could have this "observer" role where people that > find the project interesting could simply take to watch and monitor it but > with their Votes also help the incubator a lot. > > Julian > > Am 12.08.19, 02:46 schrieb "Greg Stein" : > > On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean < > jus...@classsoftware.com> > wrote: > > > Hi, > > > > > I see no problem with using our infrastructure to distribute F/OSS > > > materials. Why would the Foundation want to be against that? If it > is > > > labeled properly, then ... roll with it. > > > > It often isn’t labelled properly. There’s a reasonable risk that > some of > > what would be placed there and distributed isn’t actually F/OSS. > > > And what would be the blowback of something on our server with > incorrect > information? Very little. Mostly, we'd just move on. Maybe we delete > it. > > > > I can point you to several example of this. I’m not sure how the > incubator > > (or the board) would feel about that risk, so that would be > something we > > would be need to consider further. Also > > > Welp. Then I will pose that question, rather than this endless > pontificating about "risk". > > > > while Jane and John may be fine with that, a lot of companies that > use > > Apache releases may not be. > > > > I already acknowledged that. Many people could use software regardless > of > its licensing. The license typically only matters in *redistribution* > scenarios. Things like the AGPL affect *usage*, but that is very, very > atypical. I'd think 99% of downstream could use our software, even with > gummed-up licensing. > > > > > You're conflating *learning* with *releases*. These can be handled > > separately. > > > > How exactly? > > > You're saying that releases are the control point to learning. I say > just > let the releases go. > > You want to teach? Then you can use the releases like "that wasn't > good. > next time: do A and B". Over time, releases will get fixed. But the > IPMC > should not have to manage the releases. > > Cheers, > -g > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
We were handling votes like that in OpenWhisk up until graduation. Mentor votes carry over to the IPMC vote. On Mon, Aug 12, 2019 at 07:20, Jim Jagielski wrote: > We have always had a mindset that we (the foundation) want to make it as > "brain dead easy" for people to download, use, and consume ASF projects. > This means that they don't need to worry about compliance, IP provenance, > etc. > > Incubator releases are a special case. The expectation is, and should be, > that these releases may have issues. In fact, it is quite likely they will. > Again, as long as those downloading these releases are aware of that, and > we've done all we could to ensure that they are aware of it, then we have > satisfied our requirements. IMO, with the naming and the DISCLAIMER and > other such touches, we are achieving that. > > And they are, in fact, *releases*. We need to recall that one function of > the foundation, and PMCs, is to provide legal protection to those who are > creating the software artifacts, and when a release is done, as a "formal" > act of the foundation (via the PMC), it is when they legal coverage is at > its most clear and explicit. So in order for those within the podling to > enjoy the legal protection this foundation exists to provide, these do need > to be releases. I would be opposed to not providing such coverage for those > in our podlings, since they should be safe spaces to learn about the Apache > Way and how to build communities and how to release software. > > This does NOT mean that the IPMC should be gatekeepers though... Just as > PMC chairs are the "eyes and ears of the board", mentors are the "eyes and > ears of the IPMC". The IPMC "vote" should be little more than a formality. > IMO, if mentors are IPMC members, and there are at least 3 binding votes on > the podling list, and the mentors are acting as IPMC members when they > vote, then any other additional vote in the IPMC is not required... in > essence, consider it like extending the vote for a lazy consensus, so to > speak: > > >"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and > pointers here). We have 3 (or more) binding votes from mentors. We are > giving the IPMC and additional 72 hours to vote on said release." > > Comments? > --------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] Incubation Proposal of MesaTEE
I’d most likely be interested in mentoring this project, but I’m not that experienced in incubator mentorship. If we have another more experienced mentor to work with us, I’d be happy to mentor as well. On Sat, Aug 10, 2019 at 04:13, Mingshen Sun wrote: > Thanks Justin, regarding to your questions: > > On Thu, Aug 8, 2019 at 2:46 AM Justin Mclean > wrote: > > > > Hi, > > > > Thanks for the proposal, it sound like a really interesting project. > > > > > == Core Developers == > > > > > > Current core developers work at Baidu. We are confident that > incubation will > > > help us grow a diverse community in an open and collaborative way. > > > > > > The risk of abandonment of MesaTEE is low. MesaTEE has been incubated > at Baidu > > > for over two years. Baidu is committed to the further development of > the project > > > and will keep investing resources towards the Apache processes and > community > > > building, during the incubation period. > > > > Incubation can sometimes take 2 years or more. Given few people with > experience at Apache are involved with this project and the core developers > are from one company, it may take longer that indicated in this proposal. > > We understand the incubation could take 2 years or more. Recently, we > have already received some pull requests from third-parties. > Therefore, during the incubation period, we will try to > attract/involved engineers from other companies as constant > committers. > > > > > > == Continuous Integration Service == > > > > > > MesaTEE currently uses self-hosted continuous integration (CI) service > which can > > > help developers to automatically test commits. The CI service involves > several > > > nodes which support Intel SGX. We would like to continue doing so. > > > > This may not be possible, what would the project do if that was the > case? Have you discussed this with your proposed mentors or infra? > > About the CI infrastructure, actually, the "self-hosted CI" is not our > internal infra, we are using a open source CI service (Drone CI) with > our servers/NUC with SGX supported. To answer your questions, we have > several solutions: > - we can use simulation mode for basic CI testing (by using existing > infra in Apache for example). And before merging a pull request, full > testing on a SGX supported machine is required > - donating our SGX machines for CI services to Apache is another > option we may consider, but this should be further discussed > > > > * Zhijie Shen > > > > Is not currently an IPMC member, only IPMC members can officially be > mentors. > > > > Of the three mentors listed 2 have never been mentors to my knowledge, > have they been involved with any other projects going through the > incubating process at Apache? The third mentor may be a little overextended > given the number of podlings they mentors. Having only one experienced > mentor may be a risk to the project. What will you do if your mentors go > missing or unable to help? > > I have talked with Zhijie Shen. He is very interested in helping us. > Currently, he is a member of incubator and can apply for IPMC. In > addition to Zhijie Shen, Jianyong Dai, and Luciano Resende, Furkan > Kamaci also volunteered to become one of our mentors after posting > this proposal in the mailing list. We understand this is a large > project and need experienced mentors. We are very open to include more > mentors who are interested in the project. > > - > Mingshen > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] Incubation Proposal of MesaTEE
I’ve read through a bit of the site and blog posts. I’m pretty interested in the project, especially any efforts to support more programming languages. Is it possible to use this to sandbox arbitrary code? On Sat, Aug 3, 2019 at 17:22, Mingshen Sun wrote: > Yes, this project can be used for securing general computations. > You can simply use the `mesatee_core` library to write an SGX encalve. > In addition, MesaTEE provides others features like function as a service. > That’s why we call it a universal securing computing framework. > > Best, > Mingshen Sun > > On 2019/08/03 15:27:41, Matt Sicker wrote: > > Would this project be useful in securing general computations? You > mention> > > big data and AI a lot, though I’m wondering if this is also usable for> > > things like, say, general multi tenant applications?> > > > > On Sat, Aug 3, 2019 at 03:27, Mingshen Sun > wrote:> > > > > > Hi,> > > >> > > > This is Mingshen Sun from Baidu X-Lab. Recently, we have open-sourced> > > > a universal secure computing framework called MesaTEE (> > > > https://mesatee.org/).> > > > The MesaTEE project enables general computing service for> > > > security-critical scenarios,> > > > which attracts many attentions from academia and industry.> > > >> > > > To better build up the whole ecosystem, we decide to donate the > MesaTEE> > > > project to> > > > Apache Foundation. Therefore, we’d like to propose our project to go> > > > through> > > > the incubation process.> > > >> > > > Attached is our incubation proposal for open discussion. Thank you so > much.> > > >> > > > Best,> > > > Mingshen Sun> > > > Baidu X-Lab> > > >> > > >> > > > Here is the proposal details:> > > >> > > > ==> > > >> > > > MesaTEE Apache Incubation Proposal> > > >> > > > = Abstract => > > >> > > > MesaTEE is a framework for universal secure computing.> > > >> > > > = Proposal => > > >> > > > MesaTEE is the next-gen solution to enable general computing service > for> > > > security-critical scenarios. It will allow even the most sensitive > data to> > > > be> > > > securely processed to enable offshore businesses without leakage.> > > >> > > > The solution combines the advanced Hybrid Memory Safety (HMS) model > and the> > > > power of the Trusted Computing technologies (e.g., TPM) as well as > the> > > > Confidential Computing technologies (e.g., Intel SGX).> > > >> > > > * Code base:> > > > * https://github.com/mesalock-linux/mesatee> > > > * https://github.com/baidu/rust-sgx-sdk> > > > * Website: https://mesatee.org> > > > * Documentation: https://mesatee.org/doc/mesatee_sdk/> > > >> > > > = Background => > > >> > > > The emerging technologies of big data analytics, machine learning,> > > > cloud/edge> > > > computing, and blockchain are significantly boosting our productivity, > but> > > > at> > > > the same time they are bringing new confidentiality and integrity> > > > concerns. On> > > > public cloud and blockchain, sensitive data like health and financial> > > > records> > > > may be consumed at runtime by untrusted computing processes running > on> > > > compromised platforms; during in-house data exchange, confidential> > > > information> > > > may cross different clearance boundaries and possibly fall into the > wrong> > > > hands;> > > > also not to mention the privacy issue arises in offshore data supply> > > > chains.> > > >> > > > Although the consequences of data breaching have been extensively> > > > elaborated, we> > > > should also note that proprietary computing algorithms themselves, > such as> > > > AI> > > > models, also need to be well protected. Once leaked, attackers can > steal> > > > the> > > > intellectual properties, or launch whitebox attacks and easily exploit > the> > > > weaknesses of the models.> > > >> > > > Facing all these risky scenarios, we are in desperate need of a > trusted and> > > > secure mechanism, enabling us to protect both private data and
Re: [DISCUSS] Incubation Proposal of MesaTEE
chine, 0.5.4, MIT > * ryu, 1.0.0, Apache-2.0 > * sct, 0.5.0, Apache-2.0/ISC/MIT > * serde, 1.0.94, MIT > * serde_cbor, 0.10.0, MIT/Apache-2.0 > * serde_derive, 1.0.94, MIT > * serde_json, 1.0.40, MIT > * sha1, 0.6.0, BSD-3-Clause > * sha2, 0.8.0, sha2 > * spin, 0.5.0, MIT > * syn, 0.11.11, MIT > * syn, 0.15.39, MIT > * synom, 0.11.3, MIT/Apache-2.0 > * termcolor, 1.0.5, Unlicense > * thread_local, 0.3.6, Apache-2.0/MIT > * tiff, 0.3.1, MIT > * toml, 0.5.1, MIT/Apache-2.0 > * typetag, 0.1.3, MIT > * typetag-impl, 0.1.3, MIT > * ucd-util, 0.1.3, MIT/Apache-2.0 > * unicode-xid, 0.0.4, MIT/Apache-2.0 > * unicode-xid, 0.1.0, MIT/Apache-2.0 > * utf8-ranges, 1.0.3, Unlicense/MIT > * uuid, 0.7.4, Apache-2.0 > * wabt, 0.6.0, Apache-2.0 > * wasmi, 0.5.0, MIT/Apache-2.0 > * wasmi-validation, 0.1.0, MIT/Apache-2.0 > * webpki, 0.19.1, ISC-style > * webpki-roots, 0.16.0, MPL-2.0 > * winapi, 0.3.7, MIT/Apache-2.0 > * winapi-i686-pc-windows-gnu, 0.4.0, MIT/Apache-2.0 > * winapi-util, 0.1.2, Unlicense/MIT > * winapi-x86_64-pc-windows-gnu, 0.4.0, MIT/Apache-2.0 > * wincolor, 1.0.1, Unlicense/MIT > * yasna, 0.3.1, MIT/Apache-2.0 > > Note that this is not an exhaustive dependency list and only direct > dependencies > of MesaTEE's trusted libs are included. > > == Cryptography == > > MesaTEE uses following cryptographic libraries: > > * ring (https://github.com/briansmith/ring): a Rust crypto library > based on BoringSSL > * rustls: a Rust TLS library > * sgx_tcrypto in Intel SGX SDK (https://software.intel.com/en-us/sgx/sdk > ) > > = Required Resources = > > == Mailing lists == > > * priv...@mesatee.incubator.apache.org (with moderated subscriptions) > * d...@mesatee.incubator.apache.org > * comm...@mesatee.incubator.apache.org > * u...@mesatee.incubator.apache.org > > == Git Repositories == > > Upon entering incubation, we want to transfer the existing repos from > https://github.com/mesalock-linux/mesatee and > https://github.com/baidu/rust-sgx-sdk to Apache organization in GitHub > like: > > * https://github.com/apache/incubator-mesatee > * https://github.com/apache/incubator-mesatee-rust-sgx-sdk > > == Issue Tracking == > > MesaTEE currently uses GitHub to track issues. Would like to continue > doing so. > > == Continuous Integration Service == > > MesaTEE currently uses self-hosted continuous integration (CI) service > which can > help developers to automatically test commits. The CI service involves > several > nodes which support Intel SGX. We would like to continue doing so. > > = Initial Committers = > > The list is sorted alphabetically: > > * Mingshen Sun > * Pei Wang > * Rundong Zhou > * Tao Wei > * Tongxin Li > * Yiming Jing > * Yu Ding > * Yulong Zhang > * Zhaofeng Chen > > = Sponsors = > > == Champion == > > * Zhijie Shen > > == Nominated Mentors == > > * Zhijie Shen > * Jianyong Dai > * Luciano Resende > > == Sponsoring Entity == > > The Incubator PMC > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: New disclaimer text
Agreed, this sounds like a great way to do this. As IPMC members reviewing releases, you now have better guidelines on how to go about reviewing a podling release. On Fri, Jul 12, 2019 at 17:59, Jim Jagielski wrote: > This is a great idea... +1 > > > On Jul 12, 2019, at 6:31 PM, Craig Russell wrote: > > > > Hi, > > > > I understand I'm a bit late to this particular discussion, but perhaps > we can consider two different disclaimers that podlings can choose: > > > > The standard disclaimer that does not disclaim licensing issues; or, > > > > The proposed new disclaimer to be used by podlings' first releases until > they sort their licensing issues > > > > This "split roll" allows "mature" podlings the ability to assuage their > downstream that they have their licensing issues in hand. > > > > Use of the current disclaimer means that any licensing issues found > during release voting would cancel the release and require a respin. > > > > Use of the proposed new disclaimer would allow new-ish podlings to get > on with releasing while they sort any licensing issues. > > > > And we can add to the Maturity Model a section that discusses that the > podling has had at least one release with the standard disclaimer. > > > > Regards, > > > > Craig > > > >> On Jul 10, 2019, at 2:44 PM, Justin Mclean > wrote: > >> > >> Hi, > >> > >>> Speaking as a member of a currently-incubating project (Apache Druid) > where > >>> we have always strived to do releases with no known licensing issues, > the > >>> text sounds needlessly scary to downstream consumers. > >> > >> And that may be the problem with a one solution fits all process. It > has been suggested before we let podlings choose which release process they > want. However that may get too complex and make voting on releases > inconsistent. > >> > >>> IMO this disclaims too much, and would chill adoption of incubating > >>> software by people that care about having clean licensing. PPMCs > should be > >>> able to say "we believe this release is clean and have vetted it using > a > >>> normal Apache vetting process" or maybe even "we have vetted this > release > >>> and it is clean other than the following list of known issues". If they > >>> can't say one of those two statements, then maybe it's not time to do > their > >>> first release yet. > >> > >> The idea is to allow podlings to make releases that may not comply with > policy. Have a hard switch from your releases doesn’t comply to everything > must comply is too difficult for some podlings. > >> > >>> And yeah, as a few others have mentioned, I believe that a more > streamlined > >>> voting process > >> > >> That I think is a different issue, ands may be best to start another > thread on that. The main issue here is that IPMC members votes are binding, > and not all mentors (who are IPMC members) vote on releases, so podlings > need votes from the wider IPMC members to make releases (in about 90%+ of > cases). There been a few ideas on how to improve this, including one > approved method (but no podlings have take that up yet). > >> > >> Thanks, > >> Justin > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > > > > Craig L Russell > > c...@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 > > -- Matt Sicker
Re: New disclaimer text
Since this is sort of a post-release set of info, I think it’d make sense to have either a page specific to each version, or at least a section per version all on a single page (similar to a security issues page might be or a change log in general). On Tue, Jul 9, 2019 at 21:24, Justin Mclean wrote: > Hi, > > The issue with having a detached disclaimer is that it can change and get > out of sync with what was actually in a released version. > > However one possible compromise would be to list known issues in the > disclaimer and list any other issues found by the IPMC in the release > announcements and on the release page next to the download links. The > DISCLAIMER in version control can also be updated and always reflect the > current set of released issues are. What do other people think about this? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: What is repo.maven.a.o for?
Whenever you make a release from a staging repo, it's published to that repo you linked (as well as Maven Central). That repo should reflect either https://repository.apache.org/content/repositories/releases/ or https://repository.apache.org/content/groups/public/ On Mon, 8 Jul 2019 at 14:44, leerho wrote: > > So far, I think I understand the Nexus repositories (snapshots, staging and > releases), and the dist.a.o and archive.a.o repositories. > > But what is https://repo.maven.apache.org/maven2/org/apache repository for > and how does it get updated? -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend 'Apache OpenWhisk graduation to Top Level Project' resolution to the board
+1 On Mon, 8 Jul 2019 at 10:14, David P Grove wrote: > > > > The Apache OpenWhisk podling community brings the resolution, after > discussion [1], to become a top level Apache project up for the IPMC vote. > The PPMC community vote [2] resulted in 19 +1 votes and no 0 or -1 votes. > Further details on how the community has developed during incubation are > summarized in the discussion thread [1]. > > This vote is open for 72 hours, assuming that at that stage there are at > least 3 +1 votes and nothing left open for discussion. > > Thanks, > > --dave > on behalf of the Apache OpenWhisk PPMC > > [1] > https://lists.apache.org/x/thread.html/ee66864bb39279833a19d9c4c5aa2f7d96463efdafc93594e7f32af1@%3Cgeneral.incubator.apache.org%3E > [2] > https://lists.apache.org/x/thread.html/ee66864bb39279833a19d9c4c5aa2f7d96463efdafc93594e7f32af1@%3Cgeneral.incubator.apache.org%3E > > - > > Establish the Apache OpenWhisk 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, for distribution at no charge to > the public, related to a platform for building serverless applications > with functions. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache OpenWhisk Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache OpenWhisk Project be and hereby is > responsible for the creation and maintenance of software related to a > platform for building serverless applications with functions; and be > it further > > RESOLVED, that the office of "Vice President, Apache OpenWhisk" 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 > OpenWhisk Project, and to have primary responsibility for management > of the projects within the scope of responsibility of the Apache > OpenWhisk 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 OpenWhisk > Project: > Bertrand Delacretaz, bdelacre...@apache.org > Carlos Santana, csantan...@apache.org > Chetan Mehrotra, chet...@apache.org > Dave Grove, dgr...@apache.org > Dominic Kim, styl...@apache.org > Dragos Dascalita Haut, dra...@apache.org > James Dubee, du...@apache.org > James Thomas, jamestho...@apache.org > Jeremias Werner, jeremiaswer...@apache.org > Krzysztof Sobkowiak, ksobkow...@apache.org > Markus Thömmes, markusthoem...@apache.org > Matt Rutkowski, mrutkow...@apache.org > Matt Sicker, mattsic...@apache.org > Michele Sciabarra, msciaba...@apache.org > Olivier Tardieu, tard...@apache.org > Rob Allen, akra...@apache.org > Rodric Rabbah, rab...@apache.org > Sven Lange-Last, sla...@apache.org > Tyson Norris, tysonnor...@apache.org > Vincent Hou, houshen...@apache.org > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dave Grove be appointed > to the office of Vice President, Apache OpenWhisk, to serve in > accordance with and subject to the direction of the Board of Directors > and the Bylaws of the Foundation until death, resignation, retirement, > removal or disqualification, or until a successor is appointed; and be > it further > > RESOLVED, that the Apache OpenWhisk Project be and hereby is tasked > with the migration and rationalization of the Apache Incubator > OpenWhisk podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > OpenWhisk podling encumbered upon the Apache Incubator Project are > hereafter discharged. -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenWhisk Catalog (v0.10.0-incubating, rc1)
+1 Checked via rcverify and some manual spot checks. On Fri, 5 Jul 2019 at 23:30, Dave Fisher wrote: > > Various podlings including tuweni have had to handle downloading gradle > separately. It’s not unusual and not really a source code issue where the > correct boundary is drawn. > > Regards, > Dave > > Sent from my iPhone > > > On Jul 5, 2019, at 8:42 PM, Rodric Rabbah wrote: > > > > We’ll sort it out I opened an issue to deal with it. We’re not the only > > Apache project that uses gradle. > > > > I missed you raising gradle issue before, my bad. > > > > -r > > > >> On Jul 5, 2019, at 11:13 PM, Justin Mclean > >> wrote: > >> > >> Hi, > >> > >>> (and they are listed under the exclusions here [3]). > >> > >> I note that it lists gradle-wrapper.jar as an exclusion there as well, > >> this is not the case as jars containing compiled source code can’t be > >> included in releases. See the legal JIRA mention in my last email [1] for > >> more info on this particular situation. I do recall this coming up in one > >> you r releases as well and teh jar was removed, so I assume the > >> documentation is just out of date. > >> > >> Thanks, > >> Justin > >> > >> 1. https://issues.apache.org/jira/browse/LEGAL-288 > >> > >> > >> - > >> 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 > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New Project?
I'm a little unclear about the scope of the project here. This project looks more like a service, and I don't know of any ASF projects that exist to provide services outside the ASF. On Tue, 2 Jul 2019 at 14:28, Alejandro Caceres wrote: > > Hey Folks, > > I'm interested in submitting a project as a seedling and am looking exactly > where to start. The project is already off the ground, being used by many, > is stable, reasonably mature (it's in alpha release), open source, and > already Apache licensed. I've been looking at a lot of resources to how > best to submit this to Apache and from what I understand I need to: > > Find a "champion/mentor" for the project and a "sponsor" -> submit an > incubator application -> wait (or do i submit for a vote on general@?) -> > ... -> profit :) > > For a bit more context, my project is http://scylla.sh or > https://github.com/acaceres2176/scylla. This project aggregates and makes > searchable database leaks and other information security data that is easy > for attackers to find (they have blackhat and underground resources) but > difficult for security professionals trying to defend their network (they > cannot buy stolen data, are not plugged into the blackhat hacker community, > and frankly generally don't know "where to start"). The Scylla engine aims > to even the playing field by making this data available and completely free > for everyone. The feed is meant to power threat intelligence engines to aid > in the defense of both large corporate networks, but also be accessible to > an average user who wants to check what information of theirs has been > leaked. It's a passion project of mine and have been working on it for > several months already. We have several terabytes of data and good > attention from the infosec community. > > Anyway, sorry for the brain dump above, but I suppose I should mainly ask - > where do I go from here? Do I simply ask this mailing list if there is a > sponsor and champion willing to bring this in as a podling? > > Thanks! > Alex > > > > -- > ___ > > Alejandro Caceres > Hyperion Gray, LLC > Owner/CTO -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like it’s some WebKit specific files that are BSD licensed. I haven’t inspected the individual files, but I suspect that the header files are BSD licensed to make linking less of a legal headache. On Sat, Jun 22, 2019 at 07:11, Craig Russell wrote: > The Webkit license page https://webkit.org/licensing-webkit/ says > portions licensed under LGPL and BSD licenses. > > Usually this means it's the user's choice which license to use. > > We would choose the BSD License for the components that we use. > > Can you find anywhere a statement that the Webkit.so is licensed only > under LGPL? > > Craig > > > On Jun 14, 2019, at 1:40 AM, 申远 wrote: > > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and it's > > almost impossible for us to figure out which function is a pure BSD > > function. I don't know > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or > > not. Perhaps pure BSD header file will lead to pure BSD implementation. > > Perhaps? > > > > As for alternative dependency, it's possible if we make some major > changes > > to Weex. But convenience binary of each Weex release includes Webkit.so, > > how to solve that problem? Maybe publish two convenience binary, one > named > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a > > good idea to me. > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > Sheng Wu 于2019年6月14日周五 下午4:23写道： > > > >> Hi York > >> > >> I am not a C/C++ coder, so I could be wrong. > >> > >> But from I saw, Catalog X dependency required is not right. Like Hen > said, > >> alternative is an option. > >> > >> Such as > >> Today’s another incubating project, ShardingSphere. > >> When user wants to MySQL sharing, then they needs to accept MySQL Driver > >> license first(or already accepted). > >> But user could use ShardingSphere with PostgreSQL JDBC Driver. > >> > >> > >> Sheng Wu > >> Apache Skywalking, ShardingSphere, Zipkin > >> > >> > >> > >>> 在 2019年6月14日，下午4:15，Hen 写道： > >>> > >>> Assuming Weex requires Webkit and is unable to work with an > alternative, > >>> the issue here is that users of Weex would seem to have to permit > reverse > >>> engineering in their legal terms. Our position has been that that goes > >>> beyond the scope of the Apache 2.0 license and would be an unpleasant > >>> surprise for users. > >>> > >>> (seem to have to => this is how we've discussed the license; an > actual > >>> court may decide something completely different) > >>> > >>> Looking at Weex's website's description, it does not seem to be that a > >> user > >>> of Weex will already have agreed to the terms of Webkit; thus I believe > >>> they would be unpleasantly surprised. > >>> > >>> Hen > >>> > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远 wrote: > >>> > >>>> Hi, > >>>> > >>>> I am a PPMC member of Apache Weex. After serious reviewing of our > >>>> dependencies, I found there some of the source code we copied from > >> Webkit > >>>> is actually under LGPL license(Category X) and our license format > tools > >>>> changed the license header of these files to Apache v2 incorrectly. > I'd > >>>> like to hear advice from incubator that whether our actions below > would > >> fix > >>>> the Category X issue. > >>>> > >>>> First of all, License for Webkit is complicated, as it's said that > >> "WebKit > >>>> is open source software with portions licensed under the LGPL and BSD > >>>> licenses available here." [1]. > >>>> > >>>> Now, Weex includes 1500 header files( .h files) from Webkit at > compiling > >>>> stage and around 150 of the are under BSD License. At runtime, Weex > will > >>>> dynamic links to the shared library of Webkit. > >>>> > >>>> After some major change, Weex could just include around 50 headers(.h > >>>> files) at compiling stage and all of them are under BSD license. At > >>>> runtime, Weex still needs to dynamic links to the shared library of > >> Webkit > >>>> as before. > >>>> > >>>> As Webkit is under dual license, and it's almost impossible for us to > >>>> figure out whether there is an function call chain like > >>>> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd > like > >> to > >>>> know our proposed change is enough to fix the Category X dependency. > >>>> > >>>> [1] https://webkit.org/licensing-webkit/ > >>>> > >>>> Best Regards, > >>>> YorkShen > >>>> > >>>> 申远 > >>>> > >> > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > Craig L Russell > c...@apache.org > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
There's a bit of discussion that can happen (and sometimes does) on the issue trackers which provide a bit more interactive yet asynchronous method of communication. The Slack activity is almost comparable to general chit chat at ApacheCon hackathons or similar. On Fri, 7 Jun 2019 at 11:36, Rodric Rabbah wrote: > > Hi Justin, thanks for your email. > > I have looked at the contributor distributions as follows: > > - 91 individuals with 1 commit. > - 24 individuals with 2 commits. > - 9 individuals with 3 commits. > - 16 individuals with 4 commits. > - 30 individuals with 5 or more commits (and fewer than 10). > - 22 individuals with 10 or more commits (and fewer than 25). > - 12 individuals with 25 or more commits (and fewer than 50). > - 8 individuals with 50 or more commits (and fewer than 100). > - 19 individuals with a 100 or more commits. > > I don't have a diversity profile per employer. I can try to gather that. Do > you have a suggestion for the easiest way to do this? Maybe infra has some > tools? > > We are in the process finalizing the PMC proposal and so we can note the > diversity information as we do. > > In terms of Slack, we have discussed the perception that the project relies > heavily on Slack [1] and I've opened a PR against our project webpage [2] > to clarify that all important conversations happen on the project dev list. > Slack is for quick informal questions, not deep technical discussions. When > the latter has occurred, we have been diligent about making sure to bring > the discussion to the dev list so it is accessible to all that follow the > project and encourage participation that way. > > -r > > [1] > https://lists.apache.org/thread.html/cc1bc85bfbd06ae588872827a5ee5c72fb3c608898f4b7d984c464e0@%3Cdev.openwhisk.apache.org%3E > [2] https://github.com/apache/incubator-openwhisk-website/pull/384 > > On Fri, Jun 7, 2019 at 6:25 AM Justin Mclean > wrote: > > > Hi, > > > > Congratulations. That’s pne of the most comprehensive maturity reports > > I’ve seen. > > > > I would be interested is seeing some details of: > > - Diversity of current committers in who they work for > > - Same for the proposed PMC (if that's been decided?) > > - There seems to be a heavy reliance on communication on Slack. Is this a > > barrier for people from other time zones from the main developers or people > > who can’t work full time of the project? > > > > Thanks, > > Justin > > ----- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling status Copyright section
A CCLA has two schedules (exhibits? sections?): one for employees, and one
for software grants. The grants section is typically left empty.
On Thu, May 16, 2019 at 11:15, Alex Harui wrote:
> Hi Matt,
>
> I'm not sure what "add" means, but there have been several past
> discussions where it appears that new code was brought in under a CCLA
> without an SGA.
>
>
> https://lists.apache.org/thread.html/d77183d7efd5faf331534edf7ee2de993e908cffa4feb7454f9a6ab1@%3Cgeneral.incubator.apache.org%3E
> https://issues.apache.org/jira/browse/LEGAL-236
>
> https://lists.apache.org/thread.html/2814bd99f77325f80c6bfbf1156debd22bf556bfd4b9786996c9217c@1423476452@%3Cgeneral.incubator.apache.org%3E
> http://s.apache.org/YPe
>
> It is also my understanding (from Roy) that in some cases existing code
> can come in under an ICLA.
>
> HTH,
> -Alex
>
> On 5/15/19, 4:27 PM, "Matt Sicker" wrote:
>
> You can add a software grant to a CCLA concurrently, but not vice
> versa.
>
> On Wed, May 15, 2019 at 03:28, sebb wrote:
>
> > On Wed, 15 May 2019 at 06:55, Alex Harui
> wrote:
> > >
> > > I do not like the words "transfer rights". It could be
> interpreted as
> > transfer of copyright. Copyright of existing code is not
> transferred to
> > the ASF, AIUI. How about "Check to make sure that an SGA or CCLA
> has been
> > received."
> > >
> > > I don't like hypotheticals, but I can imagine some individual
> starting a
> > project on GitHub, has only a few files already under ALv2, and gets
> a
> > project going at the ASF? Wouldn't we accept those few files under
> his
> > ICLA and not require an SGA or CCLA?
> > >
> > > I'd suggest dropping the second sentence ("it is necessary to
> transfer
> > rights..."). AIUI, it is only necessary to grant a perpetual
> license to
> > the ASF.
> >
> > Also, the CCLA is not required, and is not an alternative to the SGA
> > -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2Fcla-faq.html%23cclas-not-requireddata=02%7C01%7Caharui%40adobe.com%7C7b354edcc5b244d70e7c08d6d98ced18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636935596691256488sdata=xS2K8uFmOV367uU65bfbmB6XR5IGsdY8OirvNAiyNO4%3Dreserved=0
> >
> > > I like your third sentence.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 5/13/19, 5:28 PM, "Craig Russell" wrote:
> > >
> > > The Copyright section of the podling status page says "Check
> and
> > make sure that the papers that transfer rights to the ASF been
> received. It
> > is only necessary to transfer rights for the package, the core code,
> and
> > any new code produced by the project.".
> > >
> > > I'd propose a change:
> > >
> > > "Check to make sure that the papers that transfer rights to
> the ASF
> > been received (SGA or CCLA). It is necessary to transfer rights for
> any
> > existing package and core code. Any new code produced by the project
> must
> > be covered by ICLA."
> > >
> > > This change is proposed because it might not be obvious to
> everyone
> > what "the papers that transfer rights" are. And new code produced
> must be
> > committed by a person who has filed an ICLA.
> > >
> > > Patches welcome.
> > >
> > > Craig L Russell
> > > c...@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
> >
> > --
> Matt Sicker
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
--
Matt Sicker
Re: Podling status Copyright section
You can add a software grant to a CCLA concurrently, but not vice versa.
On Wed, May 15, 2019 at 03:28, sebb wrote:
> On Wed, 15 May 2019 at 06:55, Alex Harui wrote:
> >
> > I do not like the words "transfer rights". It could be interpreted as
> transfer of copyright. Copyright of existing code is not transferred to
> the ASF, AIUI. How about "Check to make sure that an SGA or CCLA has been
> received."
> >
> > I don't like hypotheticals, but I can imagine some individual starting a
> project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF? Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > I'd suggest dropping the second sentence ("it is necessary to transfer
> rights..."). AIUI, it is only necessary to grant a perpetual license to
> the ASF.
>
> Also, the CCLA is not required, and is not an alternative to the SGA
> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
>
> https://www.apache.org/licenses/cla-faq.html#cclas-not-required
>
> > I like your third sentence.
> >
> > HTH,
> > -Alex
> >
> > On 5/13/19, 5:28 PM, "Craig Russell" wrote:
> >
> > The Copyright section of the podling status page says "Check and
> make sure that the papers that transfer rights to the ASF been received. It
> is only necessary to transfer rights for the package, the core code, and
> any new code produced by the project.".
> >
> > I'd propose a change:
> >
> > "Check to make sure that the papers that transfer rights to the ASF
> been received (SGA or CCLA). It is necessary to transfer rights for any
> existing package and core code. Any new code produced by the project must
> be covered by ICLA."
> >
> > This change is proposed because it might not be obvious to everyone
> what "the papers that transfer rights" are. And new code produced must be
> committed by a person who has filed an ICLA.
> >
> > Patches welcome.
> >
> > Craig L Russell
> > c...@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
>
> --
Matt Sicker
Re: Podling status Copyright section
+1 on change, much clearer. Perhaps a link to the docs or a page with those links? On Mon, May 13, 2019 at 19:28, Craig Russell wrote: > The Copyright section of the podling status page says "Check and make sure > that the papers that transfer rights to the ASF been received. It is only > necessary to transfer rights for the package, the core code, and any new > code produced by the project.". > > I'd propose a change: > > "Check to make sure that the papers that transfer rights to the ASF been > received (SGA or CCLA). It is necessary to transfer rights for any existing > package and core code. Any new code produced by the project must be covered > by ICLA." > > This change is proposed because it might not be obvious to everyone what > "the papers that transfer rights" are. And new code produced must be > committed by a person who has filed an ICLA. > > Patches welcome. > > Craig L Russell > c...@apache.org > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: Missing Mentors
Provided OpenWhisk has another podling report before graduation. Otherwise, I’ll have missed out on sign offs entirely by joining too late. On Thu, May 9, 2019 at 23:36, Justin Mclean wrote: > Hi, > > > I am twice on the report of I am one of the 13. I can't figure out how > to > > read this report very well. > > You’re fine, the 13 people I extracted from this I’ve not listed anywhere > public. They probably know who they are and hopefully decide what best for > their podlings if they are not being active. > > I think the biggest take away is last time we look at this I think there > was 70 odd mentors flagged as potentially missing. This is a huge > improvement aver last time, and possibly shows that mentors are being more > engaged and active. > > The report has some limitations: > - It’s parsed from the incubator reports so it can only go off what text > is in that. > - Som times it’s not 100% correct > - The podlings are listed form oldest to newest left to right. > - Orange mean you missed a sign-off, blue you signed off the report. > - It includes podlings that have graduated > - It includes people who are no longer mentors. > > Having dates of sign-offs would probably help and would separating > current podlings from graduated one and indicating where some one is no > longer a mentor, > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Recommend 'Apache Dubbo graduation to Top Level Project' resolution to board
+1 On Wed, 1 May 2019 at 04:40, Furkan KAMACI wrote: > > Hi, > > +1 (binding) > > Kind Regards, > Furkan KAMACI > > On Wed, May 1, 2019 at 12:30 PM Justin Mclean > wrote: > > > Hi, > > > > +1 (binding) Great start to your journey! > > > > Thanks, > > Justin > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenWhisk Composer 0.11.0 (incubating)
I read through the source of rcverify before voting. Looks sufficient to cover the release checks. On Fri, Apr 26, 2019 at 18:48, Justin Mclean wrote: > Hi, > > +1 (binding) > > I checked: > - Incubating in name > - signatures and hash file fine > - DISCLAIMER exists > - LICENSE and NOTICE good > - code in release candidate matches code in version control > - No unexpected binary files > - Source files have correct header except one which has been fixed. > > Thanks, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] Graduate Apache Dubbo (incubating) as a Top Level Project
t;>>>>> > > > > >>>>>>>> As Justin mentioned above, the translation is under going. > We > > > > >> cannot > > > > >>>>>> do it > > > > >>>>>>>> for all because we need to examine the license and make sure > > > > >> ICLA > > > > >>>>> for > > > > >>>>>> each > > > > >>>>>>>> projects are signed, but, eventually we hope to move > everything > > > > >> into > > > > >>>>>> Apache > > > > >>>>>>>> group except for the repo [1] which serves redirection > dubbo.io > > > > >> to > > > > >>>>>>>> dubbo.apache.org. > > > > >>>>>>>> > > > > >>>>>>>> Now I have changed the title and the profile for dubbo group > > > > >> like > > > > >>>>> this: > > > > >>>>>>>> > > > > >>>>>>>> Title: Apache Dubbo Ecosystem > > > > >>>>>>>> Profile: Dubbo is now incubated in ASF: > > > > >>>>>>>> https://github.com/apache/incubator-dubbo, this group is > for > > > > >>>>> hosting > > > > >>>>>> dubbo > > > > >>>>>>>> eco-system temporaryly before the transition finishes. > > > > >>>>>>>> > > > > >>>>>>>> I hope this can answer your concerns. > > > > >>>>>>>> > > > > >>>>>>>> Regards, > > > > >>>>>>>> -Ian. > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> 1. https://github.com/dubbo/dubbo.github.io > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> On Wed, Apr 24, 2019 at 8:13 AM Sheng Wu < > > > > >> wu.sheng.841...@gmail.com > > > > >>>>>> > > > > >>>>>>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>>>> Part of the repo was used to host dubbo.io which now > > > > >> redirects > > > > >>>>> to > > > > >>>>>>>>> http://dubbo.apache.org/en-us/. Re the other projects it > may > > > > >> be > > > > >>>>>> that a > > > > >>>>>>>>> little clean up still needs to be done but action is being > > > > >> taken. > > > > >>>>> The > > > > >>>>>>>>> existence of this extra repo has been discussed a number of > > > > >> times > > > > >>>>> in > > > > >>>>>> the > > > > >>>>>>>>> project and projects are being moved off it. e.g. [1][2] > and > > > > >> more > > > > >>>>>>>> recently > > > > >>>>>>>>> [3][4]. > > > > >>>>>>>>>> This document probably best describes what is happening > [5]. > > > > >>>>>>>>> > > > > >>>>>>>>> Glad to see the actions are ongoing, and many projects are > > > > >> done. > > > > >>>>>> Could > > > > >>>>>>>> the > > > > >>>>>>>>> Dubbo community consider to make sure the Dubbo GitHub[1] > org > > > > >> to > > > > >>>>> be > > > > >>>>>>>>> processed well? Such as, > > > > >>>>>>>>> 1. Stop using the Dubbo logo. > > > > >>>>>>>>> 2. Statement clear, this org will be renamed or some other > > > > >>>>>> way(community > > > > >>>>>>>>> prefers) to avoid the branding concern. > > > > >>>>>>>>> I think the clear status of Dubbo ecosystem is very > important. > > > > >>>>>>>>> > > > > >>>>>>>>> Dubbo has a very wide community and connected many > > > > >>>>>> projects/developers, > > > > >>>>>>>> so > > > > >>>>>>>>> please consider to make sure the branding is clear before > > > > >>>>> graduation. > > > > >>>>>>>>> > > > > >>>>>>>>>> This issue is is being addressed (vote has been canceled, > > > > >> the > > > > >>>>>>>> dependancy > > > > >>>>>>>>> removed, documentation updated and there’s a discussion > > > > >> started on > > > > >>>>>> legal > > > > >>>>>>>>> discuss on if it might in future be allowed). I also note > it > > > > >> was > > > > >>>>> the > > > > >>>>>> PPMC > > > > >>>>>>>>> who first noticed this issue not the IPMC. > > > > >>>>>>>>> > > > > >>>>>>>>> This is not a blocker, this comes from the same reason I > asked > > > > >>>>> about > > > > >>>>>>>>> branding. > > > > >>>>>>>>> Dubbo is too widely used as they said in many media(s), > many > > > > >>>>>>>>> watcher(s)/star(s) in GitHub. > > > > >>>>>>>>> I am hoping it will be a good example of ASF project, and > the > > > > >> PMC > > > > >>>>> is > > > > >>>>>>>> ready > > > > >>>>>>>>> to find the license issue in first place. > > > > >>>>>>>>> > > > > >>>>>>>>> Thanks. > > > > >>>>>>>>> > > > > >>>>>>>>> [1] https://github.com/dubbo > > > > >>>>>>>>> > > > > >>>>>>>>> Sheng Wu 吴晟 > > > > >>>>>>>>> > > > > >>>>>>>>> Apache SkyWalking, ShardingSphere, Zipkin > > > > >>>>>>>>> Twitter, wusheng1108 > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> Justin Mclean 于2019年4月24日周三 > > > > >> 上午7:19写道： > > > > >>>>>>>>> > > > > >>>>>>>>>> Hi, > > > > >>>>>>>>>> > > > > >>>>>>>>>>> 1. If graduation happens, Dubbo should be Apache > branding, > > > > >>>>> then > > > > >>>>>> why > > > > >>>>>>>>>>> dubbo GitHub org[1] is still used. Especially the exact > > > > >> name > > > > >>>>> and > > > > >>>>>>>> logo. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Part of the repo was used to host dubbo.io which now > > > > >> redirects > > > > >>>>> to > > > > >>>>>>>>>> http://dubbo.apache.org/en-us/. Re the other projects it > > > > >> may be > > > > >>>>>> that a > > > > >>>>>>>>>> little clean up still needs to be done but action is being > > > > >>>>> taken. > > > > >>>>>> The > > > > >>>>>>>>>> existence of this extra repo has been discussed a number > of > > > > >>>>> times > > > > >>>>>> in > > > > >>>>>>>> the > > > > >>>>>>>>>> project and projects are being moved off it. e.g. [1][2] > > > > >> and > > > > >>>>> more > > > > >>>>>>>>> recently > > > > >>>>>>>>>> [3][4]. > > > > >>>>>>>>>> > > > > >>>>>>>>>> This document probably best describes what is happening > [5]. > > > > >>>>>>>>>> > > > > >>>>>>>>>>> 2. Most star project[2] in dubbo org is using Apache mail > > > > >>>>>> list[3]. > > > > >>>>>>>> But > > > > >>>>>>>>>>> groupId[4] says it belongs Alibaba > > > > >>>>>>>>>> > > > > >>>>>>>>>> I would guess this is just an oversight, but if someone > > > > >> from the > > > > >>>>>> PPMC > > > > >>>>>>>> can > > > > >>>>>>>>>> comment on this that would be good. > > > > >>>>>>>>>> > > > > >>>>>>>>>>> 3. Dubbo-go[5] project exists, and also use the Dubbo > > > > >> name. > > > > >>>>>>>>>> > > > > >>>>>>>>>> See [5]. > > > > >>>>>>>>>> > > > > >>>>>>>>>>> Also, in the last Dubbo vote `[VOTE]: Release Apache > Dubbo > > > > >>>>>>>>>>> Admin(Incubating) 0.2.0 [RC3]`. License issue hasn't been > > > > >>>>>> addressed > > > > >>>>>>>>>> inside > > > > >>>>>>>>>>> the PPMC(dev vote), I know LGPL is uncertain > thing(maybe), > > > > >>>>> but at > > > > >>>>>>>> this > > > > >>>>>>>>>>> moment, it should not be included. > > > > >>>>>>>>>> > > > > >>>>>>>>>> This issue is is being addressed (vote has been canceled, > > > > >> the > > > > >>>>>>>> dependancy > > > > >>>>>>>>>> removed, documentation updated and there’s a discussion > > > > >> started > > > > >>>>> on > > > > >>>>>>>> legal > > > > >>>>>>>>>> discuss on if it might in future be allowed). I also note > > > > >> it was > > > > >>>>>> the > > > > >>>>>>>> PPMC > > > > >>>>>>>>>> who first noticed this issue not the IPMC. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Thanks, > > > > >>>>>>>>>> Justin > > > > >>>>>>>>>> > > > > >>>>>>>>>> 1. > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >> > > > > > https://lists.apache.org/thread.html/aae8787244959aeaab0e3e83dd79036482df9e8006f0fb83e5173d87@%3Cdev.dubbo.apache.org%3E > > > > >>>>>>>>>> 2. > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >> > > > > > https://lists.apache.org/thread.html/f272b30bd9bb09dc605088504f8ed643bd9a3b2434c9e7ef59b6b7fe@%3Cdev.dubbo.apache.org%3E > > > > >>>>>>>>>> 3. > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >> > > > > > https://lists.apache.org/thread.html/1987617abc1d4989476beda9dfc9a79eb0e4750050317803b113288c@%3Cdev.dubbo.apache.org%3E > > > > >>>>>>>>>> 4. > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >> > > > > > https://lists.apache.org/thread.html/ec7995d2c42bafcb8f2778b1d0c6ee94bcbbc2dae11d23c41cad82d6@%3Cdev.dubbo.apache.org%3E > > > > >>>>>>>>>> 5. > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >> > > > > > https://github.com/apache/incubator-dubbo/wiki/Apache-Dubbo-external-ecosystem-status > > > > >>>>>>>>>> > > > > >>>>>> > > > > >> > - > > > > >>>>>>>>>> To unsubscribe, e-mail: > > > > >>>>> general-unsubscr...@incubator.apache.org > > > > >>>>>>>>>> For additional commands, e-mail: > > > > >>>>> general-h...@incubator.apache.org > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> -- > > > > >>>>>> Best Regards！ > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Huxing > > > > >>>>>> > > > > >>>>>> > > > > >> > - > > > > >>>>>> 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 > > > > > > > > > > > > > > > > -- > > Best Regards！ > > Huxing > > > > -- > Best Regards！ > Huxing > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [IP CLEARANCE] SkyWalking RocketBot UI project contribution
+1 On Thu, 25 Apr 2019 at 00:53, Sheng Wu wrote: > > Hi Incubator PMC, > > The TLP Apache SkyWalking has been donated code for a new ui, being > referred to as `skywalking-rocketbot-ui`[1], old hostsd at Yao Wang's > personal repo[2]. > I am sorry to submit this late. > > This is the formal request for IP clearance to be checked as per [3]. > The donated code can be found at [4] (*) > > See > http://incubator.apache.org/ip-clearance/skywalking-rocketbot-ui.html > Notice, at this moment, HTML has not been updated, the raw XML is here > http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/skywalking-rocketbot-ui.xml?revision=1858082=markup > > The PMC has voted and passed to accept this donation. > The ICLA of major contributors, Wang Yao and Tan Jian. have been filed > before, as they are already SkyWalking PMC. > The SGA from DaoCloud has been filed. > The reason that DaoCloud should submit SGA, because, in the old day, this > project announced powered by DaoCloud. Such as the latest release > https://github.com/TinyAllen/rocketbot/tree/v1.0.3#introduction > > Please vote to approve this contribution. > > This majority vote is open for at least 72 hours and as usual lazy > consensus applies. > > [1] https://github.com/apache/skywalking-rocketbot-ui > [2] https://github.com/TinyAllen/rocketbot > [3] > https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling > [4] https://issues.apache.org/jira/browse/INCUBATOR-237 > > > Sheng Wu 吴晟 > > Apache SkyWalking, ShardingSphere, Zipkin > Twitter, wusheng1108 -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board
+1 Looking forward to seeing a huge TLP! On Tue, Apr 9, 2019 at 15:12, Dave Fisher wrote: > +1 (binding) > > > On Apr 9, 2019, at 1:00 PM, Bertrand Delacretaz < > bdelacre...@codeconsult.ch> wrote: > > > > On Tue, Apr 9, 2019 at 12:41 PM Geertjan Wielenga > > wrote: > >> ...The Apache NetBeans podling community brings the resolution, after > >> discussion[1]... > > > > Enthusiastic +1, with my NetBeans mentor hat on. > > > > -Bertrand > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)
We have a fun layout in Logging: https://dist.apache.org/repos/dist/release/logging/ On Tue, 2 Apr 2019 at 07:46, Bertrand Delacretaz wrote: > > Hi Dave, > > On Tue, Apr 2, 2019 at 2:39 PM David P Grove wrote: > > ...For us, using the the version as the primary organizing metric in the > > dist > > isn't a great fit. Is there a precedent for doing otherwise (eg, first by > > component, then the active branches within each component)?... > > As an example, Sling also has many components, and we're just throwing > (most) everything in the top-level folder at > https://dist.apache.org/repos/dist/release/sling/ > > It's not fantastic if you look there, but it makes it easy to check > that there's only one version of a given component, and the download > page at https://sling.apache.org/downloads.cgi provides a more > convenient view. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)
+1 to the full checklist. Neat that there's an easy to use python script for helping validate. On Tue, 26 Mar 2019 at 07:48, David P Grove wrote: > > > > The Apache OpenWhisk Community has voted to make the first Apache release > of the OpenWhisk "Package Alarm", "Package Cloudant" and "Package Kafka" > components. > > The OpenWhisk dev list voting thread is here: > https://lists.apache.org/thread.html/e0fb73d8ca0d0c584650f4f5b8b02054f5c99d64895f3e5ace352234@%3Cdev.openwhisk.apache.org%3E > > We request that IPMC Members please review and vote on this incubator > release as described below. > > These three Apache OpenWhisk packages provide basic event-based programming > capabilities to an OpenWhisk deployment. > > This release comprises of source code distribution only. There are three > components (git repos) included in this release of the OpenWhisk Packages > Group. All release artifacts were built by PR#251 in the openwhisk-release > repo from the following Git commit IDs: > * openwhisk-package-alarms: dd6ab4d81c8893436e7242170d57951c089d5185 > * openwhisk-package-cloudant: ce5dac9cb0204fb2f78195d9e3f9364236613a31 > * openwhisk-package-kafka: 49820dd24170f24a37c02fae6ba7ec06e190423f > > openwhisk-package-alarms (C158D76 B5D9A53A AC10AC42 4CD5060C 7A6467D5 > E9624519 117E9C8C AB171590 CCC3505D 5C7E630D C41769B4 44F85F03 BBA40A6A > E04D2264 79FFA78B B3C5BFB8) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > .asc > > openwhisk-package-cloudant (380E1BA8 EC3C72A8 09B10DCF 03BC1D2D 4BFA7E4F > 892995EE 39D26BBE 758AFD5D FA680E81 54A9C726 A0D386C5 B447C947 70D26385 > 2A8D07BF 5848318A 42A3BBDD) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > .asc > > openwhisk-package-kafka (303B8286 AA9B945D 1A740FCB 0DE908D5 A287FAF5 > C20A9DF9 4BBD2F16 C488DF4B 3E82A75B 9D071B1A E1CCDB54 7B623A36 5AC88E5D > 9994539B 00ECEA5D A066D156) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.0-incubating-sources.tar.gz > .asc > > All release artifacts were signed with key 72AF0CC22C4CF320. > KEYS file is available here: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > How to verify the artifacts can be found at: > https://cwiki.apache.org/confluence/display/OPENWHISK/How+to+verify+the > +release+checklist+and+vote+on+OpenWhisk+modules+under+Apache > > Please vote on releasing version 2.0.0-incubating of Apache OpenWhisk > Package Alarm, Package Cloudant, and Package Kafka as described above. > > The vote will be open for at least 72 hours. > [ ] +1 Release Apache OpenWhisk Package Alarm, Package Cloudant, and > Package Kafka 2.0.0-incubating > [ ] +0 no opinion > [ ] -1 Do not release and the reason > > Checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > regards, > > --dave -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache TVM into the incubator
+1 On Sat, 2 Mar 2019 at 11:11, Brahma Reddy Battula wrote: > > +1 ( non-binding) > > > > On Sat, Mar 2, 2019 at 4:24 PM, Tianqi Chen > wrote: > > > +1 (non-binding > > > > On Thu, Feb 28, 2019 at 12:23 AM Cihad Guzel wrote: > > > > > +1 (non-binding) > > > > > > 28 Şub 2019 Per 11:08 tarihinde Felix Cheung > > şunu > > > yazdı: > > > > > > > +1 (binding) > > > > > > > > On Wed, Feb 27, 2019 at 10:17 PM kellen sunderland < > > > > kellen.sunderl...@gmail.com> wrote: > > > > > > > > > +1 (non-binding) > > > > > > > > > > On Wed, Feb 27, 2019, 10:15 PM Furkan KAMACI > > > > > > > wrote: > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > 28 Şub 2019 Per, saat 08:40 tarihinde Henry Saputra < > > > > > > henry.sapu...@gmail.com> > > > > > > şunu yazdı: > > > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 8:44 PM Markus Weimer > > > > > > > wrote: > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > we've discussed the proposal for the TVM project in [1]. The > > > > proposal > > > > > > > > itself can > > > > > > > > be found on the wiki [2]. > > > > > > > > > > > > > > > > According to the Incubator rules[3] I'd like to call a vote to > > > > accept > > > > > > the > > > > > > > > new > > > > > > > > TVM project as a podling in the Apache Incubator. > > > > > > > > > > > > > > > > A vote for accepting a new Apache Incubator podling is a > > majority > > > > > vote. > > > > > > > > Everyone > > > > > > > > is welcome to vote, only Incubator PMC member votes are > > binding. > > > It > > > > > > would > > > > > > > > be > > > > > > > > helpful (but not required) if you could add a comment stating > > > > whether > > > > > > > your > > > > > > > > vote > > > > > > > > is binding or non-binding. > > > > > > > > > > > > > > > > This vote will run for at least 72 hours (but I expect to keep > > it > > > > > open > > > > > > > for > > > > > > > > longer). Please VOTE as follows: > > > > > > > > > > > > > > > > [ ] +1 Accept TVM into the Apache Incubator > > > > > > > > [ ] +0 Abstain > > > > > > > > [ ] -1 Do not accept TVM into the Apache Incubator because ... > > > > > > > > > > > > > > > > Thank you for everyone who decided to join in in the past > > > > > discussions! > > > > > > > > > > > > > > > > Markus > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/e2b1fe9ca76422ec80b146a6b120091f2419e2f1c27d57080f39cf6f@%3Cgeneral.incubator.apache.org%3E > > > > > > > > > > > > > > > > [2]: https://wiki.apache.org/incubator/TVMProposal > > > > > > > > > > > > > > > > [3]: > > https://incubator.apache.org/guides/proposal.html#the_vote > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: > > general-unsubscr...@incubator.apache.org > > > > > > > > For additional commands, e-mail: > > > general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > --Brahma Reddy Battula -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator release votes
On Tue, 26 Feb 2019 at 07:43, David P Grove wrote: > > Or in the case of the current OpenWhisk podling voting thread [1], our only > mentor has already voted +1, but after a week we still need two more IPMC > votes to be able to proceed. > > Please help > As of sometime over the past day or so, I've volunteered to mentor here. I'm still catching up through tons of email, though I'll be catching up on these reviews and votes as well. -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings Which Need Mentors
I'd be interested in helping mentor OpenWhisk. I've reviewed some of their releases a while ago, so it's the project I'm most familiar with from that list. I've also seen some talks about the project, so I'm fairly interested in it in general as well. On Tue, 26 Feb 2019 at 15:17, Justin Mclean wrote: > > Hi, > > > So one way to put these facts next to each other: > > * We have 1 podling that has expressed concerned about too much IPMC > > involvement. (Possibly more who are concerned but unwilling to speak up.) > > * We have 8 podlings that have too little IPMC involvement. > > Out of 52 podlings and any changes we make may have an impact on all of those > and future podlings. I’m not saying we should't make changes but do need to > take care when to do so and perhaps try and look at things into the > perspective of the whole. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Apache TVM
o keep the current dependencies in the 3rdparty. We > > > elaborate > > > > on > > > > the background of these dependencies below: > > > > > > > > - dmlc-core: is a minimum module for logging and memory serialization. > > It > > > > is > > > > currently used by projects including ApacheMXNet, TVM, and XGBoost. The > > > > project is relatively stable, with around one change a week(most recent > > > > changes comes from XGBoost project). TVM’s dependency on dmlc-core is > > > > minimum > > > > and only uses its feature for logging. > > > > - dlpack: is a minimum consensus standard for in-memory Tensor format. > > It > > > > is > > > > currently used by PyTorch, ApacheMXNet, Chainer, and a few other > > > projects. > > > > - HalideIR: is a minimum IR data structure that is isolated from a fork > > > of > > > > Halide project. We keep the license to be MIT to respect the original > > > > license > > > > and its origin. A common consensus in the TVM project is that we keep > > the > > > > old > > > > derived code in HalideIR (which are stable), and all new developments > > > > happen > > > > in the TVM repo. > > > > > > > > The main reason to propose keep these dependencies are: > > > > - Each of the dependencies has the user and developer community of its > > > own > > > > which is larger than the TVM community or different license options(MIT > > > in > > > > HalideIR) > > > > - These dependencies are stable and update at a monthly rate. > > > > > > > > While it is possible to fork the code in the tvm repo, given that the > > > > current > > > > tvm repo is self-contained, and community development is stand-alone, > > we > > > > feel > > > > that there are have enough justifications to treat these as 3rdparty > > > > dependencies. > > > > > > > > > > > > === Required Resources === > > > > > > > > Mailing List: > > > > The usual mailing lists are expected to be set up when entering > > > incubation: > > > > > > > > * priv...@tvm.apache.org > > > > * d...@tvm.apache.org , subscribe github issues. > > > > * discuss-arch...@tvm.apache.org, Archive the discuss content of the > > > > discourse user forum > > > > > > > > > > > > Currently, we only use issues for developments and encourage community > > to > > > > use > > > > discuss forums when possible. As a result, the current github issues > > > serves > > > > similar purposes as dev@, so we propose to subscribe github issues to > > > dev@ > > > > after > > > > incubation. > > > > > > > > The current community use https://discuss.tvm.ai/ for general > > technical > > > > and > > > > support discussions. The community forum is maintained by PMCs. We > > > propose > > > > to > > > > continue to use the forum and archive the posts to an Apache mail-list. > > > We > > > > already have the mechanism to do so (see > > > > https://groups.google.com/forum/#!forum/tvm-discuss-archive) > > > > > > > > > > > > > > > > Git Repositories: > > > > > > > > Upon entering incubation, we plan to transfer the existing repo from > > > > https://github.com/dmlc/tvm to https://github.com/apache/incubator-tvm > > . > > > > > > > > > > > > > > > > > > > > Issue Tracking: > > > > > > > > TVM currently uses GitHub to track issues. We would like to continue to > > > do > > > > so > > > > while we discuss migration possibilities with the ASF Infra team. > > > > > > > > URL: > > > > > > > > Current project website: https://tvm.ai/, as we proceed website will > > > > migrate to > > > > https://tvm.incubator.apache.org and hopefully https://tvm.apache.org > > > > > > > > === Initial Committers and PMCs === > > > > > > > > As the project has already followed the Apache way of development(in > > > terms > > > > of > > > > meritocracy, community, and archive of public discussion). We plan to > > > > transition > > > > the current PMCs to PPMCs , and committers to apache committers. There > > > are > > > > also > > > > ongoing votes and discussions in the current tvm PMC private mail-list > > > > about new > > > > committers/PMCs(we also invited our tentative mentors as observers to > > the > > > > mail-list). We plan to migrate the discussions to private@ after the > > > > proposal > > > > has been accepted and bring in the new committers/PPMCs according to > > the > > > > standard Apache community procedure. > > > > > > > > > > > > Initial PPMCs > > > > - Tianqi Chen tqc...@apache.org > > > > - Ziheng Jiang zih...@apache.org > > > > - Yizhi Liu liuyi...@apache.org > > > > - Thierry Moreau mor...@cs.washington.edu > > > > - Haichen Shen shenhaic...@gmail.com > > > > - Lianmin Zheng lianminzh...@gmail.com > > > > - Markus Weimer wei...@apache.org > > > > - Sebastian Schelter > > > > - Byung-Gon Chun > > > > > > > > Initial Committers (Including PPMCs) > > > > - Aditya Atluri aditya.atl...@amd.com AMD > > > > - Tianqi Chen tqc...@apache.org University of Washington > > > > - Yuwei Hu huyuwei1...@gmail.com Cornell > > > > - Nick Hynes nhy...@berkeley.edu UC Berkeley > > > > - Ziheng Jiang zih...@apache.org University of Washington > > > > - Yizhi Liu liuyi...@apache.org AWS > > > > - Thierry Moreau mor...@cs.washington.edu University of Washington > > > > - Siva srk.i...@gmail.com Huawei > > > > - Haichen Shen shenhaic...@gmail.com AWS > > > > - Masahiro Masuda masahi...@gmail.com Ziosoft > > > > - Zhixun Tan phisi...@gmail.com Google > > > > - Leyuan Wang laura...@gmail.com AWS > > > > - Eddie Yan e...@cs.washington.edu University of Washington > > > > - Lianming Zheng lianminzh...@gmail.com Shanghai Jiao Tong University > > > > > > > > > > > > === Sponsors: === > > > > > > > > Champion: > > > > * Markus Weimer, Microsoft > > > > > > > > Mentors: > > > > * Sebastian Schelter, New York University > > > > * Byung-Gon Chun, Seoul National University > > > > > > > > Sponsoring Entity > > > > We are requesting the Incubator to sponsor this project. > > > > > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Training into the Apache Incubator
On Wed, 13 Feb 2019 at 14:38, Lars Francke wrote: > I'm not sure if I understand the question. Could you rephrase? > Do you mean training on "The Apache Way"? Essentially, yes. -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Training into the Apache Incubator
+1 Would be interesting if this project includes training for developing Apache projects in any way, or would that make more sense under ComDev or some other project? On Wed, 13 Feb 2019 at 09:09, Dmitriy Pavlov wrote: > > +1 (non-binding) > > ср, 13 февр. 2019 г. в 18:05, Ciprian Borodescu >: > > > +1 > > > > On Wed, Feb 13, 2019 at 4:52 PM Thomas Weise wrote: > > > > > +1 (binding) > > > > > > > > > On Wed, Feb 13, 2019, 6:40 AM Mohammad Asif Siddiqui < > > > asifdxtr...@apache.org> > > > wrote: > > > > > > > +1 (binding) > > > > > > > > Regards > > > > Asif > > > > > > > > On Wed, Feb 13, 2019 at 8:09 PM Julian Feinauer < > > > > j.feina...@pragmaticminds.de> wrote: > > > > > > > > > +1 (non-binding) > > > > > I really liked the idea from the start and probably will find some > > time > > > > to > > > > > contribute! > > > > > > > > > > Julian > > > > > > > > > > Am 13.02.19, 15:18 schrieb "Kevin A. McGrail" > >: > > > > > > > > > > +1 Binding. I'll also try again to get Udacity, Udemy, > > Coursera, > > > > > Pluralsight involved now that this is going to a formal incubator > > > > > podling. > > > > > I am hoping once a domino falls, more will help. > > > > > > > > > > Regards, > > > > > KAM > > > > > -- > > > > > Kevin A. McGrail > > > > > Member, Apache Software Foundation > > > > > Chair Emeritus Apache SpamAssassin Project > > > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > <(703)%20798-0171> > > > > > > > > > > > > > > > On Wed, Feb 13, 2019 at 7:00 AM Vinayakumar B < > > > > vinayakum...@apache.org > > > > > > > > > > > wrote: > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > -Vinay > > > > > > > > > > > > > > > > > > On Wed, Feb 13, 2019 at 4:58 PM Hans-Peter Zorn < > > hz...@inovex.de > > > > > > > > > wrote: > > > > > > > > > > > > > +1 (non-binding) > > > > > > > > > > > > > > Looking forward to work on this! > > > > > > > Thanks, > > > > > > > Hans-Peter > > > > > > > > > > > > > > > Am 13.02.2019 um 08:57 schrieb Lars Francke < > > > > > lars.fran...@gmail.com>: > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > we've discussed the proposal for the Training project in > > [1] > > > > and > > > > > [2]. > > > > > > The > > > > > > > > proposal itself can be found on the wiki[3]. > > > > > > > > > > > > > > > > According to the Incubator rules[4] I'd like to call a vote > > > to > > > > > accept > > > > > > the > > > > > > > > new "Training" project as a podling in the Apache > > Incubator. > > > > > > > > > > > > > > > > A vote for accepting a new Apache Incubator podling is a > > > > > majority vote. > > > > > > > > Everyone is welcome to vote, only Incubator PMC member > > votes > > > > are > > > > > > binding. > > > > > > > > It would be helpful (but not required) if you could add a > > > > comment > > > > > > stating > > > > > > > > whether your vote is binding or non-binding. > > > > > > > > > > > > > > > > This vote will run for at least 72 hours (but I expect to > > > keep > > > > > it open > > > > > > > for > > > > > > > > longer). Please VOTE as follows: > > > > > > > > > > > > > > > >
Re: [VOTE] Graduate Apache Unomi to TLP
+1 now that the name issue is taken care of. On Thu, 31 Jan 2019 at 09:55, Pierre Smits wrote: > > +1 > > Congratulations on achieving this milestone. > > Best regards, > > Pierre Smits > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > *Apache Directory <https://directory.apache.org>, PMC Member* > Apache Incubator <https://incubator.apache.org>, committer > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) > since 2008* > Apache Steve <https://steve.apache.org>, committer > > > On Thu, Jan 31, 2019 at 4:40 PM Jean-Baptiste Onofré > wrote: > > > +1 (binding) > > > > Regards > > JB > > > > On 31/01/2019 14:46, Serge Huber wrote: > > > I assume we can (resume) the voting process. If it's ok to do it here > > here's my > > > > > > +1 (non-binding) > > > > > > Regards, > > > Serge... > > > > > > On Thu, Jan 31, 2019 at 2:39 PM Serge Huber wrote: > > >> > > >> Name has been approved. Thanks Mark for doing this quickly. > > >> > > >> Regards, > > >> Serge... > > >> > > >> On Tue, Jan 29, 2019 at 2:10 PM Serge Huber wrote: > > >>> > > >>> Ok I've created the ticket here: > > >>> > > >>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-161 > > >>> > > >>> Please let me know if there is more to be done, I've done my best to > > >>> make it as extensive as possible. > > >>> > > >>> Best regards, > > >>> Serge... > > >>> > > >>> On Tue, Jan 22, 2019 at 4:19 PM Jean-Baptiste Onofré > > wrote: > > >>>> > > >>>> Thanks Bertrand. > > >>>> > > >>>> Serge and I will deal with that. > > >>>> > > >>>> Regards > > >>>> JB > > >>>> > > >>>> On 22/01/2019 16:18, Bertrand Delacretaz wrote: > > >>>>> On Tue, Jan 22, 2019 at 4:17 PM Jean-Baptiste Onofré < > > j...@nanthrax.net> wrote: > > >>>>>> ...I think we still have time to launch a PNS, and the idea was to > > do this > > >>>>>> as part of the graduation... > > >>>>> > > >>>>> Yes that should work - you basically just need to create a ticket at > > >>>>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH and there > > are > > >>>>> many examples there. > > >>>>> > > >>>>> Details at https://incubator.apache.org/guides/names.html > > >>>>> > > >>>>> -Bertrand > > >>>>> > > >>>>> - > > >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >>>>> For additional commands, e-mail: general-h...@incubator.apache.org > > >>>>> > > >>>> > > >>>> -- > > >>>> Jean-Baptiste Onofré > > >>>> jbono...@apache.org > > >>>> http://blog.nanthrax.net > > >>>> Talend - http://www.talend.com > > >>>> > > >>>> - > > >>>> 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 > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Discussion board vs. user mailing list in incubating project
On Wed, 16 Jan 2019 at 15:22, sebb wrote: > I thought the rule was that decisions have to be made on ASF mailing lists. > It's fine to have discussions elsewhere, but the results must be > brought back to a mailing list for the actual decision. > Or has that rule been changed? If so, is it documented anywhere? I think that's a better explanation of what I was trying to get at. I'm just remembering something about how when Slack opened up, channels were using an archive bot for a while. -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Hudi into the Apache Incubator
> * Ascii Table (0.2.5) Apache-2.0 > > * config (3.0.0) Apache-2.0 > > * utils (3.0.0) Apache-2.0 > > * kafka-avro-serializer (3.0.0) Apache-2.0 > > * kafka-schema-registry-client (3.0.0) Apache-2.0 > > * Metrics Core (3.1.1) Apache-2.0 > > * Graphite Integration for Metrics (3.1.1) Apache-2.0 > > * Joda-Time (2.9.6) Apache-2.0 > > * JUnit CPL-1.0 > > * Awaitility (3.1.2) Apache-2.0 > > * jersey-connectors-apache (2.17) GPL-2.0-only CDDL-1.0 > > * jersey-container-servlet-core (2.17) GPL-2.0-only CDDL-1.0 > > * jersey-core-server (2.17) GPL-2.0-only CDDL-1.0 > > * htrace-core (3.0.4) Apache-2.0 > > * Mockito (1.10.19) MIT > > * scalatest (3.0.1) Apache-2.0 > > * Spring Shell (1.2.0.RELEASE) Apache-2.0 > > > > All of them are Apache compatible > > > > == Cryptography == > > > > No cryptographic libraries used > > > > == Required Resources == > > > > === Mailing lists === > > > > * priv...@hudi.incubator.apache.org (with moderated subscriptions) > > * d...@hudi.incubator.apache.org > > * comm...@hudi.incubator.apache.org > > * u...@hudi.incubator.apache.org > > > > === Git Repositories === > > > > Git is the preferred source control system: git:// > > git.apache.org/incubator-hudi > > > > === Issue Tracking === > > > > We prefer to use the Apache gitbox integration to sync Github & Apache > > infrastructure, and rely on Github issues & pull requests for community > > engagement. If this is not possible, then we prefer JIRA: Hudi (HUDI) > > > > == Initial Committers == > > > > * Vinoth Chandar (vinoth at uber dot com) (Uber) > > * Nishith Agarwal (nagarwal at uber dot com) (Uber) > > * Balaji Varadarajan (varadarb at uber dot com) (Uber) > > * Prasanna Rajaperumal (prasanna dot raj at gmail dot com) (Snowflake) > > * Zeeshan Qureshi (zeeshan dot qureshi at shopify dot com) (Shopify) > > * Anbu Cheeralan (alunarbeach at gmail dot com) (DoubleVerify) > > > > == Sponsors == > > > > === Champion === > > Julien Le Dem (julien at apache dot org) > > > > === Nominated Mentors === > > > > * Luciano Resende (lresende at apache dot org) > > * Thomas Weise (thw at apache dot org > > * Kishore Gopalakrishna (kishoreg at apache dot org) > > * Suneel Marthi (smarthi at apache dot org) > > > > === Sponsoring Entity === > > > > The Incubator PMC > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Discussion board vs. user mailing list in incubating project
On Mon, 14 Jan 2019 at 07:15, Sebastian wrote: > So to rephrase this question, if the project finds a way to archive the > discussions to ASF-controlled infra (e.g., to a dedicated mailinglist), > than they could keep using the board? That's my understanding. It applied to the ASF Slack, for example, or IRC, or other communication channels in general. The idea is that you want your project's decision making to be asynchronously accessible by all interested parties via ASF infrastructure. -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Using GPLv3 in the build?
> > > > > Now we would not be bunding the compiler and the users wouldn’t need > > to use it when using PLC4X as it’s only needed in the code-generation phase > > of the build. > > > > > > So before I throw the idea over board, I just wanted to double-check > > this special case. > > > > > > Chris > > > > > > > > > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > > > [2] https://kaitai.io/ > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Feedback requested: New committer invitation template
one but secretary, but > >> please do cc: [priv...@project.apache.org] > >> > >> 3. When you transmit the completed iCLA, request > >> to notify the Apache [Project] and choose a > >> unique Apache id. Look to see if your preferred > >> id is already taken at > >> http://people.apache.org/committer-index.html > >> This will allow the Secretary to notify the PMC > >> when your iCLA has been recorded. > >> ] > >> > >> When your reply to this invitation is received, you will > >> receive a follow-up message with the next steps for > >> establishing you as a committer. > >> > >> Craig L Russell > >> Secretary, Apache Software Foundation > >> c...@apache.org http://db.apache.org/jdo > >> > >> > >> - > >> 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 > > > > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo < > http://db.apache.org/jdo> > -- Matt Sicker
Re: [DISCUSS] Mandatory relocation of Apache git repositories on git-wip-us.apache.org
+1 We’ve been using it at Logging for a little while now and love it. On Tue, Dec 11, 2018 at 08:03, Dave Meikle wrote: > +1 from me too. > > Cheers, > Dave > > On Tue, 11 Dec 2018 at 05:43, Myrle Krantz wrote: > > > +1 gitbox is wonderful. > > > > On Tue, Dec 11, 2018 at 3:33 AM Dave Fisher > wrote: > > > > > +1 > > > > > > Sent from my iPhone > > > > > > > On Dec 10, 2018, at 6:19 PM, Paul King wrote: > > > > > > > > +1 > > > > > > > >> On Tue, Dec 11, 2018 at 6:56 AM Roy Lenferink < > rlenfer...@apache.org> > > > wrote: > > > >> > > > >> Hi all, > > > >> > > > >> The Apache Incubator is still having a repository on git-wip-us as > > well > > > >> [1]. > > > >> > > > >> Does anyone have a problem with moving over the incubator repository > > to > > > >> gitbox voluntarily? > > > >> This means integrated access and easy PRs (write access to the > GitHub > > > >> repo). > > > >> > > > >> We need to document support for the decision from a mailing list > post, > > > so > > > >> here it is. > > > >> > > > >> - Roy > > > >> > > > >> [1] https://git-wip-us.apache.org/repos/asf/incubator.git > > > >> > > > >> -- Forwarded message - > > > >> From: Daniel Gruno > > > >> Date: vr 7 dec. 2018 om 17:53 > > > >> Subject: [NOTICE] Mandatory relocation of Apache git repositories on > > > >> git-wip-us.apache.org > > > >> To: us...@infra.apache.org > > > >> > > > >> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE > > > >> DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] > > > >> > > > >> Hello Apache projects, > > > >> > > > >> I am writing to you because you may have git repositories on the > > > >> git-wip-us server, which is slated to be decommissioned in the > coming > > > >> months. All repositories will be moved to the new gitbox service > which > > > >> includes direct write access on github as well as the standard ASF > > > >> commit access via gitbox.apache.org. > > > >> > > > >> ## Why this move? ## > > > >> The move comes as a result of retiring the git-wip service, as the > > > >> hardware it runs on is longing for retirement. In lieu of this, we > > > >> have decided to consolidate the two services (git-wip and gitbox), > to > > > >> ease the management of our repository systems and future-proof the > > > >> underlying hardware. The move is fully automated, and ideally, > nothing > > > >> will change in your workflow other than added features and access to > > > >> GitHub. > > > >> > > > >> ## Timeframe for relocation ## > > > >> Initially, we are asking that projects voluntarily request to move > > > >> their repositories to gitbox, hence this email. The voluntary > > > >> timeframe is between now and January 9th 2019, during which projects > > > >> are free to either move over to gitbox or stay put on git-wip. After > > > >> this phase, we will be requiring the remaining projects to move > within > > > >> one month, after which we will move the remaining projects over. > > > >> > > > >> To have your project moved in this initial phase, you will need: > > > >> > > > >> - Consensus in the project (documented via the mailing list) > > > >> - File a JIRA ticket with INFRA to voluntarily move your project > repos > > > >> over to gitbox (as stated, this is highly automated and will take > > > >> between a minute and an hour, depending on the size and number of > > > >> your repositories) > > > >> > > > >> To sum up the preliminary timeline; > > > >> > > > >> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated) > > > >> relocation > > > >> - January 9th -> February 6th: Mandated (coordinated) relocation > > > >> - February 7th: All remaining repositories are mass migrated. > > > >> > > > >> This timeline may change to accommodate various scenarios. > > > >> > > > >> ## Using GitHub with ASF repositories ## > > > >> When your project has moved, you are free to use either the ASF > > > >> repository system (gitbox.apache.org) OR GitHub for your > development > > > >> and code pushes. To be able to use GitHub, please follow the primer > > > >> at: https://reference.apache.org/committer/github > > > >> > > > >> > > > >> We appreciate your understanding of this issue, and hope that your > > > >> project can coordinate voluntarily moving your repositories in a > > > >> timely manner. > > > >> > > > >> All settings, such as commit mail targets, issue linking, PR > > > >> notification schemes etc will automatically be migrated to gitbox as > > > >> well. > > > >> > > > >> With regards, Daniel on behalf of ASF Infra. > > > >> > > > >> PS:For inquiries, please reply to us...@infra.apache.org, not your > > > >> project's dev list :-). > > > >> > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > -- Matt Sicker
Re: [VOTE] Graduate Apache Airflow to TLP
+1 (binding) On Thu, 6 Dec 2018 at 07:59, Bolke de Bruin wrote: > 199 sounds pretty cool too :-) > > > On 6 Dec 2018, at 13:39, Bertrand Delacretaz > wrote: > > > > On Thu, Dec 6, 2018 at 11:39 AM Mark Thomas wrote: > >> ...there is a resolution to > >> terminate a project on this month's board agenda so you'll be (if > >> nothing else changes) the 199th active project > > > > Depending on the order of those resolutions there might still be a > > brief window for celebrations ;-) > > > > -Bertrand > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Accept the Iceberg project for incubation
t; > External dependencies licensed under Apache License 2.0 > > > > - Guava https://github.com/google/guava > >- Jackson https://github.com/FasterXML/jackson-core > >- Joda-Time http://www.joda.org/joda-time/ > > > > External dependencies licensed under the MIT License > > > >- SLF4J https://www.slf4j.org/ > >- Mockito https://github.com/mockito/mockito > > > > ASF Projects > > > >- Apache Avro > >- Apache Hadoop > >- Apache Hive > >- Apache ORC > >- Apache Parquet > >- Apache Pig > >- Apache Spark > > > > Cryptography > > > > We do not expect Iceberg to be a controlled export item due to the use of > > encryption. > > Initial Committers and Affiliations > > > >- Ryan Blue b...@apache.org (Netflix) > >- Parth Brahmbhatt pa...@apache.org (Netflix) > >- Julien Le Dem jul...@apache.org (WeWork) > >- Owen O’Malley omal...@apache.org (Hortonworks) > >- Daniel Weeks dwe...@apache.org (Netflix) > > > > Sponsors and Nominated Mentors > > > >- Champion and mentor: Owen O’Malley omal...@apache.org > >- Mentor: Ryan Blue b...@apache.org > >- Mentor: Julien Le Dem jul...@apache.org > > > > Sponsoring Entity > > > > The Apache Incubator > > -- > > Ryan Blue > > > > > -- > Ryan Blue > -- Matt Sicker
Re: [VOTE] Accept the brpc Project into the Apache Incubator.
ists are expected to be set up when entering > incubation: > >> > >> * priv...@brpc.incubator.apache.org priv...@brpc.incubator.apache.org> > >> * d...@brpc.incubator.apache.org <mailto:d...@brpc.incubator.apache.org> > >> * comm...@brpc.incubator.apache.org comm...@brpc.incubator.apache.org> > >> > >> Git Repositories: > >> > >> Upon entering incubation, we want to transfer the existing repo from > https://github.com/brpc/brpc <https://github.com/brpc/brpc> to Apache > infrastructure like https://github.com/apache/incubator-brpc < > https://github.com/apache/incubator-brpc>. > >> > >> Issue Tracking: > >> > >> brpc currently uses GitHub to track issues. Would like to continue to > do so while we discuss migration possibilities with the ASF Infra committee. > >> > >> URL: > >> Currently brpc has no dedicated website except Github homepage. In the > future the website url should be http://brpc.incubator.apache.org/ < > http://brpc.incubator.apache.org/> to follow apache incubator conventions. > >> > >> > >> === Initial Committers === > >> > >> * Ge Jun(https://github.com/jamesge <https://github.com/jamesge> > jge...@gmail.com <mailto:jge...@gmail.com>) > >> * Chen Zhangyi(https://github.com/chenzhangyi < > https://github.com/chenzhangyi> frozen@gmail.com frozen@gmail.com>) > >> * Jiang Rujie(https://github.com/old-bear <https://github.com/old-bear> > jrjb...@gmail.com <mailto:jrjb...@gmail.com>) > >> * Zhu Jiashun(http://github.com/zyearn <http://github.com/zyearn> > zhujiashun2...@gmail.com <mailto:zhujiashun2...@gmail.com>) > >> * Wang Yao(https://github.com/ipconfigme <https://github.com/ipconfigme> > ipconfi...@gmail.com <mailto:ipconfi...@gmail.com>) > >> > >> === Sponsors: === > >> > >> Champion: > >> * Dave Fisher > >> > >> Mentors: > >> > >> * Kevin A. McGrail > >> * Jean-Baptiste Onofré > >> > >> Sponsoring Entity > >> We are requesting the Incubator to sponsor this project. > >> > >> > >> - > >> 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 > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [Vote] call a vote for IoTDB incubation proposal
com/thulab/iotdb-jdbc > > > > > > === External Dependencies === > > To the best of our knowledge, all dependencies of IoTDB are distributed > under Apache compatible licenses. Upon acceptance to the incubator, we > would begin a thorough analysis of all transitive dependencies to verify > this fact and introduce license checking into the build and release process. > > > > == Documentation == > > * Documentation for TsFile: https://github.com/thulab/tsfile/wiki > > * Documentation for IoTDB and its JDBC: http://tsfile.org/document > (Chinese only. An English version is in progress.) > > > > == Required Resources == > > === Mailing Lists === > > * priv...@iotdb.incubator.apache.org > > * d...@iotdb.incubator.apache.org > > * comm...@iotdb.incubator.apache.org > > > > === Git Repositories === > > * https://git-wip-us.apache.org/repos/asf/incubator-iotdb.git > > > > === Issue Tracking === > > * JIRA IoTDB (We currently use the issue management provided by Github > to track issues.) > > > > > > == Initial Committers == > > Tsinghua University, K2Data Company, Lenovo, Microsoft > > > > Jianmin Wang (jimwang at tsinghua dot edu dot cn ) > > > > Xiangdong Huang (sainthxd at gmail dot com) > > > > Jun Yuan (richard_yuan16 at 163 dot com) > > > > Chen Wang ( wang_chen at tsinghua dot edu dot cn) > > > > Jialin Qiao (qjl16 at mails dot tsinghua dot edu dot cn) > > > > Jinrui Zhang (jinrzhan at microsoft dot com) > > > > Rong Kang (kr11 at mails dot tsinghua dot edu dot cn) > > > > Tian Jiang（jiangtia18 at mails dot tsinghua dot edu dot cn） > > > > Shuo Zhang (zhangshuo at k2data dot com dot cn) > > > > Lei Rui (rl18 at mails dot tsinghua dot edu dot cn) > > > > Rui Liu (liur17 at mails dot tsinghua dot edu dot cn) > > > > Kun Liu (liukun16 at mails dot tsinghua dot edu dot cn) > > > > Gaofei Cao (cgf16 at mails dot tsinghua dot edu dot cn) > > > > Xinyi Zhao (xyzhao16 at mails dot tsinghua dot edu dot cn) > > > > Dongfang Mao (maodf17 at mails dot tsinghua dot edu dot cn) > > > > Tianan Li(lta18 at mails dot tsinghua dot edu dot cn) > > > > Yue Su (suy18 at mails dot tsinghua dot edu dot cn) > > > > Hui Dai (daihui_iot at lenovo dot com, yuct_iot at lenovo dot com ) > > > > == Sponsors == > > === Champion === > > Kevin A. McGrail (kmcgr...@apache.org) > > > > === Nominated Mentors === > > Justin Mclean (justin at classsoftware dot com) > > > > Christofer Dutz (christofer.dutz at c-ware dot de) > > > > Willem Jiang (willem.jiang at gmail dot com) > > > > > > -- > Kevin A. McGrail > VP Fundraising, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Sharding-Sphere incubation proposal
e the value and reputation that the Apache brand would > > bring to Sharding-Sphere. However, our primary interest is in the > > excellent community provided by Apache Software Foundation, in which > > all the projects could gain stability for long-term development. > > > > = Documentation = > > A complete set of Sharding-Sphere documentations is provided on > > shardingsphere.io in both English and Simplified Chinese. > > > > * [[http://shardingsphere.io/document/current/en/overview/|English]] > > * [[http://shardingsphere.io/document/current/cn/overview/|Chinese]] > > > > = Initial Source = > > The project consists of three distinct codebases: core, example and > > document. The address of three existed git repositories are as > > follows: > > > > * https://github.com/sharding-sphere/sharding-sphere > > * https://github.com/sharding-sphere/sharding-sphere-example > > * https://github.com/sharding-sphere/sharding-sphere-doc > > > > = Source and Intellectual Property Submission Plan = > > The codes are currently under Apache License Version 2.0 and have been > > verified to have no intellectual property or license issues before > > being released to open source by Dangdang in 2016. Dangdang will > > provide SGA and all committers will sign ICLA after Sharding-Sphere is > > accepted into the Incubator. > > > > = External Dependencies = > > > > As all dependencies are managed using Apache Maven, none of the > > external libraries need to be packaged in a source distribution. All > > dependencies have Apache compatible licenses except MySQL (GPL-2.0). > > > > We will remove MySQL dependencies in future. MySQL JDBC driver is > > adopted by Sharding-Proxy to connect MySQL now; We will use SPI to > > load JDBC driver, so MySQL JDBC driver is no longer provided on > > Sharding-Sphere. > > > > * Guava Apache-2.0 > > * Guava Retrying Apache-2.0 > > * commons-codec Apache-2.0 > > * commons-pool Apache-2.0 > > * commons-dbcp Apache-2.0 > > * netty Apache-2.0 > > * curator Apache-2.0 > > * grpc Apache-2.0 > > * protobuf BSD 3-clause > > * lombok MIT > > * groovy Apache-2.0 > > * snakeyaml Apache-2.0 > > * spring-context-support Apache-2.0 > > * spring-context-test Apache-2.0 > > * spring-boot-starter Apache-2.0 > > * spring-boot-configuration-processor Apache-2.0 > > * spring-boot-starter-test Apache-2.0 > > * slf4j MIT > > * logback EPL-1.0 > > * junit EPL-1.0 > > * hamcrest BSD 3-clause > > * mockito MIT > > * h2 MPL-2.0/EPL-1.0 > > * mysql GPL-2.0 Will remove before first apache release, use SPI > instead of it > > * postgresql BSD > > * mssql-jdbc MIT > > * HikariCP Apache-2.0 > > * ANTLR BSD > > * OpenTracing BSD > > > > = Required Resources = > > == Git Repositories == > > * https://github.com/sharding-sphere/sharding-sphere.git > > * https://github.com/sharding-sphere/sharding-sphere-example.git > > * https://github.com/sharding-sphere/sharding-sphere-doc.git > > > > > > == Issue Tracking == > > > > The community would like to continue using GitHub Issues. > > > > == Continuous Integration tool == > > Travis > > > > == Mailing Lists == > > * Sharding-Sphere-dev: for development discussions > > * Sharding-Sphere-private: for PPMC discussions > > * Sharding-Sphere-notifications: for users notifications, and > > notifications from GitHub > > > > == Initial Committers == > > * 张亮, Liang Zhang, zhangli...@apache.org > > * 曹昊, Hao Cao, > > * 吴晟, Sheng Wu, wush...@apache.org > > * 高洪涛, Hongtao Gao, hanahm...@apache.org > > * 张永伦, Yonglun Zhang > > * 潘娟, Juan Pan > > * 赵俊, Jun Zhao > > * 岳令, Ling Yue > > * 马晓光, Xiaoguang Ma > > * 陈清阳, QingYang Chen > > * 彭勇升, Yongsheng Peng, pen...@apache.org > > > > == Affiliations == > > * JD: Liang Zhang, Yonglun Zhang, Juan Pan, Jun Zhao > > * Dangdang: Hao Cao, Ling Yue > > * CHINA TELECOM Bestpay: QingYang Chen > > * Individuals: Sheng Wu, Hongtao Gao, Xiaoguang Ma > > > > = Sponsors = > > == Champion == > > * Roman Shaposhnik (rvs at apache dot org) > > > > == Mentors == > > * Craig L Russell (clr at apache dot org) > > * Benjamin Hindman (benh at apache dot org) > > * Willem Ning Jiang (ningjiang at apache dot org) > > > > == Sponsoring Entity == > > We are expecting the Apache Incubator could sponsor this project. > > > > - > > 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 > > -- Matt Sicker
Re: [VOTE] Graduate Apache Griffin (incubating) as a TLP
+1 On Thu, 1 Nov 2018 at 07:58, Kevin Yao wrote: > +1 > > On Thu, Nov 1, 2018 at 8:14 PM john@apache wrote: > > > +1 > > > > On Thu, Nov 1, 2018 at 6:03 PM Jean-Baptiste Onofré > > wrote: > > > > > +1 (binding) > > > > > > Regards > > > JB > > > > > > Le 1 nov. 2018 à 14:03, à 14:03, Willem Jiang > a > > > écrit: > > > >+1 binding. > > > >It's good to see griffin is ready to graduate. > > > > > > > >Willem Jiang > > > > > > > >Twitter: willemjiang > > > >Weibo: 姜宁willem > > > > > > > >On Thu, Nov 1, 2018 at 3:31 PM William Guo wrote: > > > >> > > > >> +dev > > > >> > > > >> -- Forwarded message - > > > >> From: William Guo > > > >> Date: Thu, Nov 1, 2018 at 11:21 AM > > > >> Subject: [VOTE] Graduate Apache Griffin (incubating) as a TLP > > > >> To: > > > >> > > > >> > > > >> Hi all, > > > >> > > > >> Given that we've got positive feedback on the DISCUSS > > > >> thread, after we had made some changes based on DISCUSS feedback. > > > >> I'd like to start an official VOTE thread now. > > > >> > > > >> > > > >> Please vote on the resolution pasted below to graduate > > > >> Apache Griffin from the incubator to the top level project. > > > >> > > > >> [ ] +1 Graduate Apache Griffin from the Incubator. > > > >> [ ] +0 Don't care. > > > >> [ ] -1 Don't graduate Apache Griffin from the Incubator because... > > > >> > > > >> This vote will be open for at least 72 hours. > > > >> > > > >> > > > >> Many thanks to our mentors and everyone else for their support, > > > >> > > > >> William Guo (on behalf of the Apache Griffin PPMC). > > > >> > > > >> > > > >> ## Resolution to create a TLP from graduating Incubator podling > > > >> > > > >> X. Establish the Apache Griffin 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, for distribution at no charge to the > public, > > > >> related to a data quality solution for big data, including both > > > >streaming > > > >> and batch mode. > > > >> > > > >> > > > >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > > >> (PMC), to be known as the "Apache Griffin Project", be and hereby is > > > >> established pursuant to Bylaws of the Foundation; and be it further > > > >> > > > >> RESOLVED, that the Apache Griffin Project be and hereby is > > > >> responsible for the creation and maintenance of software related to > > > >> a data quality solution for big data, including both streaming and > > > >batch > > > >> mode; > > > >> and be it further > > > >> > > > >> RESOLVED, that the office of "Vice President, Apache Griffin" 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 > > > >> Griffin Project, and to have primary responsibility for management > > > >> of the projects within the scope of responsibility of the Apache > > > >> Griffin 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 Griffin > > > >Project: > > > >> > > > >> * Alex Lv > > > >> * Deyi Yao > > > >> * Eugene Liu > > > >> * Grant Guo > > > >> * He Wang > > > >> * Henry Saputra > > > >> * Jason Liao > > > >> * John Liu > > > >> * Juan Li > > > >> * Liang Shao > > > >> * Lionel Liu > > > >> * Luciano Resende > > > >> * Nick Sokolov > > > >> * Shawn Sha > > > >> * Vincent Zhao > > > >> * William Guo > > > >> * Yuqin Xuan > > > >> > > > >> NOW, THEREFORE, BE IT FURTHER RESOLVED, that William Guo be > > > >> appointed to the office of Vice President, Apache Griffin, to serve > > > >> in accordance with and subject to the direction of the Board of > > > >> Directors and the Bylaws of the Foundation until death, resignation, > > > >> retirement, removal or disqualification, or until a successor is > > > >> appointed; and be it further > > > >> > > > >> RESOLVED, that the Apache Griffin Project be and hereby is tasked > > > >> with the migration and rationalization of the Apache Incubator > > > >> Griffin podling; and be it further > > > >> > > > >> RESOLVED, that all responsibilities pertaining to the Apache > > > >Incubator > > > >> Griffin podling encumbered upon the Apache Incubator PMC are > > > >> here after discharged. > > > > > > > >- > > > >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > >For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > -- Matt Sicker
Re: Getting through the hoops (was: Mentors wanted...)
Finding the project for an ICLA isn't too hard provided the person's name was mentioned in the mailing list recently. Finding the userid for someone new, however, does require them to tell us ahead of time. On Tue, 16 Oct 2018 at 09:31, Dave Fisher wrote: > Hi - > > Sent from my iPhone > > > On Oct 16, 2018, at 1:25 AM, Serge Huber wrote: > > > > > > Actually I think there is a lot of documentation and in itself it can be > a bit daunting. Also for the committer request, it would be great if it > could be streamlined by doing some kind of online form but there is the > question of the digital signature that might be an issue. > > > > Also, some of the optional fields such as the Apache ID or the project > name should maybe be explained as less than optional. I’ve had the problem > recently that committers filled the ICLA without the optional fields, and > then the secretary asked for the ID and the project name. So this is > putting additional work on the secretary which could be avoided. > > > > In other words, it’s not that hard when you know the process, but when > you’re learning it and want to do the right thing by not bothering mentors > for everything, I think it is less straightforward than setting up an > account on Github, which I think is what a lot of people are comparing the > experience too (at least that’s the feedback I get usually). > > Your Mentors are the ones who need to update the roster in Whimsy. It used > to be only the VP Incubator. > > If a Mentor is not helping drive onboarding then they aren’t engaged. > > Regards, > Dave > > > > > Regards, > > Serge… > > > >> On 16 Oct 2018, at 10:06, Bertrand Delacretaz < > bdelacre...@codeconsult.ch> wrote: > >> > >> Hi, > >> > >>> On Mon, Oct 15, 2018 at 7:29 PM Benjamin Young > wrote: > >>> ...I've continued to reach out to other initial committers to get them > through the > >>> hoops here at Apache--which took a few weeks of setup, > reading, etc... > >>> Mostly, I think folks find the process daunting. :-/... > >> > >> I'm curious what's so hard, maybe we aren't explaining things properly? > >> > >> IMO an initial or elected committer needs to choose an Apache ID, > >> register their iCLA, wait for their account to be created, sign up to > >> their project's dev (and maybe private) list and they're in business. > >> Ok, for now they also need to create accounts on Jira and Confluence > >> if the project uses that. > >> > >> Is this what's considered too hard, or did I miss something? > >> > >> -Bertrand > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > > > > > > ----- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] Graduate Apache Griffin (incubating) as a TLP
>> * He Wang > >> * Henry Saputra > >> * Jason Liao > >> * John Liu > >> * Juan Li > >> * Liang Shao > >> * Lionel Liu > >> * Luciano Resende > >> * Nick Sokolov > >> * Shawn Sha > >> * Vincent Zhao > >> * William Guo > >> * Yuqin Xuan > >> > >> NOW, THEREFORE, BE IT FURTHER RESOLVED, that William Guo > >> be appointed to the office of Vice President, Apache Griffin, 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 Griffin 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 Griffin Project; and be it further > >> > >> RESOLVED, that the Apache Griffin Project be and hereby > >> is tasked with the migration and rationalization of the Apache > >> Incubator Griffin podling; and be it further > >> > >> RESOLVED, that all responsibilities pertaining to the Apache > >> Incubator Griffin podling encumbered upon the Apache Incubator > >> Project are hereafter discharged. > >> > > -- Matt Sicker
Re: [VOTE] Graduate Apache ServiceComb (incubating)
+1 (binding) On Wed, 26 Sep 2018 at 06:02, Bertrand Delacretaz < bdelacre...@codeconsult.ch> wrote: > On Wed, Sep 26, 2018 at 12:06 AM Roman Shaposhnik wrote: > > ...Please vote on the resolution pasted below to graduate > > Apache ServiceComb from the incubator to the top level project... > > +1 > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java and docker runtimes 1.12.0 [RC1]
I wouldn't say it's necessarily because a jar can't be included in the source. The source for generating the jar would need to be included at least. I can see how that would get more complicated with gradlew. On Tue, 25 Sep 2018 at 16:18, Justin Mclean wrote: > Hi, > I would guess because jars cannot be included in a source release. > > Thanks, > Justin > > > > > > -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java and docker runtimes 1.12.0 [RC1]
Thanks for the explanation! That was my only concern. +1 from me then On Tue, 25 Sep 2018 at 13:50, Vincent S Hou wrote: > Hi Matt, > > This is based on ASF policy. If the jar is included in the source code, we > have to deal with the license issue of the gradle wrapper in our LICENSE > and NOTICE, which may bring more legal risks to the openwhisk release. > > Actually, within OpenWhisk community, we have a list to walk through in > order to vote: > > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repo. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > We check to make sure no compiled archives are bundled in the artifact. We > also refer to other existing Apache projects, like apache beam( > https://archive.apache.org/dist/beam/2.5.0/apache-beam-2.5.0-source-release.zip). > The jar is excluded, but the gradle wrapper scripts are kept. > > Their source code releases do not bundle the gradle wrapper either. > > I did not paste this list in general list of apache. > > Best wishes. > Vincent Hou (侯胜博) > > Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM > Cloud > > Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, > Phone: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -Matt Sicker wrote: - > To: general@incubator.apache.org > From: Matt Sicker > Date: 09/25/2018 02:31PM > Subject: Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java > and docker runtimes 1.12.0 [RC1] > > Is not including the gradle wrapper jar an ASF policy or just something > being done in this project? > > On Tue, 25 Sep 2018 at 13:28, Vincent S Hou wrote: > > > Hi Matt, > > > > We have documents saying that users need to run gradle wrapper in order > to > > install the jar in order to use further gradlew command to build. > > > > > https://github.com/apache/incubator-openwhisk-release/blob/master/releases/0.9.0-incubating/INSTALL.md#build-the-source-code > > > > We exclude the jar because this is the the artifact, which contains only > > source code. At the beginning the jar is included in the artifact, but it > > was removed later, since we target this artifact as source code only > > without jars. > > > > People need to install the gradle with the correct version, no matter the > > gradlew wrapper script is there or not. > > > > > > Best wishes. > > Vincent Hou (侯胜博) > > > > Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM > > Cloud > > > > Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, > > Phone: +1(919)254-7182 > > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > > States > > > > -Matt Sicker wrote: - > > To: general@incubator.apache.org > > From: Matt Sicker > > Date: 09/25/2018 01:57PM > > Subject: Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java > > and docker runtimes 1.12.0 [RC1] > > > > Why do the source artifacts include the gradle wrapper script if they > don't > > include the bootstrap jars? This breaks normal gradle workflows, and the > > end user will have to manually install the correct version of gradle. > > > > On Tue, 18 Sep 2018 at 11:11, Vincent S Hou wrote: > > > > > Dear IPMC members, > > > > > > This is a call for vote to release Apache OpenWhisk (Incubating): > > > OpenWhisk nodejs, java and docker runtimes 1.12.0 [RC1]. > > > > > > The Apache OpenWhisk community has voted on and approved a proposal to > > > release Apache OpenWhisk (Incubating): nodejs, java and docker > runtimes, > > > Version 1.12.0. > > > > > > We now kindly request the Incubator PMC members to review and vote on > > this > > > incubator release. > > > > > > OpenWhisk nodejs, java and docker runtimes vote thread: > > > > > > > > > https://lists.apache.org/thread.html/443cbd5eb5f2b84c3b34b92bd8585a36cd8c1ce52ef5453a7ad33282@%3Cdev.openwhisk.apache.org%3E > > > > > > OpenWhisk nodejs, java and docker runtimes vote result thread: > > > > > > > > > https://lists.apache.org/thread.html/257f62b54b1fd14e7b6e2347d0263169821f55ac4f57355e44c84194@%3Cdev.openwhisk.apache.org%3E > > > > > > This re
Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java and docker runtimes 1.12.0 [RC1]
Is not including the gradle wrapper jar an ASF policy or just something being done in this project? On Tue, 25 Sep 2018 at 13:28, Vincent S Hou wrote: > Hi Matt, > > We have documents saying that users need to run gradle wrapper in order to > install the jar in order to use further gradlew command to build. > > https://github.com/apache/incubator-openwhisk-release/blob/master/releases/0.9.0-incubating/INSTALL.md#build-the-source-code > > We exclude the jar because this is the the artifact, which contains only > source code. At the beginning the jar is included in the artifact, but it > was removed later, since we target this artifact as source code only > without jars. > > People need to install the gradle with the correct version, no matter the > gradlew wrapper script is there or not. > > > Best wishes. > Vincent Hou (侯胜博) > > Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM > Cloud > > Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, > Phone: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > -Matt Sicker wrote: - > To: general@incubator.apache.org > From: Matt Sicker > Date: 09/25/2018 01:57PM > Subject: Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java > and docker runtimes 1.12.0 [RC1] > > Why do the source artifacts include the gradle wrapper script if they don't > include the bootstrap jars? This breaks normal gradle workflows, and the > end user will have to manually install the correct version of gradle. > > On Tue, 18 Sep 2018 at 11:11, Vincent S Hou wrote: > > > Dear IPMC members, > > > > This is a call for vote to release Apache OpenWhisk (Incubating): > > OpenWhisk nodejs, java and docker runtimes 1.12.0 [RC1]. > > > > The Apache OpenWhisk community has voted on and approved a proposal to > > release Apache OpenWhisk (Incubating): nodejs, java and docker runtimes, > > Version 1.12.0. > > > > We now kindly request the Incubator PMC members to review and vote on > this > > incubator release. > > > > OpenWhisk nodejs, java and docker runtimes vote thread: > > > > > https://lists.apache.org/thread.html/443cbd5eb5f2b84c3b34b92bd8585a36cd8c1ce52ef5453a7ad33282@%3Cdev.openwhisk.apache.org%3E > > > > OpenWhisk nodejs, java and docker runtimes vote result thread: > > > > > https://lists.apache.org/thread.html/257f62b54b1fd14e7b6e2347d0263169821f55ac4f57355e44c84194@%3Cdev.openwhisk.apache.org%3E > > > > This release comprises of source code distribution only. > > > > > > For OpenWhisk Runtime Nodejs: > > The source code artifact of OpenWhisk Runtime Nodejs can be found at: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.12.0-incubating-rc1/openwhisk-runtime-nodejs-1.12.0-incubating-sources.tar.gz > > > > The SHA-512 checksum for the artifact of OpenWhisk Runtime Nodejs is: > > openwhisk-runtime-nodejs-1.12.0-incubating-sources.tar.gz: > > D046ED19 A813D9A9 96986002 C7065C7A 41FDF48A B87440D9 CF86B227 B4E2D3BF > > A63DC4C0 > > 7BAC979F 998B9867 3492A8A5 07F739ED 822BFC14 2E44EFA9 7D29DF23 > > which can be found via: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.12.0-incubating-rc1/openwhisk-runtime-nodejs-1.12.0-incubating-sources.tar.gz.sha512 > > > > The signature of the artifact of OpenWhisk Runtime Nodejs can be found > via: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.12.0-incubating-rc1/openwhisk-runtime-nodejs-1.12.0-incubating-sources.tar.gz.asc > > > > > > For OpenWhisk Runtime Java: > > The source code artifact of OpenWhisk Runtime Java can be found at: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.12.0-incubating-rc1/openwhisk-runtime-java-1.12.0-incubating-sources.tar.gz > > > > The SHA-512 checksum for the artifact of OpenWhisk Runtime Java is: > > openwhisk-runtime-java-1.12.0-incubating-sources.tar.gz: > > FADF0287 E4A65B8C F56F0CAD 128CB02E 89B701EA A621D394 6A8412FD 05522B44 > > 1AD4EC05 > > A52FF4CE 6B73FC6D 44B6730F E4023923 EE92C1C9 02DAC10F 1DB253C3 > > which can be found via: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-1.12.0-incubating-rc1/openwhisk-runtime-java-1.12.0-incubating-sources.tar.gz.sha512 > > > > The signature of the artifact of OpenWhisk Runtime Java can be found via: > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/a
Re: [VOTE] Release Apache OpenWhisk (Incubating): nodejs, java and docker runtimes 1.12.0 [RC1]
pache/incubator-openwhisk-release) to release all the > modules of OpenWhisk. The instruction for release managers can be found at: > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/release_instructions.md. > This tool > supports both manual and automated modes to package the source code, sign > the artifacts and upload the artifacts into Apache SVN repositories. > > The vote will be open for at least 72 hours or until necessary number of > votes are reached. > > Please vote accordingly: > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > > Best wishes. > Vincent Hou (侯胜博) > On behalf of OpenWhisk team > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [IP CLEARANCE] Arrow Gandiva library
+1 On Fri, 21 Sep 2018 at 14:09, Wes McKinney wrote: > Apache Arrow is receiving a donation of the Gandiva library, an > LLVM-based analytical expression compiler framework [1] > > Please vote to approve this contribution. > > This is a lazy consensus majority vote, per the IP clearance process > [2], open for at least 72 hours. > > Wes > > [1]: http://incubator.apache.org/ip-clearance/arrow-gandiva.html > [2] http://incubator.apache.org/ip-clearance/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] Graduate Apache Servicecomb (incubating) as a TLP
inted to the office of Vice President, Apache ServiceComb, to serve > > in accordance with and subject to the direction of the Board of > > Directors and the Bylaws of the Foundation until death, resignation, > > retirement, removal or disqualification, or until a successor is > > appointed; and be it further > > > > RESOLVED, that the Apache ServiceComb Project be and hereby is tasked > > with the migration and rationalization of the Apache Incubator > > ServiceComb podling; and be it further > > > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > > ServiceComb podling encumbered upon the Apache Incubator PMC are > > hereafter discharged. > > > > - > > To unsubscribe, e-mail: > > > general-unsubscribe@.apache > > > For additional commands, e-mail: > > > general-help@.apache > > > > > > -- > Sent from: http://apache-incubator-general.996316.n3.nabble.com/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: New member - Help me to find out project
See also https://helpwanted.apache.org On Mon, 24 Sep 2018 at 03:22, Liang Chen wrote: > Hi > > You can find all projects from this link : > https://projects.apache.org/projects.html > > It would be better if you could first spend some time in understanding "how > to contribute ... documents" of the selected project. > > Regards > Liang > > > $uMe$h wrote > > Hi all, > > > > I am new here and would like contribute in new open source projects. > > > > I mostly work on java technology and know bit of Python and JS. > > > > Please help me to find out new project which requires more > > volunteers/attention. > > > > Thanks and Regards, > > Sumesh > > > > > > -- > Sent from: http://apache-incubator-general.996316.n3.nabble.com/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: Mentor capactity of the incubator
I'm interested in being a mentor at some point, though I'd prefer to help with a project in a domain I'm experienced with. On Sun, 16 Sep 2018 at 10:26, Willem Jiang wrote: > Hi > > From my podling experience, it's really hard for a new podling > project to find a mentor by himself, so sometime new podling project > just ask help in the mailing list. > The warm hearted mentors who response the mail will be put put into > the podling proposal, and we never ask them about if they have time to > perform the duty of mentor. > Maybe we can setup a reminder email once the mentor is adding to the > podling project to let him know about the role, duties, and how much > time he need to put into the Podling project. In this way, we may > reduce the inactive mentor situations in the future. > > But how much time do we need to spend for mentoring the project. From > my experience, there are some work for the project initial setup and > release mentoring, but other time,the mentor just need to keep an eye > on the project and response the question from Podling projects. But > it could be different from project to project, so please add your > comments here. > > BTW, it's hard for the podling project to ask for release checking as > there are only few IPMC members vote the release kit. If we talk about > the Mentor capacity, IMO we need to take this issue into > consideration. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sun, Sep 16, 2018 at 3:18 PM Justin Mclean > wrote: > > > > Hi, > > > > We have a large number of IPMC members (280+). I wondering if any IPMC > members could indicate if they have any capacity/free cycles and a > willingness for mentoring projects. It looks like we are going to have a > number of inactive mentors step down in the near future and we may end up > with some podlings only having one or two mentors. Three mentors seems to > the the number that works best. > > > > Of course I understand it may have to be the right sort of project, but > I’m just trying the gauge the current mentor capacity of the incubator, so > if you think you could be a mentor if the right project came along then > please indicate it here. > > > > For IPMC members who are unable to be a mentor I’m curious to know what > the reasons are, I’m sure that “not having the time" is probably the number > one reason, but are is there any thing else stopping member (in particular > first time ones) from coming forward and volunteering? > > > > The mentor capacity we have may in the future have an impact on if and > how often we accept new podlings. I'd hate to turn away podlings, but if we > can’t effectively mentor them I’m not sure what else we can do. anyone have > any ideas? > > > > For myself currently I could only realistically mentor one more project. > > > > 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 > > -- Matt Sicker
Re: [VOTE] Retire Gearpump podling
+1 On Mon, 17 Sep 2018 at 04:33, Justin Mclean wrote: > +1 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Graduate Apache Pulsar (incubating) as a TLP
+1 (binding) On Wed, 12 Sep 2018 at 10:40, Dave Fisher wrote: > Hi - > > The Apache Pulsar project is ready to graduate as a TLP. They entered > Incubation on June 1, 2017, have had many releases and have grown the > community. > > Vote: > [ ] +1 - Recommend Graduation of Apache Pulsar as a TLP > [ ] -1 - Do not recommend graduation of Apache Pulsar because …. > > At the mentors request they did a maturity model analysis [1] and wrote > contribution guidelines. [2] > > The Graduation Proposal was written and discussed on the dev list. [3] At > the mentor's recommendation the By-Laws Clause was removed. > > The new prospective PMC is set and the VOTE thread in the podling is here > [4] with these results. [5] > > Regards, > Dave > > [1] > https://github.com/apache/incubator-pulsar/wiki/Apache-Maturity-Model-Assessment-for-Pulsar > [2] http://pulsar.incubator.apache.org/en/contributing/ > [3] > https://lists.apache.org/thread.html/b0914461f57253237e4a3c9151342f6d4fa37359dfc98a07adf9f36f@%3Cdev.pulsar.apache.org%3E > [4] > https://lists.apache.org/thread.html/93198abe36564a9e11a2a1bfe3ea8f35998444dbafea830f8b39df7b@%3Cdev.pulsar.apache.org%3E > [5] > https://lists.apache.org/thread.html/64841a07ba3dee2271f4098f9142afd41acffae1736275592aab4c83@%3Cdev.pulsar.apache.org%3E > > > > > Establish the Apache Pulsar 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, for distribution at no charge to the public, > related to a highly scalable, low latency messaging platform running on > commodity hardware. It provides simple pub-sub and queue semantics over > topics, lightweight compute framework, automatic cursor management for > subscribers, and cross-datacenter replication. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache Pulsar Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache Pulsar Project be and hereby is responsible > for the creation and maintenance of software related to a highly > scalable, low latency messaging platform running on commodity hardware. > It provides simple pub-sub and queue semantics over topics, lightweight > compute framework, automatic cursor management for subscribers, and > cross-datacenter replication; and be it further > > RESOLVED, that the office of "Vice President, Apache Pulsar" 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 Pulsar > Project, and to have primary responsibility for management of the > projects within the scope of responsibility of the Apache Pulsar > 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 Pulsar Project: > > * Boyang Jerry Peng > * Brad McMillen > * David Fisher > * Francis Christopher Liu > * Hiroyuki Sakai > * Ivan Brendan Kelly > * Jai Asher > * Jia Zhai > * Jim Jagielski > * Joe Francis > * Ludwig Pummer > * Masahiro Sakamoto > * Masakazu Kitajo > * Matteo Merli > * Nozomi Kurihara > * P. Taylor Goetz > * Rajan Dhabalia > * Sahaya Andrews > * Sanjeev Kulkarni > * Sebastián Schepens > * Siddharth Boobna > * Sijie Guo > * Yuki Shiga > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matteo Merli be appointed > to the office of Vice President, Apache Pulsar, to serve in accordance > with and subject to the direction of the Board of Directors and the > Bylaws of the Foundation until death, resignation, retirement, removal > or disqualification, or until a successor is appointed; and be it > further > > RESOLVED, that the Apache Pulsar Project be and hereby is tasked with > the migration and rationalization of the Apache Incubator Pulsar > podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > Pulsar podling encumbered upon the Apache Incubator PMC are hereafter > discharged. > -- Matt Sicker
Re: [VOTE] Accept Zipkin into the Apache Incubator
veral years, association with the ASF is expected > to > > expedite this pattern of growth. Development is expected to continue on > > Zipkin under the Apache license whether or not it is supported by the > ASF. > > > > == Documentation == > > The Zipkin project documentation is publicly available at the following > > sites: > > > > * https://zipkin.io: project overview > > * http://zipkin.io/zipkin-api/#/: swagger specification > > * https://github.com/openzipkin/b3-propagation: header formats > > * https://zipkin.io/zipkin/: Javadocs for the Zipkin server > > > > == Initial Source == > > The initial source is located on GitHub in the following repositories: > > > > * git://github.com/OpenZipkin/zipkin.git > > * git://github.com/OpenZipkin/zipkin-dependencies.git > > * git://github.com/OpenZipkin/zipkin-api.git > > * git://github.com/OpenZipkin/b3-propagation.git > > * git://github.com/OpenZipkin/docker-zipkin.git > > * git://github.com/OpenZipkin/docker-zipkin-dependencies.git > > * git://github.com/openzipkin/zipkin-reporter-java > > * git://github.com/openzipkin/brave > > * git://github.com/openzipkin/zipkin-aws > > * git://github.com/openzipkin/docker-zipkin-aws > > * git://github.com/openzipkin/zipkin-azure > > * git://github.com/openzipkin/docker-zipkin-azure > > * git://github.com/openzipkin/zipkin-gcp > > * git://github.com/openzipkin/docker-zipkin-gcp > > * git://github.com/openzipkin/brave-cassandra > > * git://github.com/openzipkin/docker-jre-full > > * git://github.com/openzipkin/brave-karaf > > > > Depending on community progress, other repositories may be moved as well > > > > == Source and Intellectual Property Submission Plan == > > Zipkin's initial source is licensed under the Apache License, Version > 2.0. > > https://github.com/openzipkin/zipkin/blob/master/LICENSE > > > > All source code is copyrighted to 'The OpenZipkin Authors', to which the > > existing core community(members list in Initial Committers) has the > rights > > to re-assign to the ASF. > > > > == External Dependencies == > > This is a listing of Maven coordinates for all of the external > > dependencies Zipkin uses. All of the dependencies are in Sonatype and > their > > licenses should be accessible. > > > > == Cryptography == > > Zipkin contains no cryptographic algorithms. > > > > = Required Resources = > > == Mailing Lists == > > * Zipkin-dev: for development discussions > > * Zipkin-user: for community discussions > > * Zipkin-private: for PPMC discussions > > * Zipkin-commits: for code changes > > > > == Git Repositories == > > The Zipkin team is experienced in git and requests to transfer GitHub > > repositories(list in Initial Source) to Apache. > > > > == Issue Tracking == > > The community would like to continue using GitHub Issues. > > > > = Initial Committers = > > * Zoltán Nagy > > * Adrian Cole, Pivotal > > * Bas van Beek > > * Brian Devins > > * Eirik Sletteberg > > * Jeanneret Pierre-Hugues > > * Jordi Polo Carres > > * José Carlos Chávez > > * Kristof Adriaenssens > > * Lance Linder > > * Mick Semb Wever, > > * Tommy Ludwig > > > > = Champion = > > * Michael Semb Wever, m...@apache.org > > > > = Mentors = > > * Michael Semb Wever, m...@apache.org > > * Andriy Redko, r...@apache.org > > * John D. Ament, johndam...@apache.org > > * Willem Ning Jiang, ningji...@apache.org > > > > = Sponsoring Entity = > > We are requesting the Apache Incubator to sponsor this project. > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > -- Matt Sicker
Re: [VOTE] Accept Marvin-AI into Apache Incubator
I don't think it'll be a problem, but it's something to keep in mind while filing SGAs down the line. +1 (binding) On Wed, 22 Aug 2018 at 14:18, Lucas Bonatto Miguel wrote: > Hi Matt, the paper is scheduled to be released in the proceedings of the > JMLR (Journal of Machine Learning Research) volume 82. > > There is code samples in the paper in fact, however that code is only using > Marvin APIs to implement an engine, it does not contain Marvin's > implementation code. By the way, that code is also using Apache Spark APIs. > Let me know if you think it's still an issue. > > On Wed, Aug 22, 2018 at 4:00 PM Matt Sicker wrote: > > > What license is the Marvin paper distributed under? There's code samples > in > > that paper as well which have no license. > > > > On Tue, 21 Aug 2018 at 16:11, Luciano Resende > > wrote: > > > > > Off course, my +1 (binding) > > > > > > On Tue, Aug 21, 2018 at 10:43 AM Luciano Resende > > > > wrote: > > > > > > > After the initial discussion, please vote on the acceptance of > > Marvin-AI > > > > Project for incubation at the Apache Incubator. The full proposal is > > > > available at the end of this message and on the wiki at : > > > > > > > > https://wiki.apache.org/incubator/Marvin-AI > > > > > > > > Please cast your votes: > > > > > > > > [ ] +1, bring Marvin-AI into Incubator > > > > [ ] +0, I don't care either way > > > > [ ] -1, do not bring Marvin-AI into Incubator, because... > > > > > > > > The vote is open for the next 72 hours and only votes from the > > > > Incubator PMC are binding. > > > > > > > > === > > > > > > > > = Marvin-AI = > > > > > > > > == Abstract == > > > > > > > > Marvin-AI is an open-source artificial intelligence (AI) platform > that > > > > helps data scientists, prototype and productionalize complex > solutions > > > with > > > > a scalable, low-latency, language-agnostic, and standardized > > architecture > > > > while simplifies the process of exploration and modeling. > > > > > > > > == Proposal == > > > > > > > > Marvin helps non-experienced developers create industry-grade AI > > > > applications. It has three core components: a development > environment > > to > > > > be used during data exploration and hypothesis validation (Toolbox), > a > > > > library which should be extended to create Marvin engines, and a > Scala > > > > application server which interprets engines (Engine Executor). > > > > A basic premise of Marvin is that it should be language-agnostic, > able > > to > > > > interpret engines implemented in different programming languages. > > > > > > > > == Background == > > > > > > > > The Marvin AI project was initiated as an internal project at B2W > > Digital > > > > (Brazil), the largest e-commerce company in Latin America. Nowadays, > it > > > is > > > > used by all data scientists within the B2W team. Oftentimes, data > > > > scientists don't have an extensive background in software > engineering, > > > yet > > > > are in charge of creating AI applications that need to scale to high > > > > throughput and provide millisecond-level response times. At B2W, > Marvin > > > AI > > > > plays an important role in this process, abstracting advanced > software > > > > engineering procedures, allowing data scientists to focus on their > > > > knowledge domain. > > > > > > > > == Rationale == > > > > > > > > With recent advances in computer architecture and a corresponding > > > increase > > > > in the amount of data generated by always-connected devices, AI > > > algorithms > > > > offer a solution to problems that have long troubled modern > > corporations. > > > > Since AI developers come from various fields, such as statistics, > > > physics, > > > > and math, there exists a strong need for platforms which enable them > to > > > > move from prototypes to enterprise applications. Although some tools > > > claim > > > > to offer this service, in reality, there is no reliable open-source > > > > solution. > > > > > > > > == Initial Goals == > > > &g
