[jira] [Commented] (INCUBATOR-271) SeaTunnel Incubator project request for the GitHub repositories moving service
[ https://issues.apache.org/jira/browse/INCUBATOR-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464317#comment-17464317 ] Calvin Kirs commented on INCUBATOR-271: --- Thanks for your guidance, can you help me close this? > SeaTunnel Incubator project request for the GitHub repositories moving service > -- > > Key: INCUBATOR-271 > URL: https://issues.apache.org/jira/browse/INCUBATOR-271 > Project: Incubator > Issue Type: Task > Components: git >Reporter: Calvin Kirs >Priority: Major > > The vote result of *Accept SeaTunnel into the Apache Incubator* can be found > here: > https://lists.apache.org/thread/70yywsx4r8y5o91twnp13s671q8j4dng > We have completed the submission and confirmation of SGA > Please help us to move the SeaTunnel repos: > https://github.com/InterestingLab/seatunnel to > https://github.com/apache/incubator-seatunnel > Deeply thanks for your help -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-271) SeaTunnel Incubator project request for the GitHub repositories moving service
[ https://issues.apache.org/jira/browse/INCUBATOR-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464314#comment-17464314 ] Calvin Kirs commented on INCUBATOR-271: --- Thank you~ > SeaTunnel Incubator project request for the GitHub repositories moving service > -- > > Key: INCUBATOR-271 > URL: https://issues.apache.org/jira/browse/INCUBATOR-271 > Project: Incubator > Issue Type: Task > Components: git >Reporter: Calvin Kirs >Priority: Major > > The vote result of *Accept SeaTunnel into the Apache Incubator* can be found > here: > https://lists.apache.org/thread/70yywsx4r8y5o91twnp13s671q8j4dng > We have completed the submission and confirmation of SGA > Please help us to move the SeaTunnel repos: > https://github.com/InterestingLab/seatunnel to > https://github.com/apache/incubator-seatunnel > Deeply thanks for your help -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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
Ralph>I was busy The world is on fire with log4j, so if you have no time left for 1.x, then, please, just let others do the maintenance. Ralph>My recollection was me saying if I had the code in a git repo getting it into a GitHub repo would be easy. I do not want to dilute "svn -> git" question any further, so, if you have time (apparently, you do respond on logging and here), consider answering at https://issues.apache.org/jira/browse/LOG4J2-3272 --- Ralph, my response was https://lists.apache.org/thread/jzym3z270jqr84m8o4m7pxlmpk8frr4z Literally, you have **nothing** to do except blessing the migration in order to get Git and GitHub open for log4j 1.x . You even ignored "[VOTE] Move log4j 1.x from SVN to Git..." https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2 You still keep asking "if git repo exists or not". Who cares if git repo exists? I offer you help with getting the things done, yet you ask questions as if I ask you to do the work. Vladimir
[jira] [Commented] (INCUBATOR-271) SeaTunnel Incubator project request for the GitHub repositories moving service
[ https://issues.apache.org/jira/browse/INCUBATOR-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464307#comment-17464307 ] Justin Mclean commented on INCUBATOR-271: - You'll need to raise an INFRA JIRA for this. > SeaTunnel Incubator project request for the GitHub repositories moving service > -- > > Key: INCUBATOR-271 > URL: https://issues.apache.org/jira/browse/INCUBATOR-271 > Project: Incubator > Issue Type: Task > Components: git >Reporter: Calvin Kirs >Priority: Major > > The vote result of *Accept SeaTunnel into the Apache Incubator* can be found > here: > https://lists.apache.org/thread/70yywsx4r8y5o91twnp13s671q8j4dng > We have completed the submission and confirmation of SGA > Please help us to move the SeaTunnel repos: > https://github.com/InterestingLab/seatunnel to > https://github.com/apache/incubator-seatunnel > Deeply thanks for your help -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (INCUBATOR-271) SeaTunnel Incubator project request for the GitHub repositories moving service
Calvin Kirs created INCUBATOR-271: - Summary: SeaTunnel Incubator project request for the GitHub repositories moving service Key: INCUBATOR-271 URL: https://issues.apache.org/jira/browse/INCUBATOR-271 Project: Incubator Issue Type: Task Components: git Reporter: Calvin Kirs The vote result of *Accept SeaTunnel into the Apache Incubator* can be found here: https://lists.apache.org/thread/70yywsx4r8y5o91twnp13s671q8j4dng We have completed the submission and confirmation of SGA Please help us to move the SeaTunnel repos: https://github.com/InterestingLab/seatunnel to https://github.com/apache/incubator-seatunnel Deeply thanks for your help -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Release Apache MXNet (incubating) version 1.9.0
Dear all, The Apache MXNet (incubating) community is happy to announce Apache MXNet (incubating) version 1.9.0! Apache MXNet (incubating) is a deep learning framework designed for both efficiency and flexibility. It allows you to mix symbolic and imperative programming to maximize efficiency and productivity. A full list of the changes in this release can be found in the release notes: https://github.com/apache/incubator-mxnet/releases/tag/1.9.0 A link to the download page can be found here: https://mxnet.apache.org/versions/1.9.0/get_started/download.html If you prefer to build from source and experiment with various compile-time configuration options, use this link to get the instructions: https://mxnet.apache.org/get_started/build_from_source Or you can download and play with MXNet easily using one of the options below: 1. The pip packages can be found here: https://pypi.python.org/pypi/mxnet 2. The Docker Images can be found here: https://hub.docker.com/r/mxnet/python/ The release tag: https://github.com/apache/incubator-mxnet/tree/1.9.0 MXNet Resources - Our discussion forum (https://github.com/apache/incubator-mxnet/discussions) - MXNet dev mailing list (https://lists.apache.org/list.html?d...@mxnet.apache.org) - StackOverflow mxnet tag (https://stackoverflow.com/questions/tagged/mxnet) - MXNet website (https://mxnet.incubator.apache.org) - Follow MXNet Development on Github (https://github.com/apache/incubator-mxnet/issues) - MXNet Confluence Wiki for Developers (https://cwiki.apache.org/confluence/display/MXNET) - Apache Slack #mxnet Channel (https://the-asf.slack.com/archives/C7FN4FCP9) Social Media - Apache MXNet on Twitter (https://twitter.com/apachemxnet) - Contributor and user blogs about MXNet (https://medium.com/apache-mxnet) - Discuss MXNet on r/mxnet (https://www.reddit.com/r/mxnet) - Apache MXNet YouTube channel (https://www.youtube.com/apachemxnet) - Apache MXNet on LinkedIn (https://www.linkedin.com/company/apache-mxnet) For more information on Apache MXNet (incubating), please see: https://mxnet.incubator.apache.org/ Best regards, Apache MXNet (incubating) Team ___ DISCLAIMER: Apache MXNet (incubating) is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
[IP CLEARANCE] Apache Arrow Julia library (2nd try)
Hi, Apache Arrow is receiving a donation of a Julia library [1]. Note that this is the second Julia library donation because Apache Arrow's development process had a problem after the first Julia library donation. See the "Description" in [1] for details. Apache Arrow restarts Julia library development with correct (the Apache way) development process from IP clearance. 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. [1]: https://incubator.apache.org/ip-clearance/arrow-julia-library2.html [2]: https://incubator.apache.org/ip-clearance/ Thanks, -- kou - 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
OK, thank you for the feedback. Will open issues and also discuss threads on the mailing list for these things. Ralph Goers 于2021年12月23日周四 08:10写道： > > > > On Dec 21, 2021, at 9:22 PM, 张铎(Duo Zhang) > wrote: > > > > But in my experience, first, the log4j12 bridge is not perfect. For > > example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge > > dependency if I want to run UTs based on hadoop mini cluster, and then I > > need to manually copy some code from log4j1 in order to make it work, > this > > is an example > > > > > https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java > > > > I know in the bridge you will create log4j2 appender instead when reading > > the configuration file of log4j1, but since the appenders in log4j1 lack > of > > some abilities, it is common that lots of projects will implement their > own > > appender, I think we should take care of these usages and make them > migrate > > smoothly. > > I do not know if you are aware but the experimental support we added a few > releases ago should > be able to use Log4j 1 Appenders in Log4j2. It is experimental simply > because we have no idea what wild > and crazy things uses are relying on in Log4j 1 since nothing was private. > We need user feedback. > > > > > And then, while fully migrating to log4j2, there is another annoying > > problem, the > > > > log4j.rootLogger=INFO,console > > > > grammar is gone! It is used among almost all the projects I've seen, and > we > > just drop the support for it! > > Again, support for Log4j 1 configuration files is part of the experimental > support. We finally received > our first bug report on it so someone is using it. > > Ralph > - > 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
> On Dec 22, 2021, at 12:35 AM, Vladimir Sitnikov > wrote: > > > I already asked Logging PMC to enable Git and GitHub for 1.x, and they > rejected it: > https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2 My recollection was me saying if I had the code in a git repo getting it into a GitHub repo would be easy. But I wasn’t going to do the work. But it appears the code is in Gitbox. If so, getting it into an updatable GitHub repo should be easy - except the name you probably want to use is the one used by Gitbox. We’ve also asked what your plans would be for all the issues that are in Bugzilla. It seems you would rather use Jira or GitHub issues. I don’t blame you there. But will you just ignore all those old problems? I don’t recall getting an answer. But maybe you did. I was busy. Ralph - 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
> On Dec 21, 2021, at 10:24 PM, Vladimir Sitnikov > wrote: > > Matt>Nobody in the Logging PMC is blocking a release here. > > Matt, thanks for the reply, however, it is false :( > I see you are positive, however, many more replies were quite negative. > > Ralph Goers says: "We’ve stated several times that we don’t think > resurrecting Log4j 1.x permanently is a good idea." > https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt > > Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should > ONLY be for CVEs," > https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7 > > They both are on Logging PMC, and they both have negative opinions on > making progress with v1. > I do not really understand what "ONLY be for CVEs" means (e.g. does it > allow upgrading from Maven2 to Maven3?), > but I do not want to get accidentally blocked by "oh, this change is not > allowed because it is not a CVE fix". Of course we have opinions. But me saying I don’t think it is a good idea doesn’t mean “No, it isn’t going to happen”. I’ve said I think lots of things are bad ideas and then changed my mind. But the emphasis here should really be on getting consensus from those who are trying to do work on Log4j 1.x. Do they just want a 1.2.18 release or a continuing sub-project. I know you are very vocal about wanting a continuing sub-project but I’ve not really heard anybody else say they are in it for the long haul. Ralph - 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
> On Dec 21, 2021, at 9:22 PM, 张铎(Duo Zhang) wrote: > > But in my experience, first, the log4j12 bridge is not perfect. For > example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge > dependency if I want to run UTs based on hadoop mini cluster, and then I > need to manually copy some code from log4j1 in order to make it work, this > is an example > > https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java > > I know in the bridge you will create log4j2 appender instead when reading > the configuration file of log4j1, but since the appenders in log4j1 lack of > some abilities, it is common that lots of projects will implement their own > appender, I think we should take care of these usages and make them migrate > smoothly. I do not know if you are aware but the experimental support we added a few releases ago should be able to use Log4j 1 Appenders in Log4j2. It is experimental simply because we have no idea what wild and crazy things uses are relying on in Log4j 1 since nothing was private. We need user feedback. > > And then, while fully migrating to log4j2, there is another annoying > problem, the > > log4j.rootLogger=INFO,console > > grammar is gone! It is used among almost all the projects I've seen, and we > just drop the support for it! Again, support for Log4j 1 configuration files is part of the experimental support. We finally received our first bug report on it so someone is using it. Ralph - 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
I’m sorry, I was just directed to this thread. I don’t read my incubator emails every day since I am not mentoring any podlings at the moment. There seems to be some disconnect with the facts. From my viewpoint they are: An email came in asking if it would be possible to put out a new 1.2.18 release to address the outstanding CVEs. Our response was that we were totally focused on 2.x, don’t have a lot of experience building 1.x but would be happy to help release that if it met the PMCs expectations. A pull request then arrived - I believe https://github.com/apache/log4j/pull/16 - that was objected to by one of our PMC members as it deletes a bunch of classes rather than fixing them in a manner similar to what we did for Log4j 2. I noticed that there seemed to be a disconnect between some of the posters. Some just wanted to get 1.2.18 published as originally proposed while others seemed to want it to continue on. As there currently is no Log4j 1 community I asked which option they were after and suggested that if they wanted to develop a community that the incubator is where that happens with Logging Services as the sponsor. If a community develops it would be expected that graduation would be as a subproject of the Logging Services Project. That seemed to make some unhappy as any PMC member could veto commits in the Log4j 1 work. As far as I am concerned we never really got an answer to 1) Is this a one and done? 2) Is there are real community to support Log4j 1? 3) There are major flaws in Log4j 1.x’s architecture which is why SLF4J/Logback and Log4j 2 came to be. Will an attempt be made to address those without breaking compatibility? 4) Does this community care about compatibility? Simply removing classes is not user friendly. To top it off this discussion was going on while the whole Logging Services PMC was overwhelmed with security emails, users asking for help, and the PMC trying to get patch releases out. It was a poor choice of timing to try to have this discussion during that frenzy. In short, we don’t object to either a 1.2.18 release or reactivating Log4j 1. What we don’t want is a release of Log4j 1 along with a misconception that it is being supported again when it is not. We don’t want releases of Log4j 1 that do more harm than good. Sorry for the long post. Ralph > On Dec 20, 2021, at 12:26 AM, Vladimir Sitnikov > wrote: > > Hi, > > I want to resurrect log4j 1.x to fix well-known security issues. > I'm looking for the champion and committers. > > log4j 1.x is a wildly used logging library, so releasing a secured version > would silence CVE warnings > all over the world, and it would enable users to focus on more relevant > tasks than "upgrading from log4j1 to log4j2". > > I do not expect active log4j1 development, however, I would strongly focus > on fixing the security issues. > > Unfortunately, there are lots of applications that can't easily upgrade to > log4j2, and they are exposed to security issues. > I did try my best cooperating with the current logging PMC, and it looks > like they > are not interested in fixing 1.x (see [1], [2], [3], [4]) > > I'm a member of PMC on Apache JMeter and Apache Calcite projects, so > I am familiar with the way Apache projects are governed. > > [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5 > [2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc > [3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n > [4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8 > > Vladimir - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache AGE Incubating as a Top Level Project
Hi Justin, Felix, and others, I keep hearing that the bar for a committer is too high for our project. Could you clarify what would be considered too low of a bar for a committer? Or, if there is some document that I am not aware of that explains this, that would be great too. I feel that we need good upper and lower bounds for this so that we are all on the same page on who qualifies to be a committer. Additionally, this way, when we submit a new committer, we can state the milestones that they have reached that makes us confident with them as a new committer and most would agree. I would rather we don't bounce back and forth between, too high and too low. Thanks! John On 2021/12/18 11:55:12 Justin Mclean wrote: > Hi, > > > Because of the nature of the project, committers require a broad range of > > expertise in several areas including: Database (Postgres and SQL), Graph > > Technology and Cyper, C language. While many contributors demonstrated > > expertise in some areas, few had expertise in all disciplines. In addition > > we restricted committer status to those who demonstrated consistent > > contribution to the project over many months and across multiple and > > diverse challenges. We felt this was the most prudent way to build a strong > > and tight community. > > IMO that bar is far too high, and I suggest the project needs to lower its > bar. No one should have to be an expert in all areas to become a committer in > a project. It would also be best to consider committers than contribute > things other than code. > > Kind Regards, > 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: 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
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
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) 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
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
