Re: [VOTE] Accept Fury Into the ASF Incubator
+1 (binding) On Fri, Dec 8, 2023 at 5:05 AM tison wrote: > Hi Incubator > > Following the discussion [DISCUSS] Incubating Proposal of Fury [1], I > am starting this official vote for the Fury project. > > Here is their proposal: > https://cwiki.apache.org/confluence/display/INCUBATOR/Fury+Proposal > > Please cast your vote: > > [ ] +1, bring into the Incubator > [ ] +0, I don't care either way > [ ] -1, do not bring Fury into the Incubator, because... > > The vote will open for one week from today, Dec. 8th, 2023 > > Best, > tison. > > [1] https://lists.apache.org/thread/jr3qwzxg2m6507zsll5fs8mopcco3ny3 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Incubating Proposal of Fury
Is there any docco/comparison that we can read, comparing Fury to Apache Thrift and Apache Avro? On Fri, Dec 1, 2023 at 3:01 AM tison wrote: > Hi IPMC members, > > I would like to propose a new project to the ASF incubator - Fury. > > Fury[1] is a high-performance, multi-language, and automatic > serialization framework powered by JIT and zero-copy. > > Ant Group owns this project, and they have agreed to sign the SGAs and > CCLAs for the donation. > > Here is their proposal - > https://cwiki.apache.org/confluence/display/INCUBATOR/Fury+Proposal > > I would be the Champion of the project. > > I will mentor and help the project through the incubator with > PJ Fanning [fannin...@apache.org] > Yu Li [l...@apache.org] > Xin Wang [xinw...@apache.org] > > We are open to hearing the feedback from the incubator. > > Best, > tison. > > [1] https://github.com/alipay/fury > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Tison: STOP cross-posting between private and public lists. You have been advised to stop doing so once, and this is now TWICE. No more. Regards, Greg Stein Infrastructure Administrator, ASF On Mon, Jul 3, 2023 at 6:01 AM tison wrote: > Hi Daniel, > > Thanks for your information! That can be an alternative for the signing > key. > > Right now the blocker I met is 403 from the Nexus server which I suspect is > the lack of permissions from the Nexus credentials. Could you confirm or > correct it? > > Best, > tison. > > > tison 于2023年7月3日周一 18:58写道： > > > Hi PJ, > > > > Thanks for sharing your thoughts! > > > > For signing key, it's a resolved topic from my perspective. I use - > > > > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1] > > 2. Load the key from our 1password service, while since it's a specific > > key, I feel comfortable to pass it to INFRA member and configure as a > > secret alternatively. > > > > Best, > > tison. > > > > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS > > > > > > PJ Fanning 于2023年7月3日周一 18:52写道： > > > >> Adding the Incubator general list. > >> > >> My view would be that non-snapshot binary artifacts should be signed > >> with a personal signing key - ideally the signing key that was used to > >> release the related source release. Unfortunately, this would mean > >> adding a user's signing key to the Apache GitHub account as a secret > >> so that the automated GitHub Action job could access it. I don't see > >> how we could allow personal signing keys to be added like this. > >> > >> On Mon, 3 Jul 2023 at 10:18, tison wrote: > >> > > >> > cc security > >> > > >> > Missed in the first place. > >> > > >> > Best, > >> > tison. > >> > > >> > > >> > tison 于2023年6月29日周四 22:21写道： > >> >> > >> >> Hi security team members, > >> >> > >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding. > >> >> > >> >> I already verify that GitHub Actions work well for automatically > >> deploying OpenDAL Java binding[2]. > >> >> > >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a > >> problem that deploying Maven projects requires NEXUS credentials. For my > >> personal repo, I can config my Apache ID and password as secrets. For > >> apache repos, it requires handing over the credentials to INFRA team > >> member. Even I can trust the member, it's a bit less than awesome. > >> >> > >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and > >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only. > >> INFRA member suggested me to consult security team for approval for such > >> automatic deployment and they would help to grant related permissions if > >> approved. > >> >> > >> >> Please help review the request to support ASF projects deploying > Maven > >> project via GitHub Actions. > >> >> > >> >> Best, > >> >> tison. > >> >> > >> >> [1] http://github.com/apache/incubator-opendal > >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752 > >> >> [3] > >> > https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192 > >> >> > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> >
Re: [QUESTION] do pom files need to have a license header
The source archive/tarball includes a LICENSE and NOTICE which specifies the license for that artifact. The individual files' header simply reinforces that. In some release artifacts, individual files have a slightly different license (eg. a third-party MIT-licensed piece of source), which definitely needs to be recorded within those files. IMO, it is just fine for the pom file to not contain a license header, since the entire distribution is licensed as ALv2. Cheers, -g On Sun, Jan 29, 2023 at 11:31 AM PJ Fanning wrote: > Hi everyone, > > The Apache Pekko builds use the sbt tool for building and this generates > pom files for us. They do not include any headers (example [1]). > It seems the norm to add an XML comment with Apache License info (example > from log4j [2]). > Does the Pekko team need to fix this or is it just a nicety to have the > license header in the pom files? If the answer is that we do need to fix > this, does this also apply to other published files? sbt generates and > publishes a 'buildinfo' file as part of the maven publish (example [2]). > > Regards, > PJ > > > [1] > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-actor_2.13/0.0.0+26546-767209a8-SNAPSHOT/pekko-actor_2.13-0.0.0+26546-767209a8-SNAPSHOT.pom > [2] > https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.19.0/log4j-api-2.19.0.pom > [3] > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-actor_2.13/0.0.0+26546-767209a8-SNAPSHOT/pekko-actor_2.13-0.0.0+26546-767209a8-SNAPSHOT.buildinfo > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Incubating Proposal for Pekko
Sheng Wu is correct. I was a Mentor for the Apache Fineract project. Never read the dev@ list, never checked out the code. They graduated, and I didn't join the PMC. But I happen to still be subscribed to their mailing list to offer historical perspective/advice. There are many ways to contribute to a community and commit/coding doesn't have to be the only path. Cheers, -g On Fri, Sep 30, 2022 at 3:36 AM Sheng Wu wrote: > I think mentors don't have to be committers. > Just some initial committers could be mentors. This is not required. > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > Claude Warren, Jr 于2022年9月30日周五 16:20写道： > > > > Is is standard for mentors to be committers on the project? And should > > they be listed in both sections. > > > > Claude > > > > On Fri, Sep 30, 2022 at 9:15 AM Claude Warren, Jr < > claude.war...@aiven.io> > > wrote: > > > > > Tison, > > > > > > I send the email yesterday before submitting the proposal. Thanks for > the > > > heads up though. > > > > > > As to the other part, I think I will remove myself from the committer > list > > > at this time. > > > > > > On Thu, Sep 29, 2022 at 6:23 PM tison wrote: > > > > > >> Hi Claude, > > >> > > >> Thanks for starting this discussion! +1 to this proposal. > > >> > > >> It answers my previous questions on > > >> https://lists.apache.org/thread/hdknoyvr9c0d4j70xqw6t2t7gnbzc7nq a > new > > >> name + a clear goal. > > >> > > >> I'm interested to act as a mentor to help with this podling's growth. > > >> > > >> w.r.t the membership, I notice that Claude Warren and PJ Fanning are > > >> listed > > >> on both initial committers and mentors, while other mentors don't. > Perhaps > > >> you should check what's the intention here. > > >> > > >> Also, Claude Warren (you) and PJ Fanning are Apache members who can > become > > >> IPMC members with a notice, but it still needs to go through the > > >> process[1][2]. > > >> > > >> Best, > > >> tison. > > >> > > >> [1] > > >> > > >> > https://incubator.apache.org/guides/roles_and_responsibilities.html#incubator_project_management_committee_ipmc > > >> [2] https://lists.apache.org/thread/t6k3mg97pyshzoxzjg4c62n166l3crcw > > >> > > >> > > >> > > >> Jean-Baptiste Onofré 于2022年9月29日周四 23:36写道： > > >> > > >> > Hi Claude > > >> > > > >> > Very interesting. I would be more than happy to mentor this podling > (if > > >> > accepted of course). > > >> > > > >> > I will take a deeper look on the proposal wiki page. > > >> > > > >> > Thanks ! > > >> > > > >> > Regards > > >> > JB > > >> > > > >> > Le jeu. 29 sept. 2022 à 16:57, Claude Warren, Jr > > >> > a écrit : > > >> > > > >> > > Greetings, > > >> > > > > >> > > I would like to propose Pekko [1] as a new Apache Incubator > project. > > >> > > > > >> > > Pekko is a toolkit that brings the actor model (popularised by > > >> Erlang) to > > >> > > the JVM, providing the basis for building both locally and > distributed > > >> > > concurrency. On top of this Pekko provides a rich set of libraries > > >> built > > >> > on > > >> > > top of Actors to solve modern problems, including: > > >> > > > > >> > > > > >> > >- Streams: Fully bi-directional backpressured streams > following the > > >> > >Reactive manifesto > > >> > >- HTTP: A fully streamed HTTP client/server built on top of > streams > > >> > that > > >> > >also provides expected tools (such as connection pooling) > necessary > > >> > for > > >> > >highly available web services > > >> > >- connectors: A rich set of connectors for various databases, > > >> > messaging, > > >> > >persistent services built on top of streams > > >> > >- grpc: A gRPC server/client > > >> > >- projection: Provides abstractions necessary for CQRS pattern > > >> such as > > >> > >envelope, necessary for systems such as Kafka. > > >> > > > > >> > > > > >> > > > > >> > > Controversially Pekko is a fork of the Akka project just prior to > its > > >> > > licence changed from Apache 2 to Business Source License 1.1. > > >> > > > > >> > > I look forward to your feedback and discussions, > > >> > > > > >> > > Thank you, > > >> > > Claude Warren > > >> > > [1] > > >> https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoProposal > > >> > > > > >> > > > >> > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: possible interest in forming a community fork of akka
On Tue, Sep 27, 2022 at 4:55 AM PJ Fanning wrote: >... > In some cases, the critical fix might be submitted to the fork first > and it may be easier for the Lightbend team to cherry pick those cases > than it is for the fork team to do the opposite. > Should an ALv2 fork arise *anywhere*[1], then I believe Lightbend's community will vaporize. That community will follow the OSS fork, and Lightbend will be relegated to picking up those ALv2-licensed patches into their proprietary version. There will simply be no reason for a community to hang around and contribute their work to the newly-licensed and proprietary version of Akka. Cheers, -g [1] whether at the ASF, or at an external hosting site. Note that, historically, the ASF has been mostly against forks where the owner(s) disagree with creating that fork (aka "a hostile fork").
Re: terminology (was: [DISCUSSION] Incubating proposal of Kvrocks)
Oh, sure. That totally works! On Tue, Apr 26, 2022 at 10:14 PM tison wrote: > Hi Greg, > > Thanks for pointing that out. Is "5 IPMC members" correct also? "5 members > of the IPMC" is a bit wordy, though. > > Best, > tison. > > > Greg Stein 于2022年4月27日周三 10:52写道： > > > I have a problem with the terminology some people are using: > > > > On Thu, Apr 14, 2022 at 10:28 PM tison wrote: > > >... > > > > > 3. The proposal wants to run this podling with 5 IPMCs, > > > > > > There is ONLY ONE IPMC. aka the Incubator Project Management Committee. > > > > ONE. > > > > IPMC refers to the committee. > > > > The use of "IPMC" to refer to a *MEMBER* of the IPMC is erroneous. The > > correct phrase is "5 members of the IPMC". > > > > NOTE: I have seen this elsewhere. A "PMC" is a committee. It is NOT A > > PERSON. > > > > -g > > >
terminology (was: [DISCUSSION] Incubating proposal of Kvrocks)
I have a problem with the terminology some people are using: On Thu, Apr 14, 2022 at 10:28 PM tison wrote: >... > 3. The proposal wants to run this podling with 5 IPMCs, There is ONLY ONE IPMC. aka the Incubator Project Management Committee. ONE. IPMC refers to the committee. The use of "IPMC" to refer to a *MEMBER* of the IPMC is erroneous. The correct phrase is "5 members of the IPMC". NOTE: I have seen this elsewhere. A "PMC" is a committee. It is NOT A PERSON. -g
Re: Can we use the GitHub's "transferring a repository" feature after IP clearance
On Wed, Nov 24, 2021 at 1:24 AM Dominik Riemer wrote: > Hi, > > we used the "transfer repository" feature when we were transferring > StreamPipes to the incubator, which worked smoothly. > Infra performs the transfer upon request, the only requirement is that you > are able to add someone from Infra as an owner to your existing repository, > as only Infra can initiate the transfer due to access rights. > This is correct. Sometimes the repository-to-transfer is in an Organization that will not allow Infra to become an owner (for example, a bank). For those cases, we use an intermediate Organization where an owner of the repo-to-transfer can be added as an admin to that intermediate. They can then transfer from the closely-held Organization to the intermediate. Then Infra will move it one more time into the Apache Organization on GitHub. This is pretty routine, and just requires an INFRA ticket with links to any votes/approvals for the move into the Apache org. Cheers, Greg Infrastructure Administrator, ASF
Re: [WEBSITE] More Fully Move to Git
Branches for a purpose are appropriate. Avoiding that tool/feature, and (say) using distinct repositories is a version control anti-pattern. Cheers, -g On Fri, Aug 6, 2021, 03:59 Bertrand Delacretaz wrote: > Hi Dave, > > On Thu, Aug 5, 2021 at 6:39 PM Dave Fisher wrote: > > ...In Pelican we will have two branches for each directory... > > Just a quick comment on this: I often get crazy with repositories > which use multiple branches "for production use" as they are often not > discoverable. > > If you go this route (which might be perfectly valid) please make sure > to add a big info block to the main or master branch README so people > see what's going on! > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Retire BlueMarlin project from Incubator
+0 to retire (binding) On Sun, Feb 21, 2021 at 7:32 AM Sheng Wu wrote: > Hi IPMC > > This is an official vote for retiring the BlueMarlin from the incubator. > We had several discussion about this > - general@incubator, > > https://lists.apache.org/list.html?general@incubator.apache.org:lte=6M:BlueMarlin > - private@incubator, > > https://lists.apache.org/thread.html/r84b334ac2bd7a21fa53556ecbe32e39adf12a6fab437196abb105fa7%40%3Cprivate.incubator.apache.org%3E > > The project has few activities except Jan.'s report. No process about > codes, and no response on the mail list. > > I want to start this official vote. > > Voting will start now and will remain open for at least 72 hours, > [ ] +1 Retire the project > [ ] +0 No opinion. > [ ] -1 Do not retire the project because... > > Sheng Wu 吴晟 > Twitter, wusheng1108 >
Re: Travis job on github
On Wed, Feb 3, 2021, 01:36 Weiwei Yang wrote: >... > we can communicate with Microsoft about giving the Apache > repo some extra resources. > I guess it won't be a big problem to such a wealthy company > Their wealth does not mean they can give us anything we want. That is a fallacy. Their wealth means they can be kind to us, and we should be thankful. Microsoft is extremely generous to the Foundation, across many paths (sponsorship, Azure, MSDN, etc). Let us not presume that we can keep asking for more. Regards, -g
Re: svn commit: r1878377 - /incubator/public/trunk/content/podlings.xml
Yeah, sorry about the intrusion. Infra took a quick workaround, but we'll fix our tools instead, for the next time. Won't happen again. Regards, Greg InfraAdmin, ASF On Mon, Jun 1, 2020 at 3:53 PM Dave Fisher wrote: > No, why? Please revert this. > > Please discuss with the Petri PMC. > > Sent from my iPhone > > > On Jun 1, 2020, at 1:37 PM, c...@apache.org wrote: > > > > Author: cml > > Date: Mon Jun 1 20:37:10 2020 > > New Revision: 1878377 > > > > URL: http://svn.apache.org/viewvc?rev=1878377=rev > > Log: > > treat petri project more like a podling > > > > this will need to be broken out into a separate petri.xml or something > at some point in the future > > > > > > Modified: > >incubator/public/trunk/content/podlings.xml > > > > Modified: incubator/public/trunk/content/podlings.xml > > URL: > http://svn.apache.org/viewvc/incubator/public/trunk/content/podlings.xml?rev=1878377=1878376=1878377=diff > > > == > > --- incubator/public/trunk/content/podlings.xml [utf-8] (original) > > +++ incubator/public/trunk/content/podlings.xml [utf-8] Mon Jun 1 > 20:37:10 2020 > > @@ -395,9 +395,8 @@ > > Yoav Shapira > > > > > > - resource="buildstream" sponsor="Petri" startdate="2020-06-01" > enddate="2020-06-01"> > > + sponsor="Petri" startdate="2020-06-01"> > > BuildStream is a Free Software tool for integrating > software stacks. > > - > > > > Justin Erenkrantz > > David Nalley > > > > > > > > - > > To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org > > For additional commands, e-mail: cvs-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [MENTORS] Podlings download pages with issues
On Wed, Mar 4, 2020 at 2:11 AM Justin Mclean wrote: >... > I guess given it's a recent change, not all projects projects are aware of > it or have made the changes yet. This change means most podling download > pages would need to change and I assume most TLP as well. > > As /dist has been deprecated, do we have an estimated date when it will be > turned off? > www.a.o/dist/ has been set up as redirects. So (generally) there shouldn't be a problem. Some automated scripts that don't understand redirects may see issues. ... Infra has no intent to delete those redirects to there is no "turned off" on the schedule. Updating pages across podlings and TLPs are simply to avoid downstream seeing redirects. Cheers, -g
Re: [MENTORS] Podlings download pages with issues
On Wed, Mar 4, 2020 at 1:01 AM Justin Mclean wrote: > Hi, > > Also I assume https://archive.apache.org/dist/ is still valid for older > releases? > Yes. Please stop trimming emails so much. Do you spend extra time just deleting context? Makes for a lot of extra work. So manually cut/paste your other email: On Wed, Mar 4, 2020 at 12:49 AM Justin Mclean wrote: > Hi, > > > www.a.o/dist/ is deprecated. Please use downloads.a.o/ > > Good to know. When did that change? All of the policy documentation still > refers to a.o/dist. A week-ish ago. Not "all". For example, http://www.apache.org/legal/release-policy.html has been updated. But we're continuing to fix up old references. The main point is that Infra wants to move any kind of download off the main TLP website servers. Cheers, -g
Re: [MENTORS] Podlings download pages with issues
Good work, Justin. One small comment:
On Tue, Mar 3, 2020 at 7:57 PM Justin Mclean
wrote:
>...
> if not href.startswith('https://www.apache.org/dist/')
> and not href.startswith('https://archive.apache.org/dist'):
> print("Please change link to " + href + " to go via
> https://www.apache.org/dist/ or https://archive.apache.org/dist;)
>
www.a.o/dist/ is deprecated. Please use downloads.a.o/
Cheers,
-g
Re: Incubator PMC members not subscribed to private list
IMO, involuntary mailing list subscription is not the right choice. ... Just take your list of AWOL non-responders to the Board, and ask if there are any objections to placing them on a "removal" resolution for the February meeting. The Board may provide some guidance/steps to take. Or they may say "roll with it. submit a resolution". In other words, go with the least imposition on the missing IPMC peeps. Assume they're just not interested, so they didn't respond to you. Putting them onto a mailing list could anger them (think about it: would you be happy, if I subscribed you to (say) priv...@tomee.apache.org?). And take the position they can be re-added to the IPMC, any time, if the (upcoming) removal happened to be in error. Cheers, -g On Tue, Jan 21, 2020 at 5:24 PM Justin Mclean wrote: > Hi, > > > There is another (perhaps more obvious) solution and that is to sign > these people up to the mailing list. > > I’ve not had any feedback on this, so unless someone else has some input, > I’m going to assign lazy consensus applies and this is what I’m going to do: > > 1. Subscribe all missing IPMC members to the private list > 2. If some complain ask if they want to continue to be IPMC members > 3. If too many complain, remove them and discussion with the board on the > possibility of removing these IPMC members. This would involve contacting > them again so they are clear on what would happen if they don’t sign up. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: How to subscribe (was: Incubator PMC members not subscribed to private list)
On Thu, Jan 16, 2020 at 9:10 PM Dave Fisher wrote: > Hi - > > Sent from my iPhone > > > On Jan 16, 2020, at 6:56 PM, Justin Mclean > wrote: > >... > > In the case of people asking to be removed from the IPMC, they are > removed from the roster, this is reported in the next Incubator board > report and if there no objections from the board they would then be > considered non longer IPMC members. So a roster may not 100% accurately > reflect who is actually a IPMC member at a point in time. > > > > What we would be doing is removing people from the roster who have not > signed up to the private list and they can be added back to the roster by > performing one simple action. We would not be asking the board to remove > them from the IPMC. > There is no distinct "roster" and "membership". The canonical "source of truth" on committee membership is committee-info.txt. Everything falls out from that. The "roster" that Whimsy displays. How LDAP gets configured. etc. The Foundation uses that file to record changes, and membership. Removing somebody from that file can only be performed via Board resolution. (of course, unless you mean something else by "roster") I think that without an explicit resignation they must remain IPMC members. > The only exception would be those who have gone emeritus or have passed on. > The driver is membership. > Disagree. That does not comport with history/precedent. See below. > An IPMC Member who is not a Member and is no longer subscribed should be > consider individually on private@i.a.o. > > The Board evaluates PMCs via roll calls on private@. I’m not aware of > cases of PMCs throwing people off w/o a resignation and as you Justin > should be aware the Board goes to the extreme to prevent it. (The current > Board may differ from prior Boards, but let’s not test it!) > There have been a number of cases of involuntary removal. Although I'm using "involuntary" in only the loosest sense here, because the people indicated no desire one way or another. About 15 people were removed from the Apache HTTPD PMC in November 2014: http://www.apache.org/foundation/records/minutes/2014/board_minutes_2014_11_19.txt There have been a couple other cases, too. Let me also fine-tune a statement above, Dave: "cases of PMCs throwing people off". That is not possible. Only the Board can do that. > Alternatively do any of the board members here think that not signing up > to the private mailing list is grounds for removal from a PMC? Where they > actually on it in the first place? > I cannot speak for the Board, but I believe they would be amenable to removing those IPMC members, if and only if, there have been one or more attempts to reach out to them. The Apache HTTPD spent a year or two, with several calls to see if anybody wanted to remain. The 15 delivered to the Board was the result of that activity. As you can see from the Minutes, the Board approved the resolution and removed all 15. Cheers, -g
Re: How to subscribe (was: Incubator PMC members not subscribed to private list)
On Thu, Jan 16, 2020 at 9:59 AM Nathan Hartman wrote: >... > This should be documented clearly under expectations from IPMC members. If > there is a period of inactivity after which IPMC members will be removed, > then people should know this up front. > Only the Board can remove members from a PMC, and "lack of activity" not one they typically support. They _have_ supported "we reached out several times over the course of a year, and got no response" as valid. ... The consideration for IPMC member removal might be a bit lower for the IPMC since it is (currently) has a low bar for joining for ASF Members. As Justin notes elsethread, the random "IPMC person pops up for activity one week, then goes silent for two years" is a valid and supported pattern. Cheers, -g
Re: Incubator PMC members not subscribed to private list
On Thu, Jan 16, 2020 at 7:41 AM Trevor Grant wrote: > @Greg, I would echo Ning's point. > I saw Ning's post before my own response, and (frankly) have little sympathy. Email exists to ask questions and solve problems. "I can't get subscribed. Please help" is very easy to send. If a member of the IPMC has not bothered, then they are not fulfilling their responsibilities. I am also guessing that Justin is only considering members of the IPMC that joined (say) more than a year ago. So we could say "if you want to join the IPMC, we'll give you an ENTIRE YEAR to figure out how to join one of the mailing lists at Apache". ... and to return to my original point: no sympathy. If "you" cannot figure out how to subscribe to an Apache mailing list over the span of a mere week, then what are you doing as an IPMC Member and/or Mentor? Personal responsibility. Step up. Figure it out. Get it done. -g
Re: Incubator PMC members not subscribed to private list
In the past, I've made my position clear: if an IPMC member cannot be bothered to get themselves subscribed to the private list, then they are not providing appropriate oversight, and (thus) should be removed from the PMC. They can continue to contribute via the general@ list, but lose their (binding) status due to removal from the IPMC. Cheers, -g On Wed, Jan 15, 2020 at 11:25 PM Justin Mclean wrote: > Hi, > > I can see a couple of people have signed up and a couple of inactive IPMC > members have asked to be removed. However we still have a large number of > IPMC members are still not subscribed to the private list. > > A possible idea. Do we want to consider the drastic step of removing all > IPMC from the PMC who are not signed up to the private mailing list? They > could re-instated themselves by subscribing to the private list. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Accept NuttX into the Apache Incubator
+1 (binding) On Tue, Dec 3, 2019 at 11:30 PM 俊平堵 wrote: > Hi folks, > > > The [DISCUSS] thread on NuttX has died down. > > > Accordingly, I would like to call a VOTE to accept NuttX into the > > Apache Incubator. > > > Please cast your vote: > > > [ ] +1, bring NuttX into the Incubator > > [ ] +0, I don't care either way > > [ ] -1, do not bring NuttX into the Incubator, because... > > > The vote will open at least for 72 hours and only votes from the > > Incubator PMC are binding, but votes from everyone are welcome. > > > =Abstract= > > NuttX is a mature, real-time embedded operating system (RTOS). It has wide > usage in IoT projects, control systems, robotics, drones, and many other > systems. Unique properties of NuttX are its strict adherence to standards > and its scalability. NuttX follows the Unix standards as defined > by OpenGroup.org (POSIX, ANSI, and others). This allows for a high degree > of portability. Scalability is supported through a configuration system > that allows NuttX to run on the smallest embedded platforms and through > high end single board computers. > > > =Proposal= > > NuttX was released under a BSD 3-Clause license on February 17, 2007. From > that time until now it has been managed by a single person, Gregory Nutt. > The user base of NuttX has grown to probably thousands of projects and > perhaps a hundred active developments at any time. The code base has grown > to around 1.5 million lines of code (according to OpenHub.com). > > NuttX has benefited from this single person management because this has > resulted in a consistent architecture and controlled growth. But now it is > time to open this project to the participation of others because this > consistent architecture assures solid future growth, and because the > magnitude of effort required to support the RTOS exceeds the capability of > a single person, but also because users of NuttX require a stable road map > going forward that does not depend on a single person. > > For these reasons, I propose that NuttX enter the Apache Incubator as a > first step in opening the project to wider participation. > > > =Initial Goals= > > The initial goal will be to move the existing BSD code base to Apache and > integrate with the Apache development process and infrastructure. A primary > goal of incubation will be to grow and diversify the NuttX community. We > will convert that code base to the Apache license during incubation. > > > =Current Status= > > As previously mentioned, NuttX is a mature, stable product in wide use in > embedded products. > > > ==Meritocracy== > > We value meritocracy and we understand that it is the basis for an open > community that encourages multiple companies and individuals to contribute > and be invested in the project’s future. We will encourage and monitor > participation and make sure to extend privileges and responsibilities to > all contributors. > > Being a mature project, NuttX already has an extensive user base with many > people who understand the software, who have committed hundreds of changes, > and are happy to participate in the project. I believe that with a little > guidance and formalization, a PMC and a large group of experienced > committers can quickly be established. > > > ==Community== > > NuttX has a large, active community. Communication is via a Google group > at https://groups.google.com/forum/#!forum/nuttx where there are 395 > members as of this writing. Code is currently maintained > at Bitbucket.org at https://bitbucket.org/nuttx/. Other communications > are > through Bitbucket issues and also via Slack for focused, interactive > discussions. > > Keeping up with the communications, requests for help, issues, and > contributions is more than a full time job at this time. > > > ==Core Developers== > > NuttX was initially developed by Gregory Nutt, released as an open source > project on February 17, 2007, and is still under active development. There > are several dozen, active, frequent contributors involved with the project. > The core OS can be considered finished at this point, but development > continues in specialized areas of networking, IoT, cryptography, tools, and > other more specialized functions. > > > =Alignment= > > NuttX is an original development with some small percentage of ported > code. It stands alone depends on no other projects. > > > =Known Risks= > > ==Orphaned Products== > > We are committed to the future development of NuttX and understand that > graduation to a TLP, while preferable, is not the only positive outcome of > incubation. > > Should the NuttX project be accepted by the Incubator, the prospective PPMC > would be willing to agree to a target incubation period of 2 years or less, > knowing that every Incubator project incurs a certain cost in terms of ASF > infrastructure and volunteer time. > > > ==Inexperience with Open Source== > > None of the initial committers are Apache members and we will need some >
Re: [DISCUSS] NuttX Proposal
I say just move to a vote and stop the second-guessing. GNutt seems on-board. Let them get their stuff done. On Mon, Dec 2, 2019 at 5:23 PM Alex Harui wrote: > Might be less risk and disruption for a few experienced ASF folks to go > "live amongst" the NuttX folks where they are now and verify that that the > founder's authority and reputation will not result in a BDFL effect. > > Just a thought, > -Alex > > On 12/2/19, 12:48 PM, "Ted Dunning" wrote: > > Very well said. > > I am optimistic. > > On Mon, Dec 2, 2019 at 9:26 PM Gregory Nutt > wrote: > > > > > > This is a good discussion to have had before entering the > incubator, and > > I'm satisfied that the intent is good, and the podling can > demonstrate > > during incubation that the founder will in fact step back and allow > the > > project to move forward without the founder's undue influence. > > > > > > Note that it's fine for the founder to continue to work on the > project, > > but in a different role. > > > > I have been standing back and not getting deeply involved with this > > discussion because it pertains too closely to me. It is my > intention to > > divest myself of total authority over the project just as stated in > the > > Proposal. Further, it is my intention to stay out of the initial > > formation of the project as much as possible, in partial fulfillment > of > > Ted Dunning's "thought experiment." I intend to vote 0 on all > decisions > > before the PPMC -- unless, I suppose, I had some very strong opinion > > about some topic. I cannot imagine what topic that might be, > however. > > > > I will be available as needed for information needed by the others to > > accomplish this transition but for the most part, just consider me > as on > > vacation in place. I will help as much as needed and stay out of the > > way as much as possible. > > > > I suppose I should say a little more about my motivations in this. > > Without some understanding, is is reasonable to be skeptical. Yes, > the > > project is very dear to me and the result of many years of blood, > sweat, > > and tears and years of work mostly done alone for crazy long hours. > > Being a "benevolent dictator" does not proper describe my past role > > because I was the ONLY person on the project. I did everything. I > > still do. > > > > There are two things that motivate me: First, the workload has > gotten > > to be far too much for one person. I dispose of around 60-100 > changes > > per week and really have no personal life left. It is more than I > can > > do (and much more than I can do well). The only real way to solve > that > > is to open the project up to others working as equals. The second, > and > > more important, motivation is the I am closing in on 70 years old > now. > > I retired 8 retires ago and I cannot realistically control this > project > > long into the future. For my personal health and sanity, I really > need > > to detach and let the project take a life of its own that does not > > depend on me in any way. > > > > I would see the biggest risk to a new PPMC would not be me, but > rather > > the sheer volume of work that the PPMC is stepping into. I am > prepared > > for some initial chaos and perhaps a missed release cycle. But I > have > > come to accept that that is a reasonable price to pay for a clean > > knife-edge hand-off. > > > > Greg > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > >
Re: [DISCUSS] NuttX Proposal
The initial five works for me. I see no reason to add more at this time. It would only be a block for graduation, not inception. To rephrase: some may have an issue with five, but I bet you'll get enough +1 votes as-is. Cheers, -g On Sun, Dec 1, 2019 at 6:39 PM 张铎(Duo Zhang) wrote: > I think it just because that it will spend more time... > > So what is the suggested initial committer number for NuttX? We can try to > get even more but is this necessary? The plan is to expand the committers > quickly during the incubation time, follow the Apache way, and also the > IPMCs can observe whether there are problems when electing new committers. > > Thanks. > > Justin Mclean 于2019年12月2日 周一07:56写道： > > > Hi, > > Given I assume there are other contributors why not make them initial > > commitors? > > Thanks, > > Justin > > > > On Mon, 2 Dec 2019, 10:45 Duo Zhang, wrote: > > > > > The proposal on the wiki page has already listed five initial > committers. > > > > > > And I think we can let the initial committers reply here to confirm > that > > > they will be active, at least in the early time in the incubator, > before > > we > > > elect new PPMC members. > > > > > > Does this solve your concerns? Thanks Dave. > > > > > > Dave Fisher 于2019年12月2日 周一01:38写道： > > > > > > > I share Ted’s concerns. > > > > > > > > It would help if the initial committer list was greater than the bare > > > > minimum of three. Three PPMC members is not enough. There needs to be > > at > > > > least five committers to start. > > > > > > > > (Should there be an explicit minimum in the proposal template?) > > > > > > > > It’s often the case that some initial committers do not actually > > > > transition to the incubating podling. > > > > > > > > Regards, > > > > Dave > > > > > > > > Sent from my iPhone > > > > > > > > > On Dec 1, 2019, at 9:16 AM, Ted Dunning > > wrote: > > > > > > > > > > I doubt that the name is the crucial issue. I would see that have > a > > > > > substantial group of initial committers who are active in setting > up > > > > there > > > > > project would be the crucial step. That doesn't have to happen > before > > > > > incubation. > > > > > > > > > > As a thought experiment, if Greg could go on a disconnected > vacation > > > > right > > > > > now without messing up the move to Apache, I would have no worries. > > > That > > > > is > > > > > almost certainly not true, but it can serve to illuminate the > factors > > > > that > > > > > make it not true. Is the decision-making centralized? Are there > > > > problematic > > > > > thoughts about retaining a high bar to committee status? Do > community > > > > > members automatically defer to Greg rather than move forward on > > > > decisions? > > > > > Are non-coders excluded from committer status? > > > > > > > > > > I don't know the answers to these questions, but I have a very > strong > > > > > expectation that this will be harder to address than expected so it > > is > > > > > really good that this has already been identified and there are > some > > > > > actions in progress. The only thing I can really add is that the > > > > community > > > > > members probably don't yet know how big a deal this will be and the > > > > Apache > > > > > folks probably assume more cultural transfer than has actually > > > happened. > > > > > > > > > > > > > > > > > > > >> On Sat, Nov 30, 2019, 11:43 PM Justin Mclean < > > > jus...@classsoftware.com> > > > > >> wrote: > > > > >> > > > > >> Hi, > > > > >> > > > > >>> Having a project that seems to have the name of a prominent > > community > > > > >>> member seems to pose a risk that there is a benevolent dictator > > > pattern > > > > >> at > > > > >>> work here. > > > > >> > > > > >> Greg is aware of the “no dictators rule" and has already answered > > this > > > > in > > > > >> this thread. He willing to hand over responsibilities to the wider > > > > >> community and give up his trademark. > > > > >> > > > > >> Do you think it would be a good idea to change the name of the > > > 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 > > > > > > > > > > > > > >
Re: [DISCUSS] NuttX Proposal
Hi Greg :-) On Fri, Nov 29, 2019 at 7:05 AM Gregory Nutt wrote: > > >> I imagine that it will take a month or two to get the GitHub > repositories ready for prime time. > > The physical transfer shouldn’t take that long, fixing up all the > headers and licenses may take longer but that’s OK when using the work in > progress disclaimer, you can makes incubating ASF release that don’t fully > comply with ASF policy when including that disclaimer. > Yes, releasing with a disclaimer should work and cut the transition > period down to a few weeks. For that transition time, I am not thinking > about physically moving the repositories. That should be quick. But > getting the organization and workflow in place to manage commits will > take a little time. Everyone is new at this except me and I am the bad > example. > I'd suggest setting a "flag day" and mark the bitbucket repository read-only, and then clone/push a copy onto gitbox.a.o. It will then sync over to GitHub, and work can continue with either of those repositories (GH is easier, but there are a few who don't like the GH T, so elect to stick to gitbox.a.o for work). You can make "non-Apache" releases as you used to, just based on a different repository. Then, one day, you can start making Apache releases. We did this with Subversion, and Apache Subversion. We continued to make 1.6.x Subversion releases (on our old release/distro platform; based on source in the ASF's repository), and then we started making 1.7.x Apache Subversion releases. Eventually, our support policy EOL'd the 1.6.x line, and all releases were just Apache Subversion releases. ... You could follow the same pattern with NuttX releases, and Apache NuttX releases. >> with changes pulled into the Apache Github until such time that support > can transition seamlessly to GitHub. > > Im not sure how easy that’s going to be, generally infra have made a > single transfer and I’m not aware of any projects that tried this approach. > It would require some discussion with infra to see what’s possible here. > > If it is not possible to automate this, then changes originated from old > retiring Bitbucket could be handled as normal PRs. That is not unusual. > The Apache Infrastructure team has no tooling to synchronize with third-party git repositories. We only have tooling to keep gitbox.a.o and GitHub in sync. Cheers, Greg Stein Infrastructure Administrator, ASF (and IPMC member)
Re: [DISCUSS] NuttX Proposal
On Sun, Dec 1, 2019 at 11:38 AM Dave Fisher wrote: >... > It would help if the initial committer list was greater than the bare > minimum of three. Three PPMC members is not enough. There needs to be at > least five committers to start. > Read the thread in its entirety, please. It has already been expanded to five. And more can join while incubating. I'm +1 (binding) on the proposal, with its current list of committers/mentors. (ie. when the [VOTE] comes up) Cheers, -g
Re: [GitHub] [incubator] justinmclean merged pull request #53: bold table title and fix footer spacing
On Wed, Nov 27, 2019 at 2:41 AM Justin Mclean wrote: > HI, > > > should these go to commits@incubator, rather than general@ ? > > I just filter to the same mail folder, but happy to have that change > happen. Do I need to raise a JIRA or can you do it? > Infra requests a [thread] link to consensus from the PMC on such a change. So let's go with lazy consensus. Anybody _opposed_ to sending github PRs and commits to commits@ ? ... 72 hours. Cheers, -g
Re: [GitHub] [incubator] justinmclean merged pull request #53: bold table title and fix footer spacing
should these go to commits@incubator, rather than general@ ? On Tue, Nov 26, 2019 at 11:09 PM GitBox wrote: > justinmclean merged pull request #53: bold table title and fix footer > spacing > URL: https://github.com/apache/incubator/pull/53 > > > > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > > With regards, > Apache Git Services > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator release area clean up
On Sat, Nov 16, 2019 at 5:16 PM Justin Mclean wrote: >... > There is a possible alternative and that is to not have a incubating area > and have all projects just use /dist/dev/ and > /dist/release/. That way no clean up would be needed. The > releases still have incubator disclaimers and are likely downloaded from > places where it obvious they are incubating projects. But I assume their > may be some permission issues with this approach? > This *can* be done, without problem. IPMC would just be responsible for multiple dev/release areas. Not an issue. We auto-generate ACLs for the areas, so it may take a little work to figure this out, but it's a Simple Matter of Programming :-) With that said, and with my Infra hat on, I'd like to see a thought from the Legal peeps on whether the incubator/ directory structure layout is a requirement (to supplement the disclaimers). I know there are distinct opinions about what/how we host releases on our servers. Cheers, Greg InfraAdmin, ASF
Re: Incubator release area clean up
On Fri, Nov 15, 2019 at 12:18 AM Justin Mclean wrote: > Hi, > > > Ha! The Infra team was just talking about that today, with the retirement > > of Edgent and (cleanup of) Zipkin. Over the years, we've had mixed > signals > > about what to do with "Incubator releases" after a podling leaves the > > Incubator. Some have said "keep them; they are IPMC releases", or "they > > should follow the graduated podling to their TLP directories", or "just > > remove them”. > > Correct me if I’m wrong but any releases (in /dist/release) will be > archived and any releases in /dist/dev/ no longer need to be there as they > are RCs and the like. > Not wrong at all! .. everything on dist.a.o will be copied over to archive.a.o. Further, dist.a.o is mapped out of Subversion. So all of those releases are in there, forever. You can 'svn rm' all the dirs you listed, and they'll disappear off of dist.a.o. But not from archive.a.o or svn history. Discoverability/browsing/trimming/clean (DBTC) is the net effect, of your proposed change. No data loss. My request is simply that the DBTC has been found desirable by the Incubator over the past 15 years, in various forms/amounts, so it would be nice to see you plant a stake in the ground. Infra can then easily follow that, without having to wonder/ask. Cheers, -g
Re: Incubator release area clean up
Ha! The Infra team was just talking about that today, with the retirement of Edgent and (cleanup of) Zipkin. Over the years, we've had mixed signals about what to do with "Incubator releases" after a podling leaves the Incubator. Some have said "keep them; they are IPMC releases", or "they should follow the graduated podling to their TLP directories", or "just remove them". Could I suggest a paragraph or two, somewhere, to solidify the IPMC's position? Thanks, Greg InfraAdmin, ASF On Thu, Nov 14, 2019 at 5:56 PM Justin Mclean wrote: > Hi, > > If there is no objection, in a few days, I'm going to remove the following > directories for the incubator release area, as the project have either > graduated or retired: > > If a product want to remove this themselves, before I get to it, please go > ahead. > > https://dist.apache.org/repos/dist/dev/incubator/airflow/ > https://dist.apache.org/repos/dist/dev/incubator/apex/ > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/ > https://dist.apache.org/repos/dist/dev/incubator/asterixdb/ > https://dist.apache.org/repos/dist/dev/incubator/blur/ > https://dist.apache.org/repos/dist/dev/incubator/edgent/ > https://dist.apache.org/repos/dist/dev/incubator/gossip/ > https://dist.apache.org/repos/dist/dev/incubator/griffin/ > https://dist.apache.org/repos/dist/dev/incubator/htrace/ > https://dist.apache.org/repos/dist/dev/incubator/johnzon/ > https://dist.apache.org/repos/dist/dev/incubator/joshua/ > https://dist.apache.org/repos/dist/dev/incubator/kudu/ > https://dist.apache.org/repos/dist/dev/incubator/mrql/ > https://dist.apache.org/repos/dist/dev/incubator/netbeans/ > https://dist.apache.org/repos/dist/dev/incubator/odftoolkit/ > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/ > https://dist.apache.org/repos/dist/dev/incubator/plc4x/ > https://dist.apache.org/repos/dist/dev/incubator/predictionio/ > https://dist.apache.org/repos/dist/dev/incubator/quickstep/ > https://dist.apache.org/repos/dist/dev/incubator/rya/ > https://dist.apache.org/repos/dist/dev/incubator/sirona/ > https://dist.apache.org/repos/dist/dev/incubator/skywalking/ > https://dist.apache.org/repos/dist/dev/incubator/slider/ > https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/ > https://dist.apache.org/repos/dist/dev/incubator/unomi/ > https://dist.apache.org/repos/dist/dev/incubator/wave/ > https://dist.apache.org/repos/dist/dev/incubator/zipkin/ > > https://dist.apache.org/repos/dist/release/incubator/dubbo/ > https://dist.apache.org/repos/dist/release/incubator/edgent/ > https://dist.apache.org/repos/dist/release/incubator/joshua/ > https://dist.apache.org/repos/dist/release/incubator/netbeans/ > https://dist.apache.org/repos/dist/release/incubator/openwhisk/ > https://dist.apache.org/repos/dist/release/incubator/plc4x/ > https://dist.apache.org/repos/dist/release/incubator/rya/ > https://dist.apache.org/repos/dist/release/incubator/skywalking/ > https://dist.apache.org/repos/dist/release/incubator/unomi/ > https://dist.apache.org/repos/dist/release/incubator/zipkin/ > > Thanks, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
We're trying to do better on what services are available, so consider this "step one" :-) On Thu, Nov 7, 2019 at 1:19 PM Julian Feinauer wrote: > Thanks Greg, I didn't know that! > > Julian > > Am 07.11.19, 19:24 schrieb "Greg Stein" : > > > https://cwiki.apache.org/confluence/display/INFRA/Distribution+via+the+Apple+App+Store > > On Thu, Nov 7, 2019 at 12:14 PM Greg Stein wrote: > > > An app signed by the Foundation is most definitely associated with > the > > ASF. The Foundation has an Apple Developer Account for exactly this > reason. > > > > > > On Thu, Nov 7, 2019 at 9:17 AM Justin Mclean < > jus...@classsoftware.com> > > wrote: > > > >> Hi, > >> > >> A binary convenance release needs to be created from released voted > on > >> code. [1] > >> > >> However if some 3rd party (not the PPMC) wants to use unreleased > code and > >> make a “release” from it and put that somewhere but it needs to be > clear > >> that this is not in anyway associated with the ASF and it needs to > respects > >> ASF branding and trademarks.Doing [1] is probably easier so I > suggest you > >> go down that path. > >> > >> Thanks, > >> Justin > >> > >> 1. > http://www.apache.org/legal/release-policy.html#compiled-packages > >> > - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > >
Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
https://cwiki.apache.org/confluence/display/INFRA/Distribution+via+the+Apple+App+Store On Thu, Nov 7, 2019 at 12:14 PM Greg Stein wrote: > An app signed by the Foundation is most definitely associated with the > ASF. The Foundation has an Apple Developer Account for exactly this reason. > > > On Thu, Nov 7, 2019 at 9:17 AM Justin Mclean > wrote: > >> Hi, >> >> A binary convenance release needs to be created from released voted on >> code. [1] >> >> However if some 3rd party (not the PPMC) wants to use unreleased code and >> make a “release” from it and put that somewhere but it needs to be clear >> that this is not in anyway associated with the ASF and it needs to respects >> ASF branding and trademarks.Doing [1] is probably easier so I suggest you >> go down that path. >> >> Thanks, >> Justin >> >> 1. http://www.apache.org/legal/release-policy.html#compiled-packages >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
An app signed by the Foundation is most definitely associated with the ASF. The Foundation has an Apple Developer Account for exactly this reason. On Thu, Nov 7, 2019 at 9:17 AM Justin Mclean wrote: > Hi, > > A binary convenance release needs to be created from released voted on > code. [1] > > However if some 3rd party (not the PPMC) wants to use unreleased code and > make a “release” from it and put that somewhere but it needs to be clear > that this is not in anyway associated with the ASF and it needs to respects > ASF branding and trademarks.Doing [1] is probably easier so I suggest you > go down that path. > > Thanks, > Justin > > 1. http://www.apache.org/legal/release-policy.html#compiled-packages > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Open up incubator wiki to all committers
Generally/all: please stick to committers ... NOT confluence-users. The latter will bring down the spam. Thx, Greg InfraAdmin, ASF On Thu, Oct 10, 2019 at 4:40 AM Myrle Krantz wrote: > Hey all, > > I just checked the Weex report for October, and while doing so, I realized > that I do not have edit rights to the incubator wiki. Rather than request > them now, I'd like to make a different suggestion: > > We should add the group "committers" with RW access (but not delete) to the > entire INCUBATOR space. > > We have, historically, spent rather a lot of time granting people access to > our wiki. > > But our recently implemented confluence-LDAP integration makes that > unnecessary. I made the COMDEV confluence space writable for all > committers. So far this has had several advantages and no disadvantages. > It's made it possible for committers of any project to enter themselves for > the ApacheCon EU hackathon without having to ask for permissions, and I > haven't seen any spamming of our spaces from this. > > Do you all see any reason we can't do the same for the incubator confluence > space? > > Best Regards, > Myrle >
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Wed, Aug 14, 2019, 06:00 Julian Feinauer wrote: > Hi Greg, > > I think Justins Answer refers to the WIP-Disclaimer Aware of that, but disagree. It is way more: the IPMC vote is performed to establish legal oversight and shield. I suggest that is burdensome and should be tossed. PS.: Allow me to add a very personal side note. But it seems to me that the > tone in this discussion is from time to time rather harsh. And I add to the harsh. Yes. Guilty. ... But it makes me angry to see misleading comments, and misdirection, away from the intent of my emails. Cheers, -g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Mon, Aug 12, 2019, 22:31 David Nalley wrote: >... > Greg - I propose that you, Ross (sorry for volunteering you), and I > pick an incubating project in need of mentor attention and make this > as streamlined as we can. Let's focus on educating and enabling and > not gatekeeping. Let's prove out the concept and stop beating this > poor horse so much. :) > This is not possible under the rules regime of the IPMC. A new PMC, operating under different rules, sanctioned by the Board, is required. With that, I am willing. Cheers, -g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Wed, Aug 14, 2019, 00:33 Justin Mclean wrote: > Hi, > > > Q: Does the IPMC want to produce non-ASF releases? > > A: We already are Not true, as you well know. Whether we call the above a lie, or misdirection is left to the reader. The IPMC currently attempts to ensure all podling releases conform to policy, and then/thus calls them ASF releases. This thread is to ask about stopping that approach. That we can/should make a business decision to accept the moot risk of placing podling releases on our distribution servers. -g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Tue, Aug 13, 2019 at 8:17 PM Justin Mclean wrote: > Hi, > > > Hoops constructed by the IPMC. Like a secondary release vote on general@ > > This is because of ASF bylaws i.e only PMC votes are binding on releases. That is not in the Bylaws. Stop making stuff up. > So you're saying implementations of ASF bylaws are "arbitrarily defined > hoops”? See above. > There could be other ways of dealing with this bylaw that have been > suggested, What bylaw? Got a reference? > for example treating podling releases not as official Apache releases. That is the origin of this thread, because you only ever pose hypotheticals. You only pose "could" possibilities. But you *never* move things to conclusion. So this thread is an attempt to do so. Your "could" emails on this thread is antithetical to its origin. > But that also has implications and concerns, which I’m not seeing being > addressed in this discussion. > Then help drive it, rather than take a back seat. Drive a decision. Q: Does the IPMC want to produce non-ASF releases? -g
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Tue, Aug 13, 2019 at 7:10 PM Justin Mclean wrote: > Hi, > > > Here's an idea... The IPMC focuses on supporting mentors to do their job > rather than forcing project developers and their mentors to jump through > arbitrarily defined hoops. > > What "arbitrarily defined hoops” are you referring to? ASF policy or > something else? > Hoops constructed by the IPMC. Like a secondary release vote on general@ > > The IPMC doesn't need to enforce policy of any kind, except at the > point of graduation. > > That seems less than ideal to me, why would a IPMC volunteer want to do > that job? And again IMO it introduces a hard gate that podlings are going > to dislike, probably more so than they do now. > They are gated day by day by day. Empirically, we already know the podlings dislike this. Let the podlings do their work. And say "nope. can't graduate now." ... until they can. >... Cheers, -g
Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking
On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean wrote: > Hi, > > > I will also note that if the IPMC switches to *voting* Members into the > > IPMC, that the Apache Member will be observing that vote take place on > > private@ through a subscription (they can reply!) or via the archives. … > > Which is also the same for any project who votes in a ASF member as a > committer or PMC member. > I would counter that any project which creates such a bar for ASF Members may be doing it Wrong :) (this goes into my general feeling that projects generally need to lower their bars, and become more inclusive) Cheers, -g
Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking
On Fri, Aug 9, 2019 at 12:04 AM Justin Mclean wrote: > Hi, > > Current any ASF member can come along and ask to join the IPMC. I assume > this was put in place for two reasons: ( but don’t know the full history > behind it) > - There was a lack of mentors. > - Is is assumed that if you are an ASF member you know enough about the > Apache Way to mentor a project. > The latter, definitely. I don't recall if the former is true. I'm -0 on removal of the precedent. I will also note that if the IPMC switches to *voting* Members into the IPMC, that the Apache Member will be observing that vote take place on private@ through a subscription (they can reply!) or via the archives. ... A vote in front a person is never going to be Fair. There is a natural misgiving to speak out against a person, to their face. You will likely not get the -1 votes that may be deserved. Cheers, -g
Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
See further below for an unfortunately trimmed thread. A couple paragraphs that I wrote early-thread are important to add: Option (F): stop calling them official ASF releases, which means PMC votes are not required. > In that case voting would not be required and they wouldn’t have to follow > ASF policy. Right. > If they are not official releases then we probably can’t release or > distribute them on ASF infrastructure. 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. We distribute a *ton* of stuff that wasn't produced by the ASF. We incorporate that stuff into a larger work, but it isn't "ours". Yet we put it onto our servers. Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use it ... but John and Jane and Joe certainly want to, and *can*. Isn't that our goal? I see no problems with the purported "risk" mentioned below. Would some mis-licensing occur? Likely. Is it material to the Foundation's mission? Nah. What if something appears on our servers without a clear F/OSS license? Does John or Jane care? Nopes. But we fix it in a future release. Move along, everybody is happy. I'd like to see the IPMC get out of the way of the podlings' releases. I see no reason for us to be a gate, and many more reasons to back off and let podlings get their work done. Cheers, -g On Sun, Aug 11, 2019 at 7:46 PM Greg Stein wrote: > On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean > 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 > >
Re: [DISCUSS] IPMC votes on releases
On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 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
Re: [DISCUSS] IPMC votes on releases
On Sat, Aug 10, 2019 at 5:29 PM Justin Mclean wrote: > Hi, > > I wrote: (dunno why Justin keeps trimming sources for his quotes...) > > Option (F): stop calling them official ASF releases, which means PMC > votes > > are not required. > > In that case voting would not be required and they wouldn’t have to follow > ASF policy. Right. > If they are not official releases then we probably can’t release or > distribute them on ASF infrastructure. 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. We distribute a *ton* of stuff that wasn't produced by the ASF. We incorporate that stuff into a larger work, but it isn't "ours". Yet we put it onto our servers. Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use it ... but John and Jane and Joe certainly want to, and *can*. Isn't that our goal? We do allow connivance binaries but they still have to follow ASF policy > and have to be made from the source of an official release. In this > scenario how do podlings learn what is required to make official releases? > You're conflating *learning* with *releases*. These can be handled separately. Cheers, -g not-Infra
Re: [DISCUSS] IPMC votes on releases
Option (F): stop calling them official ASF releases, which means PMC votes are not required. On Fri, Aug 9, 2019 at 12:04 AM Justin Mclean wrote: > Hi, > > One of the incubator pain points is the double voting on releases first by > the podling and then by the IPMC. > > Historically there been a lot of discussion about this and a couple of > proposals to try and change it, but none have been accepted. There have > been proposals on alternative ways to vote and to ask for guidances which > have been accepted, but podlings don’t seem to take these options up. I’m > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > go some way to helping podling get releases out, but time will tell. > > When consider what to do about this, please keep this in mind: > 1. Only PMC members can have binding votes on releases (it’s in our > bylaws) so a minimum of 3 IPMC votes are require to make a release. > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > not binding on releases. > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > checking this way. This is mostly, but not always, on the early releases. > > So option (A) would be to get the Bylaws changed and treat podlings as > TLPs. > > Another option (B) is to get all mentors to vote on every release. We’ve > tried this via various means and it seems only a couple of podlings can > manage this. > > One (perhaps not carefully considered) option (C) would be to vote in all > PPMC members as IPMC and make PPMC members IPMC members when projects are > first created rather than incubator committers. If we did this we could > optionally gate graduation on a review of a podlings releases but that may > be unpopular. There have also been complaints in the past that he IPMC is > too large, so increasing the IPMC size this way may also not be popular. > > A variation on (C) let call it option (D) would be to vote in podling > release mangers into the IPMC after they have done a number of releases > along with podling committers that provide good feedback on a number of > release candidates. That way when starting out a podling is likely to need > the IPMC help, but one they have a few releases under their belts they will > have enough IPMC votes without having to reply on mentors or other IPMC > members. It would also encourage more careful voting on releases, If you > just go +1 with giving some detail you’re not going to be voted into the > IPMC. This wouldn't require any bylaws or policy change, we could just go > ahead and do it. It would require the mentors help in identifying good > candidates. > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > notify the IPMC that they are making a release, the IPMC can review it and > and any issues or feedback found can incorporated into the next release or > before graduation as per [1]. This may mean that there’s a risk that a > release has to be taken down and redone - (see issues that are blockers in > that ticket), but most issues found over the notification it would be > business as usual. > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > really working, but option (D) combined with (E) along with the recent > DISCLAIMER-WIP I think could would improve the situation. > > Does anyone have any other ideas they care to share? > > Thanks, > Justin > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] DataSketches-memory RC2
+1 (binding) On Mon, Jul 29, 2019 at 12:09 AM leerho wrote: > Hello Apache general@incubator community. > > 1. This is a call for vote to release Apache DataSketches-memory version: > 1.0.0-incubating-RC2 > > NOTE 1: This is one component of the DataSketches library which needs to be > released first as other repositories have a dependency on this one. Once > this is released, the other components of the library will be able to be > released. > > > 2. Results from the PPMC vote (open for more than 102 hours not counting > the weekend) > > - 5 votes were cast. All of the votes were (+1). Two of the votes were > from Mentors. > > - The vote thread can be found at: > > https://mail-archives.apache.org/mod_mbox/datasketches-dev/201907.mbox/browser > > > 3. Testing/actions/votes performed by the voters: > > - Lee Rhodes: (+1) > - All of the code has been properly refactored with > "org.apache.datasketches...". > - All source files have the proper Apache license and have been checked > with the Maven Rat Plugin. > - The code passes all tests with a coverage of > 98%. > - Checkstyle: passes with no warnings. This uses the configuration > MemoryCheckstyle.xml located in the /tools/ directory. > - SpotBugs: passes with no bugs found: This uses the configuration > FindBugsExcludeFilter.xml located in the /tools/directory. > - mvn clean javadoc:javadoc produces no javadoc errors. The javadocs > will be found under /target/site/ > - mvn versions:display-plugin-updates. This has 2 warnings, but the > versions are inherited from the super-pom. >- [WARNING] The following plugins do not have their version > specified: >- [WARNING] maven-assembly-plugin . (from > super-pom) 2.6 >- [WARNING] maven-compiler-plugin . (from > super-pom) 3.5. >Note: In the next release we can add the version numbers to the > local pom to eliminate this warning. > - The assembly file signatures and checksums have been verified. > > - Alex Saydakov: (+1) > - mvn package > - mvn test > > - Jon Malkin: (+1) > - mvn test > - mvn install > > - Furkan Kamaci (+1 IPMC Member) > - incubating in name > - Disclamer exists > - License is fine > - Notice is fine > - no unexpected binary files > - code compiles and tests successfully run > > - Kenneth Knowles (+1 IPMC Member) > Double checked: > - DISCLAIMER, LICENSE and NOTICE > - mvn install succeeded > > > 4. Source repository: > https://github.com/apache/incubator-datasketches-memory > > - Git Tag for this release: 1.0.0-incubating-RC2 > > > https://github.com/apache/incubator-datasketches-memory/tree/1.0.0-incubating-RC2 > > - Git HashId for this release starts with: ec8f16e > > > 5. DIST/DEV: The release candidate assembly: > > - > > https://dist.apache.org/repos/dist/dev/incubator/datasketches/memory/1.0.0-incubating-RC2/apache-datasketches-memory-1.0.0-incubating-src.zip > > - The assembly file has been signed with --keyid-format SHORT : 8CD4A902 > > - The public signing key can be found in the KEYS file: > https://dist.apache.org/repos/dist/dev/incubator/datasketches/KEYS > > - Upon acceptance, the above assembly and signatures will be deployed > into the official Apache release repository: > > https://dist.apache.org/repos/dist/release/incubator/datasketches/memory/ > > > 6. NEXUS: The Jar and pom attributes have been deployed to Nexus Staging > Repository "orgapachedatasketches-1000", which can be examined from the > Nexus UI. > >- Upon acceptance, the staging repository holding the artifacts will be > closed and then the artifacts will be released. > > > 7. Note that Mentors k...@apache.org and furkankam...@gmail.com as well as > pa...@asert.com.au have made a number of valuable suggestions on improving > the process that are recorded in a separate thread. None of the > suggestions impact the voting for this release. This has been valuable > learning for us and we will be implementing these suggestions in the next > release. > > Lee > lee...@apache.org >
Re: [Vote] Release Apache Weex (Incubating) 0.26.0-RC2
+1 (binding) (also, again, registering my dispute with needs for IPMC votes) On Mon, Jul 8, 2019 at 6:19 AM 王乾元 wrote: > Hi, > > The Apache Weex community has voted and approved the proposal to release > Apache Weex (Incubating) version 0.26.0-RC2. > We now kindly request the Incubator PMC members to review and vote on this > incubator release. > > >- Vote thread: > > https://lists.apache.org/x/thread.html/1fe6327f7a2775fad2ca08c6960dac8d389479fce2abbd8c6680a374@%3Cdev.weex.apache.org%3E >- Vote result thread: > > https://lists.apache.org/x/thread.html/199d2046caece609992271546926378dda4dc2bfd5281caa3ff9c8a6@%3Cdev.weex.apache.org%3E >- Git tag for this Release: 0.26.0-RC2 >- The source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz > > >- The signature of the source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz.asc >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.asc > > >- The SHA-512 checksum of the source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz.sha512 >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.sha512 > > >- The source tarball is signed with Key: >CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the > key >file: https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS > > > *ChangeLog about this version:* > *Features* > >- Support arm64 & ndk18 on Android platform. >- Android JSC Runtime refactor. >- Android & iOS multi-size screen & rotation support. >- Background JS thread on iOS. >- Log module on iOS and Android to support redirection. >- Synchronous call of component methods. >- Unified C++ log system of WeexCore. > > *Main Bugfix* > >- Animation module crash on iOS. >- RTL layout crash on iOS. >- NSTimer not removed by WXTimerModule on iOS. >- Occasionally showing placeholder instead of main image on iOS. >- Animation end progress error on iOS. >- Some NPE issues on Android. >- Closing fd multiple times on Android IPC. >- box-shadow crash protection on Android. >- GPU texture size overflow protection on Android. >- Weexcore.so loading failure problem on Android. > > > One can build the binary from source according to > > https://github.com/apache/incubator-weex/blob/0.26.0-RC2/HOW-TO-BUILD.md#build-all-by-script > < > https://github.com/apache/incubator-weex/blob/0.26.0-RC1/HOW-TO-BUILD.md#build-all-by-script > > > > > This vote will remain open for at least 72 hours, until we get enough > votes. Please vote on releasing this RC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) >
Re: New disclaimer text
On Wed, Jul 3, 2019 at 4:35 PM Alex Harui wrote: > Suggestion: The DISCLAIMER references a detached copy of the DISCLAIMER > at dist.a.o/releases/incubator/project and that detached copy is the one > that gets updated with late breaking stuff. > > Re-rolling required re-GPG-signing, new hashes, etc. > Which is made worse by the two-step/vote process of podling then IPMC. Cheers, -g
Re: Podlings, the Incubator, relationships and Apache
On Wed, Jul 3, 2019 at 1:07 AM Justin Mclean wrote: > Hi, > > > Or we *don't* provide legal protections. That *is* what the disclaimer is > > there for. > > For that to happen I think the disclaimer text would need to change, I’m > assuming you don’t think that. Even so a DISCLAIMER doesn’t remove legal > obligations. > What the heck are you talking about? "legal obligations"? ... A tarball is placed on a server. People download. Done. As long as we don't include stolen source, then ... whatever. Of course, the disclaimer changes. It should say "The Foundation doesn't endorse this. It is an artifact produced by a third party, and we make no guarantees on licensing, functionality, or security." > I don't recall that advice. In fact, Roman seemed to indicate Legal would > > be just fine with that. > > Only if the incubator is not considered a TLP but is a special construct > within the Foundation. Several people have indicated they see the incubator > as a TLP. > Blah blah blah. Wordsmithing crap. The Incubator is a PMC. Period. Fact. It can operate however it needs to, to achieve the outcome assigned by the Board. The Board told it to onboard communities. The Board did *NOT* tell it to follow standard release policy. That's just an invalid assumption. > > IMO, stop being pessimistic. Move forward with change to stop the gating, > > and let podlings do their releases without all the IPMC burden. > > We want to be at “D” or “E” , we’re currently at “A” and there's a few > steps that need to be taken. I don’t believe the IPMC can just say “make it > so” and move from “A" to “E”. We also need consensus which I don’t believe > we have yet, so we might end up at “F” or “G”. Also if we make this > position “offical”, it will stop the same issue from reoccurring in the > future. It has occurred every few years since the incubator has existed as > far as I can tell. Well that’s the way I see it anyway, you and others may > see it differently. > I have zero confidence that you will move the pin here. You have shown zero willingness. I'd like to see a new VP Incubator. -g
Re: Podlings, the Incubator, relationships and Apache
On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean wrote: >... > Hi, > > > Although not a "real" PMC, we do need to provide legal protection for > each PPMC and distributing releases is the time that most legal > considerations "kick in" as it were. So we need a Or we *don't* provide legal protections. That *is* what the disclaimer is there for. >... > Which while I don’t disagree with, again I ask how can a PMC (i.e the > incubator) make releases that are not in line with policy? Current advice > seems that the board would not grant a blanket exception like to the IPMC I don't recall that advice. In fact, Roman seemed to indicate Legal would be just fine with that. IMO, stop being pessimistic. Move forward with change to stop the gating, and let podlings do their releases without all the IPMC burden. >... > > Let's also recall that the origin genesis of the Incubator was NOT to > provide legal oversight > > That may be the original thought, but historical threads bring up legal > oversight very very early on. (I posted one from 2004 the other day). > Hopefully someone can explain this history? > Who cares? Red herring. We are where we are. Move forward from here. -g
Re: New disclaimer text
On Tue, Jul 2, 2019 at 1:55 PM Daniel Shahaf wrote: > Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700: > > > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz < > bdelacre...@codeconsult.ch> wrote: > > > > > > Hi, > > > > > > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean < > jus...@classsoftware.com> wrote: > > >> ...I put up suggested text changes for an incubator disclaimer here > [1]... > > > > > > Basically just adding this, right? > > > > > >> Some of the project releases may not follow ASF policy or have > > >> incomplete or unknown licensing conditions > > > > > > It works for me but I'd say "incubating project" to be clearer. > > > > How is this? > > > > “Some of the incubating project’s releases may not be fully compliant > > with ASF policy. For example, releases may have incomplete or unreviewed > > licensing conditions. Known issues will be described on the project’s > > status page." > > I think the meaning you guys are after is "The artifact may not be in > compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you > actually drafted so far can be read as "We do not promise to you that the > LICENSE file is complete and accurate", which would be a deal breaker to > downstreams. > s/would/may/ As a hobbyist user, I really don't care what is in LICENSE and NOTICE. Heck, I don't even care if those files are missing. Cheers, -g
Re: Podlings, the Incubator, relationships and Apache
On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean wrote: >... > > It appears there is general consensus that "right to distribute closed > source" would be the main and potentially only blocker for podlings. > > That is not the case (re this is a blocker) I suggest you read that legal > thread again. Also infra makes distribution policy. > *distribution* Infra does not care about the contents. If a PMC says "we +1 the contents", then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do those files wrong. Include jars, Cat X source. Whatever. We aren't going to police that. Binaries in there? Knock yourself out. Legal might get on your case, but that's Not Our Problem(tm). If the IPMC says "here is a podling tarball that we will allow", then it can be put into distribution. Use whatever rules you want for the contents, or lack of rules. Infra just wants it placed into our distribution system in a specific way, to ensure correctness, auditing, and resilience. VP Infra has already stated the above. As an Officer of Infrastructure, I concur and reiterate that position. Regards, Greg Stein InfraAdmin, ASF
Re: Podlings, the Incubator, relationships and Apache
On Thu, Jun 27, 2019 at 4:24 PM Sam Ruby wrote: > On Thu, Jun 27, 2019 at 7:57 AM Greg Stein wrote: > > > > On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean > > > wrote: > > > > > > b) It listed as a TLP in Whimsy > > > > Whimsy is not canonical. Its label means absolutely nothing. Board > > decisions are canonical. > > The canonical source is: > > https://svn.apache.org/repos/private/committers/board/committee-info.txt Sure. The label "TLP" (aka "PMC") comes from the Board resolution, and maintained on an ongoing basis in that file. Just trying to answer Justin's 3 questions. -g
Re: [VOTE] Apache Tuweni 0.8.0
On Thu, Jun 27, 2019 at 4:29 PM Craig Russell wrote: >... > No. Smiley face doesn't count. > Apparently you missed the point when Justin did that to me. Hmm? Of course it doesn't count. Why don't you go police th VP Incubator, okay? -g
Re: Podlings, the Incubator, relationships and Apache
On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean wrote: > Hi, > > > Which would be a reasonable assumption give: > > a) That only IPMC votes are binding on releases. > Only because IPMC said it must provide such votes. I maintain it does not have to. The Board gave the Incubator the range/duty for incubating projects. That allows for podlings to use our infrastructure (mailing lists, jira, dist.apache, cwiki, etc) and to make their releases. Within that duty assigned by the Board, it can apply alternate rules to releases. I state that permission is already given. Others disagree, and want an answer from Legal. Roman seems amenable, if the IPMC has the will to formally ask. > > b) It listed as a TLP in Whimsy > Whimsy is not canonical. Its label means absolutely nothing. Board decisions are canonical. > > c) The resolution that formed it uses the same language as a TLP and > talks abut forming a PMC and assigning a VP [1] > That was in 2002. Establishing any PMC was a pretty new thing. But even if you ignore the age, a PMC was constructed by the Board with the *duty* to onboard new groups. It says nothing about holding releases to any specific policy. -g
Re: [VOTE] Apache Tuweni 0.8.0
On Thu, Jun 27, 2019 at 12:34 AM Justin Mclean wrote: > Hi, > > > I see a lot of "oh no. a bad file". What is the takeaway from that? "The > > IPMC thinks we should not release.” > > Has anyone voted -1? Nope. And even if they did a -1 vote is not a veto. > Great. Semantics. "But I didn't really say veto." Your "not allowed" is read as a veto by any reasonably-minded person. If you think it should NOT be read as -1, then put a +1 into your message. That did not happen. So it is NOT read as +1 for the podling. I added my +1 as the third. Mostly to get it over with, and (honestly:) for some spite about the whole process. Look. Clearly this discussion is about rulesmithing to keep the status quo. Carry on. Maybe I should say you're being an ass about the whole process. :-) -g ps. per your rules [1], I put a smiley on that sentence, so it doesn't mean anything. [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201906.mbox/%3CA2A7580A-20DA-4894-9590-14D563C3D0E0%40me.com%3E
Re: [VOTE] Apache Tuweni 0.8.0
+1 (binding) On Mon, Jun 24, 2019 at 5:03 AM Antoine Toulme wrote: > Hi all, > The Tuweni community voted on and has approved a proposal to release > Tuweni 0.8.0. Pursuant to the Releases section of the Incubation > Policy and we would now like to request the permission of the Incubator > PMC to publish the > tarball on the Tuweni Download page. > Note we have collected 4 +1 votes from IPMC members and have therefore the > necessary minimum votes. > > Please vote by 12 PM Paris time Thursday, 6/27. > > Thanks > Antoine > > Proposal: > > https://lists.apache.org/thread.html/7ad88c9725d954f0c58968b3ba53da007b8b48079fe24ee908e03a04@%3Cdev.tuweni.apache.org%3E > < > https://lists.apache.org/thread.html/7ad88c9725d954f0c58968b3ba53da007b8b48079fe24ee908e03a04@%3Cdev.tuweni.apache.org%3E > > > > Vote result: > > https://lists.apache.org/thread.html/2d4ac9cc208218e87d916a9bfc01faec53b30a5e714fe1d632f5fe8c@%3Cdev.tuweni.apache.org%3E > < > https://lists.apache.org/thread.html/2d4ac9cc208218e87d916a9bfc01faec53b30a5e714fe1d632f5fe8c@%3Cdev.tuweni.apache.org%3E > > > > Releases section of the Incubation Policy: > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > >
Re: [VOTE] Apache Tuweni 0.8.0
On Wed, Jun 26, 2019 at 9:35 PM Justin Mclean wrote: >... > This sort of language is not helpful. Nor do I think it is accurate. Can > you please take more care with your words. > I feel it is accurate. And it is not directed at anybody. Only at this process. It is descriptive, and my carefully chosen word that I feel describes what is happening. You disagree. That will occur in any free discussion. Only groupthink discussion sees no disagreement. > Just let Tuweni make a release, already. Stuff like this will get fixed > eventually. > > No-one is stopping them from making a release. Sure looks like it from here. I see a lot of "oh no. a bad file". What is the takeaway from that? "The IPMC thinks we should not release." Let me provide an exact quote: "this is currently not allowed." Read that line again. Not. Allowed. How about "make the release, and fix that next time" ? Look at the framing, and at how any normal reader is going to see it. It is (ahem) insanity to believe that it doesn't look like harshing on Tuweni for a file in their release. And then escalating with "oh geez. we need Infra to weigh in on this problem" (without really doing so, until yesterday, thus stalling the process) As long as the IPMC discusses podling releases, they are going to be *interfering*. And that is what I'm seeing with Tuweni, for a minor issue which has no material effect on people trying their product. Just ungate the release, and fix it next time. Do not attempt to rewrite history. "this is currently not allowed" was the very first response. That damned well looks like the IPMC saying "no, you cannot release that" ... **especially** when that comment comes from the VP Incubator. Fact. -g
Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Wed, Jun 26, 2019 at 1:15 PM Ted Dunning wrote: > This comment by Craig is the most important one in the discussion. > > When the first words that people pick when disagreeing are essentially > personal insults, what is going on is better described as mud wrestling > rather than discussion. > Personal insults? Euh. [citation needed]
Re: [VOTE] Apache Tuweni 0.8.0
Insanity. Just let Tuweni make a release, already. Stuff like this will get fixed eventually. On Wed, Jun 26, 2019 at 10:46 AM Justin Mclean wrote: > Hi, > > > It may not be clear to you, but it was discussed in the earlier vote > thread. See > https://lists.apache.org/thread.html/2b5fed22493e954937405cfd2553d06c00e5bee3b76be06b18b74862@%3Cdev.tuweni.apache.org%3E > for my noticing the jar still being present. > > Noting its present and clearly indicating what the podlings future > responsibility is in regards to this are perhaps seperate things. This is > not a minor issue. I hope the podling realises this is the first time that > a IPMC release with compiled code of this magnitude has been approved. A > recent thread on legal would suggest that this should not be allowed due to > licensing issues (even if we allow jars in source releases), and the thread > on infra makes this the IPMC responsibility. I’ll leave it up the the PPMC > and the mentors to consider the implications of that. In all previous IPMC > votes that would of resulted in one or more -1 votes being cast and the > podling asked to make another release candidate, especially considering > that this was a issue that has occurred in a previous release candidate. > Apache makes open source software, having a release with compiled code it > it is not open source software and is against one of the core values of > what we do. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Infrastructure removing releases Was: Re: [VOTE] Apache Tuweni 0.8.0
On Tue, Jun 25, 2019 at 10:01 PM Justin Mclean wrote: > Hi, > > > I apologize for missing that question in the May report. > > I've ask esthe question several times over serval months (in slightly > different forms) and not got a clear answer. > > The most recent conversations have been on Slack. See for instance [2] or > [3] (where is seems that sometimes infra are the police) or [4]. > > I can’t find the email in question, but did recall and find this (although > it's from a while ago) [1] > If you want to ask Infra a question, then ask on users@infra or private@infra. Per [2], that is exactly the response "not for Slack". We might see it on general@incubator ... but honestly: if you seriously want our input, then ask where we will see it and respond. And if you don't get a response, then escalate until you do. And [1] is 13 years old. Not even sure how that enters into the conversation, unless you want to take Roy's advice and move Incubator in the direction it seems people want: relax release workflow. Get the IPMC out of the process/voting. Regards, Greg Stein InfraAdmin, ASF
Re: Podlings, the Incubator, relationships and Apache
On Sun, Jun 23, 2019 at 11:55 PM Davor Bonaci wrote: > I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly > in the "2nd camp", with its desire to be lenient with the releases and > rules. > I disagree. I see a number of people who think that podling releases are TLP-level releases from the Incubator itself. I see people wanting structure/policy/rules to ensure these TLP releases are done properly. And that some want to "fix a few things" to make it easier for podlings to make these releases. There are some that disagree with that outlook (the 2nd campers), and would like that "business decision" because the status quo is rough on podlings. I believe we do not have consensus on this shift in outlook/operation. Cheers, -g
Re: Podlings, the Incubator, relationships and Apache
+1 to 2nd camp. And even less requirements than have been suggested, I would offer. For example: if the tarball is missing a LICENSE or NOTICE file? Who cares. It's still a legal release. Just hard for downstream users to consume. But they *can*. Nothing stopping somebody from trying out the tarball. Cheers, -g On Sun, Jun 23, 2019 at 10:53 PM Dave Fisher wrote: > Thanks Roman! > > +1 to the 2nd camp! > > Regards, > Dave > > Sent from my iPhone > > > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik > wrote: > > > >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: > >> > >> A couple of thoughts: > > > > And a couple of thoughts on top of that. > > > >> Podlings are not permitted to call themselves "Apache Foo" because they > are > >> not yet full Apache projects. > > > > Correct. The I way I see this thread is this: *when it comes to > > releases*, there's > > always been two camps in Incubator. One thinks that Incubator is a TLP > just > > like Apache Commons that happens to produce release artifacts that have > > nothing in common (just like Apache Commons' JXPath has very little to > do > > with Compress and). A second camp thinks that Incubator is actually a > special > > construct within a foundation (after all, if it was just like Apache > Commons why > > would we make them put DISCLAIMER into release tarballs?). > > > > It seems that David is closer to the 1st camp, and Rich and I are > > closer to the 2nd. > > > > Looking at the community benefits, I really think we should acknowledge > that > > Incubator is a special construct and optimize that special construct > > for a particular > > outcome: which is effectiveness of the graduation process. > > > >> While in the incubator we should expect podlibgs to fail at the rules. > >> They're new to them and many of them feel arbitrary, even capricious, to > >> those coming in from outside. We should make it safe to fail until they > are > >> ready to graduate. We should nurture them as long as they are moving > >> towards that goal. > > > > Yup. > > > >> I cannot disagree with your reading of our resolutions. But I wonder if > >> that reality is producing good citizen projects or a bunch of resentful > >> people following rules they don't understand or embrace because they > know > >> they have to. > >> > >> Zipkin is only the latest project which clearly didn't get it and has > left > >> angry. I would rather a project realize that they don't fit and be able > to > >> leave with their dignity without having also to leave hating what we > stand > >> for. > >> > >> I want our new graduates to love and understand the ASF not merely > tolerate > >> it. > >> > >> I want the incubator to respond to failure with gentle correction rather > >> than scoldings. > >> > >> Specifically I think podlings should be able to produce releases that > are > >> not asf complient and have them clearly labeled as such. Because they > are > >> not TLPs yet and so cannot be held to the same standard. This must be > >> accompanied by a movement towards being a TLP, not some eternal > incubation. > > > > With my IPMC member hat on -- huge +1 to the above. > > > > With my VP Legal hat on: I have no dog in this race. The IPMC needs to > make > > a *business* (well, community in this case) decision and then we can work > > with a risk profile of that decision. > > > > Like I said -- the decision to make is: 1st vs. 2nd camp. > > > > Thanks, > > Roman. > > > > - > > 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: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Thu, Jun 20, 2019 at 4:33 AM Ted Dunning wrote: > On Thu, Jun 20, 2019 at 1:59 AM Greg Stein wrote: > > > > > > On Thu, Jun 20, 2019 at 9:38 AM Lars Francke > > > wrote: > > > > > > > This is very much not thought through to the end. One question raised > > for > > > > example is whether projects would even want to become a TLP. > > > > The mission states: "We do this by providing services and support for > > > many > > > > like-minded software project communities consisting of individuals > who > > > > choose to participate in ASF activities." > > > > I don't see anything in there requiring anyone to "join" (I remember > > the > > > > recent discussions about that). If you sign up to Github you're not > all > > > of > > > > a sudden a "Github project" but still benefit from its services. > > > > > > > > We could do something similar. > > > > > > Do I understand correctly that you're proposing a sort of "indefinite > > > incubation" for projects which want to benefit from our infra but don't > > > want to follow one or more of the principles we have deemed important > to > > > producing open source software? > > > > > ... > > I don't see Lars suggesting allowing such projects. There would still be > a > > Proposal, and retirement is still an option. > > > Actually, I think that he quite literally did suggest what he called > github++ where projects would be free to make releases based on whatever > rules that they chose and to not all themselves apache projects for as long > as they like. > > I am with Myrle. That isn't what we want. There has to be some ooomph > toward becoming an Apache project. > I totally agree. Just saying I didn't read Lars that way. *shrug*
Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Thu, Jun 20, 2019 at 3:23 AM Myrle Krantz wrote: > On Thu, Jun 20, 2019 at 9:38 AM Lars Francke > wrote: > > > This is very much not thought through to the end. One question raised for > > example is whether projects would even want to become a TLP. > > The mission states: "We do this by providing services and support for > many > > like-minded software project communities consisting of individuals who > > choose to participate in ASF activities." > > I don't see anything in there requiring anyone to "join" (I remember the > > recent discussions about that). If you sign up to Github you're not all > of > > a sudden a "Github project" but still benefit from its services. > > > > We could do something similar. > > Do I understand correctly that you're proposing a sort of "indefinite > incubation" for projects which want to benefit from our infra but don't > want to follow one or more of the principles we have deemed important to > producing open source software? > We have forcibly retired projects before. That option would still be available in this model. The community "should" be moving towards Apache-style governance and TLP-style releases. Lack of movement would be an indicator to consider retirement. Just like we've always done. > I don't want to do that. If your project is in the incubator, it should be > with at least the intention of finding out if the ASF is a good fit for > your community. That answer could be "no". And it could take a long time > to figure that out. That's OK. But our volunteer time is a limited > resource. We don't need to spend it on projects which don't actually want > to be part of the ASF. > I don't see Lars suggesting allowing such projects. There would still be a Proposal, and retirement is still an option. Cheers, -g
Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Wed, Jun 19, 2019 at 12:14 PM Ted Dunning wrote: > On Wed, Jun 19, 2019 at 12:17 AM Greg Stein wrote: > > > On Wed, Jun 19, 2019 at 1:48 AM Justin Mclean > > wrote: > > > > > Hi, > > > > > > > The VOTE was ridiculous. It can only come out "Yes", so why? > > > > > > Which is the outcome of most votes, they confirm consensus. > > > > > > A vote has two outcomes. This kind of vote should never have a "no" > > outcome. Thus, it is specious on its face. > > > > > Not so much. Votes at Apache are often used to memorialized consensus in a > highly searchable fashion. It helps to make sure that people are on the > same page. > The podling community's archives have that. general@incubator would have an [EXIT] or [RETIRE] or [NOTICE] email sent to it. If the community consensus is to leave, then the IPMC has no further say. Note that I said consensus. Any -1s here would be a major surprise, but, precisely because they would > be a surprise, it would be important to make sure that there is a moment > that they could be brought out. > > You are right that a vote that has consensus already established should > have the expected outcome, unless the consensus was, say, the result of > loud voices drowning out shy voices. > The Foundation does not police loud/shy voices in consensus. We don't police it all, but presume it is occurring. (and await escalation reports of failure to follow consensus) > > But to be more specific in this case, to give a clear searchable record > in > > > the mail archives that this wasn’t a fork or other adverse situation. > > > > That was already established and recorded in the Zipkin community, with > > their vote to depart. > > That established half of the consensus. The IPMC documented the other half. > The IPMC is not part of the community. It has no vote. > > > Others might have other reasons for thinking it was needed. Also, a > > mentor > > > called the vote and I respect their decision to do so. > > > > Which mentor? Sheng Wu? Bullied into holding a vote? > > I was watching and I didn't see any bullying. Did you? Were you even > watching the process in detail? > Sheng called the vote, but clearly did not feel it was needed. "Bully" might be too strong a word, but "obligating" somebody to run a vote pretty well fits the same bill. I read Justin's email as ambiguous on whether he meant the concrete call to vote (Sheng and the email thread), or the "decision" to have Sheng run a vote, per my comment next para: > Or maybe from the private@incubator list, the one who said "I would say we > > should take a discuss/vote in general@incubator to retire the podling". > > That is simply participating in IPMC overreach. It is a sign of > disrespect > > for the Zipkin community, that the IPMC has "final say" and requires a > vote > > to (ahem) "allow them to leave". The IPMC is NOT in control of > communities. > > It is foolish to believe so, and to construct "procedures" and "policy" > and > > "bureaucracy" to pretend so. > > No, that isn't what this vote is saying. This vote is *confirming* that > nobody has objections (of any form) to Zipkin leaving and control of the > git repos being transferred. > Why should the IPMC have any say in a community that has refused to further participate in Apache? That is nonsensical. Why do they ask at weddings if there is anybody who might bring any reason > for the wedding to not go forward? Not at my wedding! :p > It isn't that they *expect* anybody to > bring something up. Instead, the tradition is there to record community > consensus. It used to have a very serious importance when communities were > smaller like Apache is now. > I reject the notion that the IPMC has any say in a community's decision to retire. If I have in the past, then I was wrong and my thinking has improved. I believe the IPMC has become to "interfere-y" with the podling communities. If it takes a Hall Pass from VP Legal to get the IPMC out of release voting, then Make It So. Podling communities should make their releases, and the IPMC should have no vote in that process. Review/feedback all they want, of course. But no votes, as that implies they have ownership of the community's release process. Regards, -g
Re: Incubation Pain Points
On Wed, Jun 19, 2019 at 1:02 PM Alex Harui wrote: >... > To close with Justin's bread analogy: A bread maker that just says "just > add yeast and flour and water, kneed, let rise and bake" and then makes you > toss out the results and start over is not going to attract nearly as many > students as the bread making expert who can more clearly provide > instructions in a friendly way, helps you catch your mistakes before you go > too far down the road, and doesn't make you start over except in a few > extreme cases. For sure, if you sign up to be a bread making apprentice at > the most prestigious bakery, then you can expect less leniency and stricter > standards. It is up to the ASF to decide if they want the reputation of > being that picky or not. I hope not. > And an even better bread maker allows you to make pies for a year (cuz why not?), knowing you'll eventually be a great bread maker under their tutelage. Cheers, -g
Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Wed, Jun 19, 2019 at 4:14 AM Bertrand Delacretaz < bdelacre...@codeconsult.ch> wrote: > Hi, > > On Wed, Jun 19, 2019 at 8:13 AM Greg Stein wrote: > > ...Let's talk about the overzealous bureaucracy of the IPMC... > > IMO something that can help fix that is declaring that the IPMC's goal > is to *provide services to podlings so they can become top-level ASF > Projects". > > Currently, many things in the Incubator make it appear more like a > *stern gatekeeper for entry to the ASF" - like this overzealous > bureaucracy that you mention and that is often perceptible. > > The difference is subtle but it can influence the IPMC's culture. > Thank you, Bertrand! ... as always, you have a knack for looking at culture. My commentary is usually rather ham-handed, but yes: what you describe is where I'd like to see the Incubator head. Stop the gatekeeping/rules, and focus on help/mentor/service. Thanks, -g
Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Wed, Jun 19, 2019 at 1:48 AM Justin Mclean wrote: > Hi, > > > The VOTE was ridiculous. It can only come out "Yes", so why? > > Which is the outcome of most votes, they confirm consensus. A vote has two outcomes. This kind of vote should never have a "no" outcome. Thus, it is specious on its face. > But to be more specific in this case, to give a clear searchable record in > the mail archives that this wasn’t a fork or other adverse situation. That was already established and recorded in the Zipkin community, with their vote to depart. > Others might have other reasons for thinking it was needed. Also, a mentor > called the vote and I respect their decision to do so. Which mentor? Sheng Wu? Bullied into holding a vote? Or maybe from the private@incubator list, the one who said "I would say we should take a discuss/vote in general@incubator to retire the podling". That is simply participating in IPMC overreach. It is a sign of disrespect for the Zipkin community, that the IPMC has "final say" and requires a vote to (ahem) "allow them to leave". The IPMC is NOT in control of communities. It is foolish to believe so, and to construct "procedures" and "policy" and "bureaucracy" to pretend so. I'm fine stating all this nonsensical behavior in public. -g
overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)
On Tue, Jun 18, 2019 at 7:42 PM Dave Fisher wrote: > Hi David and Greg, > > > On Jun 18, 2019, at 5:39 PM, Justin Mclean > wrote: > >... > > BTW in all previous cases of podlings exiting I could find, a vote was > taken (see below links and there’s more I’ve not listed). In most cases > this was to retire rather than returning/going elsewhere, so the situation > not exactly the same, but that’s a data point all the same. > That doesn't justify requiring a [VOTE]. > If anyone thinks a VOTE is not necessary then please discuss why on > another thread. > I merely added a parenthetical to my vote. As did David. But sure. Let's talk about the overzealous bureaucracy of the IPMC. Think about the result of this purported [VOTE]. Two answers: 1) yes, you are free to leave 2) no, you are NOT free to leave What does (2) mean? That we hold the community's repositories hostage? That we don't return them? On what right? On what *ethical* right? The VOTE was ridiculous. It can only come out "Yes", so why? The *Zipkin community* owns those repositories. Not Apache or the IPMC. Let the community take them where they want. If a podling graduates, then the community and its resources are recognized by the Board as an official part of the Foundation. Unless/until then, we should be very careful about spurious claims of ownership. Years back, we talked about not wanting to accept "hostile forks" of other projects as podlings. We did not want to be party to such a calamity. By voting "no" in this case, the IPMC would be the one *creating* the hostile fork. Not merely accepting it as a podling. Talk about bad karma. Regards, -g
Re: [VOTE] Zipkin leave incubator, return back to OpenZipkin
+1 (binding) (and IMO this vote should never have been needed/called; let's help them, rather than hinder) On Mon, Jun 17, 2019 at 8:22 PM Sheng Wu wrote: > Hi > > This is a call for official vote of Zipkin leave from incubator, and > return back to OpenZipkin. > > PPMC have voted.[1], carried two IPMC +1 vote from Sheng Wu and Willem > Jiang > > There is no trademark, logo transfer, so, Zipkin community is OK to still > use the name(io.zipkin or zipkin + xxx) and logo. > `org.apache.zipkin` is not allowed or going to be used. > All 9 repositories(GitHub repo) will be transferred back to OpenZipkin > org(GitHub). > incubator-zipkin --> https://github.com/openzipkin/zipkin > ncubator-zipkin-dependencies --> > https://github.com/openzipkin/zipkin-dependencies > incubator-zipkin-api --> https://github.com/openzipkin/zipkin-api > incubator-zipkin-b3-propagation --> > https://github.com/openzipkin/b3-propagation > incubator-zipkin-reporter-java --> > https://github.com/openzipkin/zipkin-reporter-java > incubator-zipkin-brave --> https://github.com/openzipkin/brave > incubator-zipkin-brave-cassandra --> > https://github.com/openzipkin/brave-cassandra > incubator-zipkin-brave-karaf --> https://github.com/openzipkin/brave-karaf > incubator-zipkin-layout-factory --> > https://github.com/openzipkin/zipkin-layout-factory > > Voting will start now (2019-6-18 9:20 UTC+8) and will remain open 72 hours > only for consensus, Request all IPMC members to give their vote. > [ ] +1 Agree > [ ] +0 No opinion. > [ ] -1 Do not agree because > > [1] > https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E > < > https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E > > > > > > Sheng Wu > Apache Skywalking, ShardingSphere, Zipkin > > > >
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019, 18:57 Justin Mclean wrote: > Hi, > > > Boring imo. You have to try hard to screw up Cat B (though I’ve seen it > > done). > > Really? Category B source code is generally not allowed in sources > releases. It's actually Category X. Category B as image and the like is > allowed. > And if it appears in a tarball... So what happens? Really. Answer that. (licenses for each piece of work get sorted) We are getting all twisted up in nonsense. Make some podling releases, and improve them each time. Nothing more than that . > I mean clearly against the terms and intention. i.e. I’m less cut up if a > > 3rd party project did a crap job of their attribution such that we had to > > fix their problems in obeying their license. GPL, MPL can happily be > > included; it breaks our policy not their license. > > Well if you include GPL (and this has happened), you need to abide by > terms of it license, claiming it's ALv2 doesn’t really do that. > So what? Think on it: what is *really* going on? Various bits of code under different licensed. That is all. Whatever mislabel occurs, doesn't change the underlying licenses. So despite the furor, there isn't a problem. We claim ALv2 on the larger work/distribution. We do not override license claims on pieces within that distro. -g
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019, 02:47 Alex Harui wrote: > Maybe the next question is: Are all release policy violations > showstoppers? I suspect the answer is no. And thus, if any TLP can punt > release policy violations to a future release, What are you talking about? Nobody has suggested any modifications to TLP's policy. -g [deleting entire rest of irrelevant goo]
Re: [IMPORTANT] Board proposal on podling releases
On Mon, Jun 10, 2019 at 12:15 AM Justin Mclean wrote: > Hi, > > It’s a pity that the people who are strongly for this position, don’t seem > to actually want to be involved in helping out, but just want to discuss > and tell the people actually doing the work are going the wrong way about > this. :-) > Dude. Totally out of bounds. I am offering suggestion on how to rethink releases. I was up front and honest that my time is going elsewhere to the Foundation. bye, -g
Re: [IMPORTANT] Board proposal on podling releases
On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean
wrote:
>...
> Hi,
>
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaybe three?
>
> Given this is probably a radical departure, would it be best to do as an
> experiment with a couple of podlings? Small reversible steps. Would you be
> willing to work on a proposal to the board and act a mentor on one or more
> podlings who took this path?
>
Not me. Any of my spare/hobby time goes to supplement my work for Infra.
There is no way that I could sustainably mentor a podling.
> And keep the IPMC out of it. No votes on releases. Stop second-guessing
> the
> > mentors and the podling communities.
>
> I don't see how IPMC votes are second guessing. IPMC votes are required.
"required"? Said who?
Be honest now. We are not talking a TLP release. This is "some code" from a
podling. It may have stuff in it that would make a Director stroke out
(maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its
"imprimatur" on the release? And who/when said they must? And let's say we
can dig that up from the past ... why not remove/relax it?
It seems there is some consensus that podling releases are getting jammed
up by IPMC rules. Assuming that is true, then why not question the vote
process itself?
Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC
gets at least (2) more, majority blah blah. Then they throw some code into
the release directory. Go out for a beer.
Wouldn't that be acceptable?
>...
> That's ASF policy / bylaws not incubator policy.
Again: I disagree. This is not a TLP release. It is "some code" from a
podling.
> We could look into changing this, but probably best discussed in another
> thread.
>
Seems to apply here. Aren't we talking about releases from podlings?
> Not all mentors (who are IPMC members) vote on releases and podlings in
> most cases need to ask for extra votes from the wider IPMC. I would guess
> 90% of them, so I’m not sure how your proposal deals with that.
Just stop having the IPMC vote. No need to ask for votes. Done. Easy Peasy.
>...
> The IPMC already added one way for releases to get reviewed by the IPMC
> without a vote, but so far no podling has taken the IPMC up on the offer.
>
What other way? Link? Publicity for this? Never heard of it. One wonders
how podlings could do this, if they never learn of it. Now, I'm not
"steeped" in Incubator like you are, and apparently missed this. But I do
tend to follow much of the goings-on ...
And:
On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik
wrote:
>...
> > I would expect that any graduating podling has this under control before
> > graduating and will not make any TLP releases with this kind of defect.
>
> I would suggest we make it a policy to document those exceptions in
> the DISCLAIMER file.
>
I would posit that most are not known at release time, but yes: it would be
a Best Practice to add those to a project's DISCLAIMER when found, to
inform downstream on the next release. And let's please not hold a
podling's release until things get added. ("no! stop! add to disclaimer".
rinse. repeat.)
Cheers,
-g
Re: [IMPORTANT] Board proposal on podling releases
The entire note below sounds like "business as usual. we haven't learned anything." Release offsite is not a solution, IMO. I believe it is Best(tm) to have a DISCLAIMER.txt in the incubator/$podling/release/ directory, and "podling releases" which do not meet our normal policies for TLPs. I think our goal should be that a podling release has (say) two MUST items (add a disclaimer, use Foundation dist system; I wouldn't even care about a LICENSE file -- let users decide if that concerns them), and the rest is forgiven as long as notes/fixes will be made before graduation. It takes a new mindset. What is the *bare* minimum MUST? Two items? maaaybe three? And keep the IPMC out of it. No votes on releases. Stop second-guessing the mentors and the podling communities. Cheers, -g On Sun, Jun 9, 2019 at 6:27 PM Justin Mclean wrote: > Hi, > > > (2) We all know that for many incubating projects immediately requiring > full Release Policy compliance is too steep a slope. > > This is solved by allowing them to make non Apache releases out side of > the ASF. We currently do this. However branding and release policy also > need to be followed there. i.e. A (P)PMC can’t release unreleased materials > outside the their development community, so they can’t be called Apache > releases, and it’s not the (P)PMC who is releasing them. > > > (3) We should be willing to provide guidance to podlings about which > requirements should be fully met first. We don’t need to define serious for > this. > > +1 > > > (4) We already have tracking in place in the Podling Status XML/YAML > about the dates where podlings have met various requirements with licensing > and copyright. If properly updated then we already providing for additional > DISCLAIMERs. > > I think those disclaimers would need to be in a more visible place, i.e. > in the release artefacts, so end users can see them. > > > (5) We should work to modernize (3) and (4) to properly discuss the > modern workflow using GitBox/GitHub. For example, at what point should a > podling stop making releases in their pre-Apache process and switch to an > Apache process and how should we handle repositories that are transferred > to the ASF. > > +1 > > > (6) The IPMC and Mentors should provide additional Status around the > current state of Incubation. See the clutch page and podling clutch > analysis for one place we can improve on policy “Status”. > > +1 > > > A simple checkbox list similar to what we have in the podling status > page. > > You mean like this but for all releases? [1] > > Thanks, > Justin > > 1. > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 9:39 AM Bertrand Delacretaz < bdelacre...@codeconsult.ch> wrote: > Hi, > > On Fri, Jun 7, 2019 at 8:46 AM Justin Mclean > wrote: > > ...The proposal can be found in the draft board report. [1]... > > If I was on the Board I don't think I would accept making releases > "with serious issues in them" as mentioned there. > > Maybe I missed the discussion - what I would find acceptable is making > releases with minor issues, which are documented as such. > You did miss the discussion. And the "STOP THE RELEASE" is precisely the issue at hand. Leniency is the goal. So "I don't think I would accept" is antithetical to the discussion. -g
Re: [IMPORTANT] Board proposal on podling releases
blah blah "legal risk" blah blah. Really. Let's step back and consider what we're talking about. A podling making a release as they learn the ropes of Apache-style governance. With a disclaimer. "OMG! There is GPL code in there!" ... no legal risk. We only care about GPL from a policy standpoint. Let it through. "OMG! No NOTICE file!" ... well, easy to fix, unlike a GPL dependency. Maybe stop the release, but there isn't any "legal risk" so maybe just write a Jira ticket and move on. Copyrights, IP, and licensing are not magically thrown out the window if a file is not present. All of that is inherent, and a NOTICE file merely helps to surface IP issues, rather than specify. And just what is this "legal risk" term that people are throwing about? Please define, before use. -g On Fri, Jun 7, 2019 at 1:00 PM Craig Russell wrote: > Hi Justin, > > As a board member, I'm not comfortable with granting a blanket exception > to policy that might put us at legal risk. > > As an IPMC member, I think that we do not want to allow podlings to > release material that might put us at legal risk. I do think that the IPMC > under today's policy has the ability to decide whether a podling release > puts us at risk and therefore should be blocked. So I am not convinced that > the IPMC needs to ask for this waiver from the board. > > My understanding as an IPMC member is that there are some items in a > release that can be allowed where they would not be in a TLP release. > These things have historically drawn -1 votes from IPMC members. > > I think there is consensus that a podling release does not have to conform > in every respect to what we expect from a TLP release. > > I think that the incubator IPMC should first flesh out (on the general@ > list) which materials in a podling release are > a) fine; > b) minor issue (file a JIRA and fix before graduation); or > c) blocker (puts the foundation at risk). > > The detail of what is minor versus what it a blocker is the most important > thing that needs clarity. As of now, I don't see consensus although I see > movement. > > Craig > > > > On Jun 6, 2019, at 11:45 PM, Justin Mclean > wrote: > > > > Hi, > > > > As suggested I’ve collated information from several threads and turned > it into a proposal for the board. Any edits, feedback, agreement, > disagreement etc etc is welcome. In particular it would be nice to hear > some feedback from people who are in favour of this. > > > > Note that this is important as it probably changes the advice mentors > will give their podlings on releases and change in a positive way how we > vote on releases with serious issues in them. If you are a mentor or vote > on releases please read it. Again feedback welcome. > > > > If the board agrees with the proposal I think we'll need to update the > incubator DISCLAIMER. I’ve suggested what we might add in the proposal but > the exact changes can to be discussed here. If the board disagrees with the > proposal I suggest we discuss and come up with a list of serious issues > that the IPMC recommends voting -1 vote on a release. This is just > guidance, not rules, and there may of course be exceptions. (For instance > you could ask VP legal for an exception as has been done in the past.) > That way mentors and podlings have clear expectations on releases must > contain. > > > > The proposal can be found in the draft board report. [1] > > > > Thanks, > > Justin > > > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > > - > > 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 > >
Re: There's a missing state in the state diagram for the incubator
This has happened before. We just say "thanks, and good luck". Most recent was odftoolkit, I believe. They moved to The Document Foundation. We transferred a related domain over TDF, for that community to use. Note that we've also stated that if a trademark is transferred to us *during* incubation, then we'll return it to the prior owner if the podling retires for any reason. In some cases, we have allowed podlings to graduate to TLP status with the understanding a trademark transfer will occur in the future (ie. trademark ownership is not a blocker). At least one TLP (iBatis) moved their community out of Apache. We kept the trademark, so they are myBatis or somesuch. It is difficult for a 501(c)3 to transfer property, so we remain hesitant around trademarks. Cheers, -g On Wed, Jun 5, 2019 at 7:31 PM Adrian Cole wrote: > Hi, all > > I just noticed that all states in the diagram are under the assumption > that the only way a project stops is by the IPMC making a decision for > the project, saying they have no community etc. > > https://incubator.apache.org/policy/process.html#termination_or_retirement > > A route not listed is the PPMC choosing to stop on their own. It would > be helpful to know that a podling can voluntarily return to their > prior state, and know up front what impact that would imply. > > I expect not everything needs to be on the website, but hypothetically > speaking, what would be the impact to the people who decided to stop > incubating.. if for example the community is entirely the same as they > started? > > Best, > -Adrian > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podling releases and release policy
On Tue, Jun 4, 2019 at 7:12 PM Adrian Cole wrote: >... > https://github.com/apache/incubator-zipkin/issues/2544 That is pretty damned awesome.
Re: Podling releases and release policy
On Tue, Jun 4, 2019 at 12:08 AM Hen wrote: > On Sun, Jun 2, 2019 at 11:53 Greg Stein wrote: > > On Sun, Jun 2, 2019 at 1:22 PM Hen wrote: > > >... > > > * Incubating releases are Apache releases. > > > > That is demonstrably not true, as (historically) the Incubator has made > > releases with GPL'd code in them (eg. Hibernate). > > I don’t understand the choice of words :( > > To me that is an Apache release which did not adhere, or had an exception, > to foundation policy. I assume it was offered from an Apache url. > > If it wasn’t from an Apache url, then it wasn’t an Incubating release. > Tarballs on our server, falling under different release guidelines. In my emails on this topic, I've been trying to distinguish between "podling releases" and "Apache releases". As Ralph said, why a disclaimer, if there isn't a difference in the nature of these tarballs/releases? Historically, demonstrably, we have applied a different policy to "podling releases" that is a bit more lenient. Once the podling graduates, it must conform to the formal Apache release guidelines. Cheers, -g
Re: Podling releases and release policy
On Mon, Jun 3, 2019 at 7:54 PM Craig Russell wrote: > > On Jun 3, 2019, at 5:40 PM, Greg Stein wrote: > > > > On Mon, Jun 3, 2019 at 7:24 PM Craig Russell > wrote: > > > >>> On Jun 3, 2019, at 2:33 PM, Justin Mclean > >> wrote: > >> > >> ... > > > >>> I agree, but if you read the disclaimer is says nothing about releases, > >> perhaps that needs to change? > >> > >> Yes, I'd like to change the disclaimer to state that releases cannot be > >> considered completely reliable, should not be depended on for > production, > > > > > > I believe the above two phrases would be unfair to mature projects. In > > fact, to 95% of all the projects that arrive in the Incubator. The > projects > > *are* reliable and *are* used in production. > > Mature projects arrive here and go into incubation. I'd like to see > production cases use the existing mature project distributions and use the > incubator releases as test subjects. YMMV. > I took part in that exact situation: *Subversion 1.6* was produced "outside" the Foundation, and was the recommended version, while *Apache Subversion 1.7* was being incubated. > The only difference is they are learning how to become an Apache-style > > community. The software doesn't magically "degrade". > > Once the community makes changes to the "mature" software they have in > production, it not-magically does "degrade". > > Maybe you and I have different standards for production. Take a mature > project, add a few hundred lines of code, and it's no longer the mature > project you are using in production. > We do have different standards, and I would maintain it is not the IPMC's place to make such judgements. If myself and my fellow community members say certain changes retain its "production" status, then that is how it should be remain labeled. Your/IPMC standards do not apply. Cheers, -g
Re: Podling releases and release policy
On Mon, Jun 3, 2019 at 7:24 PM Craig Russell wrote: > > On Jun 3, 2019, at 2:33 PM, Justin Mclean > wrote: > >... > > I agree, but if you read the disclaimer is says nothing about releases, > perhaps that needs to change? > > Yes, I'd like to change the disclaimer to state that releases cannot be > considered completely reliable, should not be depended on for production, I believe the above two phrases would be unfair to mature projects. In fact, to 95% of all the projects that arrive in the Incubator. The projects *are* reliable and *are* used in production. The only difference is they are learning how to become an Apache-style community. The software doesn't magically "degrade". > might not have passed all normal Apache reviews, etc. > Concur. > I am of the opinion that the board should not need to be involved in > telling the incubator what particular release deficiencies can stop > releases. The incubator can certainly ask the board for advice on proposed > change to policy. > Concur. Cheers, -g
Re: Podling releases and release policy
On Sun, Jun 2, 2019 at 1:22 PM Hen wrote: >... > * Incubating releases are Apache releases. > That is demonstrably not true, as (historically) the Incubator has made releases with GPL'd code in them (eg. Hibernate). Cheers, -g
Re: Podling releases and release policy
On Sat, Jun 1, 2019 at 6:50 PM Justin Mclean wrote: > Hi, > > > Point me to where you are not allowed to make non-official podling > releases > > that conform to Incubator policy. > > I find that hard to parse and perhaps you meant don’t conform to incubator > policy? But either way it’s not incubators policy, it’s the boards and > infra policy. > I was providing the converse: has the IPMC been told *not* to make podling releases? Where such releases conform to its own policy, rather than the Foundation policy? I'm stipulating that "podling release" != "Foundation release", so different policies apply. > I think that approving a release [1], or publication [2] might be your > answer, where it states “Projects SHALL publish official releases and SHALL > NOT publish unreleased materials outside the development community.”. Does > that cover it? > I'm saying that a "podling release" is not an "official [Foundation] release". > > Throw on a disclaimer that the podling release is not a Foundation > > release (already being done!) and you're good to go. > > The disclaimer doesn’t state that or anything about releases. [3] Perhaps > it should? > The disclaimer says "the project has yet to be fully endorsed by the ASF". So I'm saying that the podling release does not have to conform to ASF release policy because it is *explicitly stated* that it is not a release endorsed by the Foundation. Cheers, -g
Re: Podling releases and release policy
On Sat, Jun 1, 2019 at 4:14 AM Justin Mclean wrote: >... > > release policy to something that **is not a Foundation release** > > But don’t these releases become foundation releases when the IPMC vote on > them? > Why should they? The vote is to make a podling release. > They do not need to conform to the Foundation’s policy. > > If you could point me to where this is documented, that would be great. Point me to where you are not allowed to make non-official podling releases that conform to Incubator policy. I don't have a pointer to your request, nor one to my request. Just get on with it. I think you're getting too hung up on "rules", rather than what the Incubator should be about. And part of that is recognizing that projects are in transition, and cannot meet the Foundation release policy on Day One. Yet we also want to demonstrate to podlings what/how to make a release. Throw on a disclaimer that the podling release is not a Foundation release (already being done!) and you're good to go. Bob's your uncle. If it is disturbing you greatly, then codify the position as IPMC policy somewhere, and include a link in your next Board report. I seriously doubt the Board will take issue. It is the stance that I've always understood for the Incubator. Podlings are in a transitional state and are *not* part of the Foundation. Cheers, -g
Re: Podling releases and release policy
On Sat, Jun 1, 2019 at 12:02 AM wrote: > HI, > > > Before putting it to the board, have we ever had a IPMC vote on the > matter? > > Sure if you think one is needed, but probably best to have some discussion > about it first. > It is always best to handle at the PMC-level first, rather than skipping from community discussion straight to the Board. > So perhaps if we set an incubator policy of a podling release being a > > little more lenient > > We do not own the release policy so I don’t think we can change it like > that, but we could ask the board to do so. > I believe the key issue is that you're attempting to apply the Foundation's release policy to something that **is not a Foundation release** That is what the Incubator disclaimer is for. These are podlings' releases. Not Foundation releases. They do not need to conform to the Foundation's policy. Merely the Incubator's policy, whatever that may be (Dave sets out a great list). When a podling graduates and becomes part of the formal structure of the Foundation, *then* the release policy must apply. Cheers, -g
Re: Podling PPMC members and mentors not signed up to private lists
On Sat, May 11, 2019 at 3:43 AM sebb wrote: > On Sat, 11 May 2019 at 09:00, Greg Stein wrote: > > > > On Sat, May 11, 2019 at 2:33 AM sebb wrote: > > > > > On Sat, 11 May 2019 at 02:59, Greg Stein wrote: > > > > On Fri, May 10, 2019 at 2:36 AM Justin Mclean < > jus...@classsoftware.com> > > > > wrote: > > > > >... > > > > > > > > > No one should be subscribed to the private list other than mentors, > > > PPMC > > > > > members and ASF members (who can subscribe to any private list). > > > > > > > > Strictly speaking, a (P)PMC may have invited guests subscribed to > their > > > > private@ list. This is quite unusual, but has some precedent. As you > > > note: > > > > all subscriptions to private@ should be reviewed/moderated. > > > > > > Do such invites need to be recorded somehow? > > > > > > > I don't see why they should. A community invites a person to their > private@ > > list. > > But how does the community decide to invite the person? > I would expect such decisions to be recorded on a mailing list. > I've seen the discussion on a private@ list, and then the invite went out. So, sure: it's on a list. Again: not typical ... it's been too long for me to remember which list we did this on :) Might be possible to find subscribers to private@FOO that have no obvious connection to the FOO PMC. > That person subscribes, the moderator allows. Done. It isn't really a > > significant action. > > IMO allowing access to a private list is a significant act. > Po-tay-toe, po-tah-toe ... situational. I don't find it too significant, but also understand that's just me. Cheers, -g
Re: Podling PPMC members and mentors not signed up to private lists
On Sat, May 11, 2019 at 2:33 AM sebb wrote: > On Sat, 11 May 2019 at 02:59, Greg Stein wrote: > > On Fri, May 10, 2019 at 2:36 AM Justin Mclean > > wrote: > > >... > > > > > No one should be subscribed to the private list other than mentors, > PPMC > > > members and ASF members (who can subscribe to any private list). > > > > Strictly speaking, a (P)PMC may have invited guests subscribed to their > > private@ list. This is quite unusual, but has some precedent. As you > note: > > all subscriptions to private@ should be reviewed/moderated. > > Do such invites need to be recorded somehow? > I don't see why they should. A community invites a person to their private@ list. That person subscribes, the moderator allows. Done. It isn't really a significant action. Communities do not keep minutes/records like the Foundation's Board does, nor should they. Cheers, -g
Re: How to move code and docs from GitHub to GitHub
Yeup. Infra transfers repositories all the time. Just file an INFRA ticket specifying which repositories are to be transferred, and their new names. There are a couple approaches to perform the transfer, and that can be worked out in the ticket. Cheers, Greg Stein Infrastructure Administrator, ASF On Fri, May 10, 2019 at 2:41 PM Brian Devins-Suresh wrote: > Echoing what Dave said, we have had Infra transfer the repos > in instead of just pushing a new version so that we could keep > all issues, release notes, etc > > -Brian > > On Fri, May 10, 2019 at 3:31 PM Dave Fisher wrote: > > > Hi - > > > > I would discuss this with Apache Infra. Either: > > > > join https://the-asf.slack.com - #asfinfra, or > > subscribe to us...@infra.apache.org and send an email. > > > > Regards, > > Dave > > > > > On May 10, 2019, at 12:08 PM, leerho wrote: > > > > > > I am in the process of trying to move code from our current GitHub > > > repositories to the newly assigned Apache incubator GitHub > > repositories. I > > > could use some advice on the best way to do this. > > > > > > So far, I have used the command > > > > > > $ > git push --all --tags --repo=g...@github.com: > > apache/incubator-.git > > > > > > This pushes code and tags from my laptop *clone* of our current repo to > > the > > > apache repo. But it does not transfer important *release > documentation*, > > > which is a feature of the GitHub repo website. > > > > > > Is there a way to effectively copy everything (code, tags, > documentation, > > > etc) directly from our current origin GitHub repo to the Apache repo? > > > Without having to use my laptop clone in the middle? AND without wiping > > out > > > the current origin GitHub repo? > > > > > > Otherwise, I am having to manually copy and paste all the associated > > > release documentation! > > > > > > Any help would be appreciated! > > > > > > Thanks > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: Podling PPMC members and mentors not signed up to private lists
On Fri, May 10, 2019 at 2:36 AM Justin Mclean wrote: >... > No one should be subscribed to the private list other than mentors, PPMC > members and ASF members (who can subscribe to any private list). > Strictly speaking, a (P)PMC may have invited guests subscribed to their private@ list. This is quite unusual, but has some precedent. As you note: all subscriptions to private@ should be reviewed/moderated. Cheers, -g
Re: board report duplication
On Sat, Apr 13, 2019 at 6:27 PM Sam Ruby wrote: >... > In this case, the text format predated the agenda tool. To date, a > design constraint has been to continue to allow the text format be > edited directly (and many of us still find that to be convenient at > times). > One data point: yes, I use the svn command line exclusively to post/edit reports to the agenda. Within Infra at least, we use the philosophy of "Whimsy is great, but we must be able to perform our work without it." In that vein, the Whimsy agenda tool's design constraint seems to follow the same "alternate paths are available" concept. Cheers, -g
Re: [DISCUSS] Graduate Apache NetBeans (incubating) as a TLP
On Mon, Apr 8, 2019 at 12:41 AM Justin Mclean wrote: > Hi, > > >> - What the situation with https://netbeans.org website? > > > > That question is too open-ended. What is your concern? > > No specific concern other than a general branding one. It’s slightly > unusual for a podling to graduate with it’s previous website still in > existence. For (large) pre-existing communities, Branding has stated their existing site is Proper. That we should not gum up the works, and force a change. Nascent communities have been required to move their locus. That said: the prior site is allowed for downstream users. The *community* needs to move to *.apache.org. We have three sites currently operating under non-apache domains: openoffice.org, groovy-lang.org, and netbeans.org. (mighta missed one, but beside the point) ... each of these are to support past/current communities, and have received a +1 from Brand to do so. We also have a counter-point where the established subversion.org/com/net decided to forgo those, and redirect all of them to subversion.apache.org. Infrastructure is kind of a gateway on domain handling. We've seen this, and we work with Brand. I would describe the issue as "Communities MUST construct their presences as FOO.apache.org. For historical purposes they MAY maintain $BAR-DOMAIN." ... Infra has shut down many requests for projects wanting non-apache domains. Totally uncool. Cheers, -g
Re: [DISCUSS] Graduate Apache NetBeans (incubating) as a TLP
On Sun, Apr 7, 2019 at 6:14 PM Justin Mclean wrote: >... > - What the situation with https://netbeans.org website? > That question is too open-ended. What is your concern? Cheers, -g
Re: Podling use of StackOverflow
Totally agreed with Julian here. Community growth is one of the hardest aspects of a healthy, Apache community. It is a never-ending and always-needed process. Shutting out paths to growth, or partitioning where/how people might participate in the community is a clear yellow flag. Reach out and embrace participants no matter where they may congregate, and welcome them and include them into the larger community. Cheers, -g On Thu, Apr 4, 2019 at 1:03 PM Julian Hyde wrote: > It can be frustrating when someone posts a question to both the user list > and to StackOverflow. It means that the community has to answer the > question in two places. > > But like many problems, that is an opportunity. Answering StackOverflow > questions is a great way for people to contribute without writing code. If > you take the view that everyone reading or writing StackOverflow is part of > the community — and I do — then StackOverflow is an excellent way to grow > community. > > Julian > > > > > > On Apr 4, 2019, at 10:33 AM, Ted Dunning wrote: > > > > Just subscribe to appropriate tags on stack overflow and direct > > notifications to the dev list. > > > > Then encourage the community to answer on stack overflow. > > > > > > On Wed, Apr 3, 2019 at 6:32 PM Dave Fisher > wrote: > > > >> I think a user@ mailing list is better for the project’s sustainability > >> and Apache. > >> > >> I have examples related to POI where there is substantial StackOverflow > >> support happening. > >> > >> 12 years ago I became a POI committer for answering user questions. > >> > >> Recently we asked an active StackOverflow answer if he was interested in > >> being a committer and StackOverflow was his community. > >> > >> Apache records are always better than stuff at another company. Gmane > and > >> markmail email links have rotted away. > >> > >> I would encourage a user list for the visibility for the PMC in > >> understanding what’s happening along with a more coherent community! > >> > >> Regards, > >> Dave > >> > >> Sent from my iPhone > >> > >>> On Apr 3, 2019, at 6:02 PM, Alan Gates wrote: > >>> > >>> The superset podling is working out their processes around FAQs and > >>> answering user questions. One thing that they have suggested is that > >> they > >>> encourage people to use StackOverflow for questions and answers given > the > >>> ease of searching old questions, etc. You can see the mail thread at > >>> > >> > https://lists.apache.org/thread.html/1cd1c1e7d02d712ec4e1a13a50cb6016318be5e55ca023b10087cb61@%3Cdev.superset.apache.org%3E > >>> > >>> Personally I think encouraging podlings to use tools they and everyone > >> are > >>> comfortable with and that meet our criteria of being open to all is a > >> good > >>> thing, but I wanted to check if there was official policy on this > before > >>> they proceed with it. > >>> > >>> Alan. > >> > >> > >> - > >> 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: List of Projects that went straight to Top Level Projects
On Mon, Apr 1, 2019 at 1:11 PM Julian Hyde wrote: > Most of the projects mentioned so far have been “internal” Only because all the umbrella-derived projects haven't been mentioned. Most of that "spin out to a TLP" was done a decade ago, so they've been omitted from discussion. > - code developed to help run the ASF. “External” projects also go > straight-to-TLP and are more important because they have many more users > and greater impact on the world. > I recall only two "external" projects have gone straight-to-TLP: Serf, Zest/Polygene. I'm guessing Dave, et al, will surface others, if they exist. I would disagree with your latter statement; they went to TLP based on oversight, rather than on userbase/impact. I would suggest: the 90% of straight-to-TLP have been "internal" or "spun-out". Cheers, -g
Re: List of Projects that went straight to Top Level Projects
On Sun, Mar 31, 2019 at 7:43 AM Justin Mclean wrote: > Hi, > > > Actually, it is pretty easy to tell. The bottom of the resolution will > say > > something like "". Compare Royale[1] (with a discharge of > responsibilities) > > compared to Serf[2]. > > Perhaps? > > Royale has: > "RESOLVED, that all responsibilities pertaining to Apache FlexJS > encumbered upon the Apache Flex Project are hereafter discharged.” > > Flex has: > " RESOLVED, that all responsibilities pertaining to the Apache > Incubator Flex podling encumbered upon the Apache Incubator > Project are hereafter discharged.” > > Whimsey [1] however has nothing similar. > Not sure that I understand your concern. Whimsy and Serf went "straight to TLP", so there is no discharge of responsibilities from "prior ownership". Podlings that graduate (like Flex) have a resolution saying that the Incubator is no longer responsibility for the project. Projects that spin-out (like Royale) say their prior project has no further responsibility for what gets spun out. > But given all board reports are at: > https://whimsy.apache.org/board/minutes/XXX.html > > It may be easy to script that and come up with a list. > Sure. Cheers, -g
Re: List of Projects that went straight to Top Level Projects
On Sun, Mar 31, 2019 at 7:06 AM Greg Stein wrote: > On Sun, Mar 31, 2019 at 6:57 AM Justin Mclean wrote: > >... > >> there. The board resolutions don’t make it clear if it’s straight TLP or >> not from what I can see > > > Actually, it is pretty easy to tell. The bottom of the resolution will say > something like "". > Oop. "that all responsibilities pertaining to $FOO encumbered upon the $BAR are hereafter discharged" >
Re: List of Projects that went straight to Top Level Projects
On Sun, Mar 31, 2019 at 6:57 AM Justin Mclean wrote: >... > there. The board resolutions don’t make it clear if it’s straight TLP or > not from what I can see Actually, it is pretty easy to tell. The bottom of the resolution will say something like "". Compare Royale[1] (with a discharge of responsibilities) compared to Serf[2]. Cheers, -g [1] https://whimsy.apache.org/board/minutes/Royale.html [2] https://whimsy.apache.org/board/minutes/Serf.html
