Re: There's a missing state in the state diagram for the incubator

Hi, Given the code is under ALv2 anyone can that fork the code and go elsewhere at anytime. Whoever does that would need to respect the name however and wouldn’t be allowed to call it the same name of the Apache project. For a podling to formally leave they would need to do ask the IPMC to

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*

There's a missing state in the state diagram for the incubator

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

Mentor sign off due Tuesday June 11th

Hi, It’s good to see a number of podlings have been signed off by at least one mentor. Congratulations to Crail for have all mentors already sign off their report and to Nemo who has 4 sign-offs. Current podlings (excluding the non reporting ones) with no mentor sign off are: DataSketches

Re: Podling reports due Wednesday

HI, Podling reports are now due. Thanks to all who submitted their report in on time. Missing from the report are: BRPC DLab Iceberg Marvin-AI Tuweni Thanks, Justin - To unsubscribe, e-mail:

Re: [CONF] INCUBATOR > June2019

Hi, > I'm afraid these notices are almost worthless. Yep I ageee. > Is there a way to get a diff instead of the entire document? You can get a visual diff on the web page, but no way to see a simple diff that I know of. Thanks, Justin

Re: Podling releases and release policy

Yes it is. We’ll be appropriating this concept. On 5 Jun 2019, at 1:17, Greg Stein wrote: > 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 Sun, Jun 2, 2019 at 2:23 PM Hen wrote: > > Wrote a long thing... decided it wasn't useful :) > > The tldr; > > * Incubating releases are Apache releases. No user cares if they are > endorsed or official (for whatever they may mean). Perhaps if we said GA we > might be clearer. Agreed. We

Re: Podling releases and release policy

Given that [1] says "may" and not "will" and that Roy has said that if it isn't illegal and better than the last release it is ok to ship a release candidate, maybe the ASF should adopt the approach that every release policy issue that isn't about the legal right to distribute some IP can be

Re: late learnings, which could be helpful for all mentors to know

>> Instead of having to actually DO releases, at least Release Candidates >> should be created ... this would prove the general ability to do a release, >> but not actually DO it. Of course if these RCs contain bad things, they >> should not pass. > > I suspect in some cases there are repos

Re: late learnings, which could be helpful for all mentors to know

Hi, Also seriously don’t stress about this, as a podling you are not expected to know everything and learn as you go along. Try to ask your mentors for help and involve them more, they can help with stuff like this, Thanks, Justin

Re: late learnings, which could be helpful for all mentors to know

Hi, > That's exactly what we tried and were given grief about. We waited > until 3 binding +1 votes, which is for practical purposes all of our > active mentors To be accurate this was tried without any discussion about this decision on a mailing list (that I could find). IMO (and others may

Re: late learnings, which could be helpful for all mentors to know

> If the mentors on the project list have voted +1, then the vote can be > continued in parallel? Shouldn't this help reduce both the time votes take > but not waste the limited IPMC bandwidth? That's exactly what we tried and were given grief about. We waited until 3 binding +1 votes, which is

Re: late learnings, which could be helpful for all mentors to know

How about this as compromise? If the mentors on the project list have voted +1, then the vote can be continued in parallel? Shouldn't this help reduce both the time votes take but not waste the limited IPMC bandwidth? Regarding releasing of all repos ... how about this: Instead of having to

Re: late learnings, which could be helpful for all mentors to know

Hi, Please take this as friendly advice with with a bit of experience and personal opinion thrown in. (if that intent is not obvious). > * "parallel votes" is a technique to reduce the lag between dev@ and > general@ by starting the IPMC vote slightly after, but before > conclusion of the PPMC