Re: [IMPORTANT] Board proposal on podling releases
There's been a lot of discussion on relaxing requirements, but I don't recall
any long-time ASF person explaining how fragile or durable the legal-shield and
the insurance rates for it are.
Ted and Roy (in other threads) seem to have said that Ted's bucket #1 is the
only thing that is a true showstopper. And Ted's adds a bucket #2 for TLPs.
So maybe even for TLPs, all other issues can be punted to a next release.
Maybe that's the only clarification that is needed from the board. That no TLP
will be frowned upon for deferring anything outside of bucket #1 and #2 to a
future release and additionally no Podling will be frowned upon for deferring
anything in bucket #2 to a future release.
Unless someone can explain why that would ruin the legal-shield or raise
insurance rates, I think that would save lots of community time getting
releases out. Otherwise, we might be expending precious energy overzealously
trying to protect a legal-shield that doesn't need that level of protection.
Does anybody truly know what will and will not ruin the legal-shield? I have
to imagine that releases have been shipped by the ASF and later found to be
non-compliant with policy and that didn't ruin the legal shield or raise
insurance rates.
Of course, I could be wrong...
-Alex
On 6/9/19, 9:13 PM, "Greg Stein" wrote:
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: [DISCUSS] Release of Apache Training - Navigating the ASF Incubator Process 1.0 (incubating)
Hi, > This is very interesting. I’m going to be digging into it. There is also another presentation on releases, that will be up for vote in the near future, [1] feedback welcome on that as well. It's content may be subject to change :-) Thanks, Justin 1. https://github.com/apache/incubator-training/pull/28 - 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
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. :-) > 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? I'st a release by the incubator PMC and thus needs to follow ASF policies, do you consider the incubator a TLP or not? As to why was it originally done this way, that’s before my time so I don’t actually know. Perhaps someone else can find or comment on that. > It seems there is some consensus that podling releases are getting jammed > up by IPMC rules. No exactly a) release policy is not IPMC rules. b) The large majority of releases have no issues. c) Where a -1 happens it for a good reason. > Assuming that is true, then why not question the vote process itself? Sure but that is side tracking this thread which is on the actual proposal to the board. > 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. PPMC votes are not binding on releases, again exactly why it was set up this way I do not know, but I guess it because they are just learning about the process and not a "full citizen” yet. You need 3 + 1 binding votes from the PMC and more +1s than -1s to make a release. > Wouldn't that be acceptable? I have no idea, it probably break several ASF bylaws / policies which are not set by the IPMC and it don’t follow what TLP projects do. I’m fairly sure that the IPMC can't ignore those policies without permission from the board. Hence why this proposal exists. > What other way? Link? Publicity for this? See [1], there was a large amount of discussion about this onlist and it was in a recent board report, so the mentors should be aware of it. There was also an alternative voting process put forward 3 or 4 years ago. Thanks, Justin 1. https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E - 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 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
On Sun, Jun 9, 2019 at 8:20 PM Justin Mclean wrote: > > Hi, > > > Big +1 to the above. I would strongly suggest trying to resolve > > this first between IPMC and ASF Legal Committee > > JFYI - I’ve tried to do this before and was told (by aboard member) it was > the boards policy not the Legal Committer. All policy is ultimately a board policy (well, you know ;-)) so what I was suggesting is that a draft is worked on the legal committee side and then submitted to the board if needed. Thanks, Roman. - 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
Hi, > Big +1 to the above. I would strongly suggest trying to resolve > this first between IPMC and ASF Legal Committee JFYI - I’ve tried to do this before and was told (by aboard member) it was the boards policy not the Legal Committer. Thanks, Justin
Re: [IMPORTANT] Board proposal on podling releases
A few comments based on various excellent previous posts: On Sun, Jun 9, 2019 at 12:34 AM Hen wrote: > I don't see a need to go to the board on this :) Big +1 to the above. I would strongly suggest trying to resolve this first between IPMC and ASF Legal Committee On Sun, Jun 9, 2019 at 6:33 PM Ted Dunning wrote: > > There are three kinds of release constraints at Apache. Only one is > critical for new podlings. > > 1. Legal constraints on whether Apache has the right to distribute the > source code in question and link to any non-source dependencies. This > mostly applies to projects coming out of commercial entities, but I would > lump adversarial forks of open source projects into this category. Note > that GPL inclusions are not a problem at this level, since they still allow > us to make a source release legally. > > My feeling is that this is the only truly non-negotiable item for a podling > release made at Apache. Agreed 100%. > 2. Downstream constraints on users. Mature projects at Apache provide good > guarantees that using the release will not have limited allowable field of > use or strange license terms. This is a MUST-DO for a top-level project > release, but it is plausible to allow this for early podling releases with > LOTs of disclaimers and warning signs. Examples of this are GPL inclusions, > the JSON.org "don't be evil" license, non-commercial licenses and > non-optional binary dependencies that are not open source. All of these > could plausibly be allowable in an incubating release if the fact that the > release doesn't have the normal safety of an Apache release. > > 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. Later on, whether to allow graduation with non-trivial DISCLAIMER file can be decided on a case-by-case basis. > 3. Infrastructural impact on Apache itself. This means that a project can't > require that infra rebuild their systems just to accommodate some > idiosyncratic strangeness of the podling. This is typically a pretty strict > constraint, but is reasonable to waive for early releases if, say, the > podling uses non-Apache resources on an interim basis or if the project > really does have some special needs and infra is willing to help. > > Again, this issue probably has to be dealt with one way or another before > graduation. Agreed. Thanks, Roman. > > > > > > On Sun, Jun 9, 2019 at 5:41 PM Greg Stein wrote: > > > 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
Re: [IMPORTANT] Board proposal on podling releases
There are three kinds of release constraints at Apache. Only one is critical for new podlings. 1. Legal constraints on whether Apache has the right to distribute the source code in question and link to any non-source dependencies. This mostly applies to projects coming out of commercial entities, but I would lump adversarial forks of open source projects into this category. Note that GPL inclusions are not a problem at this level, since they still allow us to make a source release legally. My feeling is that this is the only truly non-negotiable item for a podling release made at Apache. 2. Downstream constraints on users. Mature projects at Apache provide good guarantees that using the release will not have limited allowable field of use or strange license terms. This is a MUST-DO for a top-level project release, but it is plausible to allow this for early podling releases with LOTs of disclaimers and warning signs. Examples of this are GPL inclusions, the JSON.org "don't be evil" license, non-commercial licenses and non-optional binary dependencies that are not open source. All of these could plausibly be allowable in an incubating release if the fact that the release doesn't have the normal safety of an Apache release. 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. 3. Infrastructural impact on Apache itself. This means that a project can't require that infra rebuild their systems just to accommodate some idiosyncratic strangeness of the podling. This is typically a pretty strict constraint, but is reasonable to waive for early releases if, say, the podling uses non-Apache resources on an interim basis or if the project really does have some special needs and infra is willing to help. Again, this issue probably has to be dealt with one way or another before graduation. On Sun, Jun 9, 2019 at 5:41 PM Greg Stein wrote: > 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
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? > 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. That's ASF policy / bylaws not incubator policy. We could look into changing this, but probably best discussed in another thread. 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. IPMC votes also pick up things the podlings/mentors miss, about 1 in 5 releases have a serious issue that the IPMC finds. That I think is a valuable service, one that we may not want to throw away. One way perhaps to deal with that is mentor education / engagement. 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. Thanks, Justin - 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
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
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
Hi, > I agree with other respondents that 'serious' seems bad here. To me the > serious ones are the only ones they can't release with. So we just continue as is then? You have any suggests to what we change? > ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies > with the license via some mechanism. We currently allow releases that are not strictly legal. This would be a step backwards. > GraduationBlocking: Everything else; including complying with the license > via our preferred mechanism (i.e. we might want the MIT license text in our > LICENSE file, but would accept it being in the source header of the files > themselves). We currently allow podlings to graduate with some issues as longs as the PPMC is dealing with them. This would be a step backwards. > I don't see a need to go to the board on this :) If we don’t want to change anything - sure there's no need to go to the board. >> issues have been fixed. The IPMC will add additional information to the > incubator DISCLAIMER to cover that podling release may not abide by all > > The IPMC? That sounds like a people scaling problem. The podling committee > should handle it. I mean just changing this page [1] , podlings can update their own disclaimers. > "This release still has the following issues that will need to be resolved > before the Foo Project can graduate to an Apache vetted Top Level Project” What about unknown issues? > Are the board lawyers? :) Until you have a well-defined list, I doubt > anything could be confirmed. I'd go with: "Conceptually what you describe > could lead to a situation where a PPMC releases a project fully compliant > with the ASF's expectations. “ I assume you mean “not fully compliant”? Thanks, Justin 1. https://incubator.apache.org/guides/branding.html#disclaimers - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Release of Apache Training - Navigating the ASF Incubator Process 1.0 (incubating)
Hi - This is very interesting. I’m going to be digging into it. Regards, Dave > On Jun 8, 2019, at 8:09 PM, Justin Mclean wrote: > > Hi, > > Please keep the discussion here and not in the vote thread, > > Even if not voting, mentors and IPMC members may want to talk a look at the > material as it is based on several years of talks at ApacheCon and elsewhere. > The idea here is that any IPMC person should be able to take this material > and use it to give an incubating talk at a conference or inside your company. > Feedback, pull requests etc etc also welcome. > > For those who make their own slides you might also want to take a look as it > uses maven to compile asciidoctor (improved markdown) to a reveal.js slide > show (with timer and speaker notes and other features) this also means that > your slides content can be put under version control and it easier to work > collaborative on it. It also possible to covert the output to pdf or power > point. They look quite nice as well. > > 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: [IMPORTANT] Board proposal on podling releases
Top Post. (1) We are losing track of the goal. The goal is to make it easier for incubating projects to begin to follow Foundation Release and Distribution Policies on their path to adopting the Apache Way, building a Community and graduating to become a TLP project. I think the IPMC has overcorrected and we emphasize Release Policy over Community Building. (2) We all know that for many incubating projects immediately requiring full Release Policy compliance is too steep a slope. (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. (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. (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. (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”. All that said inline with Henry below. > On Jun 9, 2019, at 12:34 AM, Hen wrote: > > Copying the proposal in so I have something to respond to :) > >> Proposal >> >> That the IPMC can allow releases with serious issues in them to be > released and distributed without IPMC or legal VP approval. When this > occurs > > I agree with other respondents that 'serious' seems bad here. To me the > serious ones are the only ones they can't release with. > > ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies > with the license via some mechanism. I would add DISCLAIMER to this. > GraduationBlocking: Everything else; including complying with the license > via our preferred mechanism (i.e. we might want the MIT license text in our > LICENSE file, but would accept it being in the source header of the files > themselves). > > I don't see a need to go to the board on this :) Agreed as this is a main purpose to the Incubator. > >> podling will documents the issue as one blocking graduation and carry on > incubating. They will not be allowed to graduate until all serious release > > +1 to documenting it as BlocksGraduation :) Noting the 'serious' here > again. This would be my point (5) above > >> issues have been fixed. The IPMC will add additional information to the > incubator DISCLAIMER to cover that podling release may not abide by all > > The IPMC? That sounds like a people scaling problem. The podling committee > should handle it. This is part of a podling’s status and the IPMC should make it easy to report. > >> terms of the ALv2 and may contain code under an incompatible license. > > Incompatible is such a vague word. It's also very specific to one type of > GraduationBlocking issue. I would stick to: > > "This release still has the following issues that will need to be resolved > before the Foo Project can graduate to an Apache vetted Top Level Project" > (or some such; I really want to say Apache-Certified Community, but that's > a different argument. Exactly. Documenting where a particular podling’s product release is on the path to graduation can allow downstream users of the podling’s release to assess their risk. > >> All releases and podling web sites will be updated to include this where >> required. > > This is a given. I think that IPMC should provide a mechanism in addition to a directive. > >> >> Notes >> >> The IPMC will come up with a well-defined list of those serious issues > and distribute to mentors, IPMC members and podlings so that everyone's >> expectations are clear. This proposal does not change the need for an > IPMC vote on podling releases. > > Redefining "serious issues" to mean ones that block a release; they should > be writeable on the back of a couple of business cards. Taking serious > issues as ones that are not actually serious and only graduation blockers; > then +1. It should still be short, but a piece of paper seems good :) A simple checkbox list similar to what we have in the podling status page. > >> Can the board also confirm that the ASF's legal shield would cover people > making releases under this proposal? > > Are the board lawyers? :) Until you have a well-defined list, I doubt > anything could be confirmed. I'd go with: "Conceptually what you describe > could lead to a situation where a PPMC releases a project fully compliant > with the ASF's expectations. “ There are too many hypotheticals. We need a pan without hypotheticals. We need a holistic plan. Regards, Dave > > Hen > > > > > On Thu, Jun 6, 2019 at 11:45 PM Justin Mclean >
Re: [VOTE] Release Apache OpenWhisk Runtimes v1.13.0-incubating
Hi, Sorry to be clearer re the short header issue I suggest you read [1]. It may be used with mages, minified JavaScript or PDFs, that’s not the case where it’s been used in your releases and this has been pointed out several times. If there are other cases where you have confirmed with legal-discuss that OK to use then please point them out. While this is only a minor issue, but its vest to comply with ASF policy. What I consider a little more serious is that issues nee reoccurring after they have been pointed out. Thanks, Justin 1. https://www.apache.org/legal/src-headers.html#is-a-short-form-of-the-source-header-available - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenWhisk Runtimes v1.13.0-incubating
> > We've also discussed the use of "short licenses" [5] and we document our > use of the short licenses > > Which I see was some time ago but this keeps happening in your releases. > You are correct that we have an outstanding item to tighten our automated checks inline with the project's documented policy. But I'm not sure if you're implying we're doing something wrong. We don't believe the use of short license is out of line with Apache policy https://www.apache.org/legal/src-headers.html. We document which files get short licenses or license exclusions here: https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md -r
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
Hi, > I conclude that all are left over from before the project entered the Apache > Incubator and the period of transition that followed. I though that was the case bur was just checking. But beauty IBM need to be respectful of the trademark and the (P)PMC make sure they do that. > The github projects in the IBM organization appear to not be maintained > actively This is a potential trademark issue IMO and I suggest you discuss it with trademarks what to do here, previous experience there are usually renamed or removed. Hopefully someone else can provide some insight with what going on with docker. Thanks Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenWhisk Runtimes v1.13.0-incubating
Hi, > For several of the issues you noted, I opened github defects [1-4] against > the relevant repos so that we will address them before the next release of > the corresponding artifacts. Thanks for that. > We've also discussed the use of "short licenses" [5] and we document our use > of the short licenses Which I see was some time ago but this keeps happening in your releases. Thanks, Justin
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
Thanks for these links. I went through many of the links you provided and conducted my own search as well. I conclude that all are left over from before the project entered the Apache Incubator and the period of transition that followed. We addressed the use of IBM OpenWhisk and Bluemix OpenWhisk over several months of transition. As you might now, the project did originate out of IBM but the OpenWhisk trademark has been fully transferred now, and more over, IBM rebranded their Apache OpenWhisk offering to IBM Cloud Functions after induction into the incubator. I find adequate references to Apache OpenWhisk in the current IBM documentation. Maybe we're seeing different results of a google "OpenWhisk" search but the snippet of result for IBM Cloud I saw clearly uses Apache OpenWhisk and not IBM OpenWhisk: "Based on Apache *OpenWhisk*, IBM Cloud Functions is a polyglot functions-as-a-service (FaaS) programming platform for developing lightweight code that scalably executes on demand. ... IBM Cloud Functions provides access to the Apache *OpenWhisk* ecosystem in which anyone can contribute ..." [image: Screen Shot 2019-06-09 at 9.05.34 AM.png] The github projects in the IBM organization appear to not be maintained actively and reference Apache OpenWhisk clearly on the landing pages and README. There were several projects that at the time of induction we did not feel we needed to move to Apache and in fact we moved too many - some of which we have to now archive as we have abandoned and not maintaining. They are helper projects or experiments and not part of the core system. Are you suggesting we ask their maintainers to rename them? There is no such plan and it has not been discussed as far as I know. We are aware of that the PMC is responsible for managing their brand and trademarks and have discussed (on private list) whether action is required in the past for other instances. As someone who was one of the founding members of the project at IBM and who no longer is at IBM, I have no doubts the project was has well out grown its IBM roots. I did open an issue to address the reference to "IBM OpenWhisk" [1]. [1] https://github.com/serverless/serverless-openwhisk/issues/171 -r On Fri, Jun 7, 2019 at 10:22 PM wrote: > Hi, > > Some of the answer be be obvious here to someone who works on the project, > and already been discussed and sorted on your mailing list. So apologies if > that the case, I’m not involved with your project, so I’m just asking to > get clarity. > > A google search turns up mention of “IBM OpenWhisk” and a logo very > similar to the OpenWhisk one. e.g [1] Is the project aware of and dealing > with the branding/trademark issues here? Is this just left over from before > the project entered incubation? > > The also a lot of pages that refer to "Bluemix OpenWhisk” e.g [4] on the > IBM website. Or this page with “OpenWhisk” [5] in the URL and title but no > clear mention it’s an Apache product. > > If I google search for Openwhisk and cloud I see this result in google: > > IBM Cloud > https://www.ibm.com/cloud > Open source. Quicklinks. All open source projects · Tutorials and > training. Try OpenWhisk on Bluemix. Get started with serverless, > event-driven computing in the … > > Again Apache is not mentioned. > > Are you concerned that this may make people think that OpenWhisk in not an > Apache product and give the impression that it's owned by IBM? > > I can also see that IBM has a number of gtihub repos using the name > OpenWhisk, what’s the plan for them? > > I notice you docker images (which are labeled as part of the ASF but oddly > use the openwhisk.org domain) [6] seem to pull down the latest code > rather than approved released version. Do you think this is in line with > ASF release policy? > > Thanks, > Justin > > 1. https://serverless.com/framework/docs/providers/openwhisk/ > 2. https://github.com/IBM/openwhisk-getting-started-template > 3. https://github.com/IBM/expressjs-openwhisk > 4. > https://developer.ibm.com/tv/ibm-expands-bluemix-openwhisk-to-support-rapid-app-development/ > 5. https://developer.ibm.com/tv/openwhisk/ > 6. https://hub.docker.com/u/openwhisk > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
> I also note that you’ve been given feedback on several releases that have > had mirror issue, but the issues don’t seem to have been fixed. Is there a > plan to do so before graduation? e.g > https://lists.apache.org/thread.html/041045024538dd9d3d7bf4b32701260a63996c48e115194302dcf0c1@%3Cgeneral.incubator.apache.org%3E I had responded to that feedback and the issues you documented with links to github issues that we will address before the next release of the corresponding artifacts [1] and I just went through your feedback again to see if there was anything missed and provide an update here [2]. [1] https://lists.apache.org/thread.html/98dc0a366d53875b49210fcaa321aeafce345da4fc8944b2544f9b2f@%3Cgeneral.incubator.apache.org%3E [2] https://lists.apache.org/thread.html/db63d274374d0efd810814570d7765abee2301d36f31cabd26b0b24c@%3Cgeneral.incubator.apache.org%3E -r
Re: [VOTE] Release Apache OpenWhisk Runtimes v1.13.0-incubating
For several of the issues you noted, I opened github defects [1-4] against the relevant repos so that we will address them before the next release of the corresponding artifacts. We've also discussed the use of "short licenses" [5] and we document our use of the short licenses and license exclusions (noted for gradle) here [6] per Apache guidance [7]. [1] https://github.com/apache/incubator-openwhisk-runtime-docker/issues/69 [2] https://github.com/apache/incubator-openwhisk-runtime-python/issues/58 [3] https://github.com/apache/incubator-openwhisk-runtime-go/issues/87 [4] https://github.com/apache/incubator-openwhisk-runtime-go/issues/91 [5] https://lists.apache.org/thread.html/bbec59cc560d446a4239627dcb463bc95fb98be5eb66d525f93e5ef1@%3Cdev.openwhisk.apache.org%3E [6] https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md [7] https://www.apache.org/legal/src-headers.html > - The go LICENSE incorrectly states you should add "Copyright 2015-2016 IBM > Corporation” to your own files > - the text of the license for Filetype 1.0.5 is not included (as required by > it's license). The pointer to the licenses should point to a copy of the > license in distribution as licenses and URLs can change over time. The license was corrected and is now the Apache license with no added text. The references to filetype were no longer relevant but > - How is this file licensed? [3] Even if is it a “free” license it may have > terms around distribution that make it incompatible with the Apache license, > and even if not then it still good to list it in LICENSE. > > Thanks,. > Justin > > 1. > ./incubator-openwhisk-runtime-docker-1.13.0-incubating/sdk/docker/buildAndPush.sh > 2. ./incubator-openwhisk-runtime-go-1.13.0-incubating/examples/Makefile > 3. > ./incubator-openwhisk-runtime-python-1.13.0-incubating/core/python3AiAction/samples/smart-body-crop/fashion-men-1.jpg > > > - > 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: [IMPORTANT] Board proposal on podling releases
Copying the proposal in so I have something to respond to :) > Proposal > > That the IPMC can allow releases with serious issues in them to be released and distributed without IPMC or legal VP approval. When this occurs I agree with other respondents that 'serious' seems bad here. To me the serious ones are the only ones they can't release with. ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies with the license via some mechanism. GraduationBlocking: Everything else; including complying with the license via our preferred mechanism (i.e. we might want the MIT license text in our LICENSE file, but would accept it being in the source header of the files themselves). I don't see a need to go to the board on this :) > podling will documents the issue as one blocking graduation and carry on incubating. They will not be allowed to graduate until all serious release +1 to documenting it as BlocksGraduation :) Noting the 'serious' here again. > issues have been fixed. The IPMC will add additional information to the incubator DISCLAIMER to cover that podling release may not abide by all The IPMC? That sounds like a people scaling problem. The podling committee should handle it. > terms of the ALv2 and may contain code under an incompatible license. Incompatible is such a vague word. It's also very specific to one type of GraduationBlocking issue. I would stick to: "This release still has the following issues that will need to be resolved before the Foo Project can graduate to an Apache vetted Top Level Project" (or some such; I really want to say Apache-Certified Community, but that's a different argument. > All releases and podling web sites will be updated to include this where > required. This is a given. > > Notes > > The IPMC will come up with a well-defined list of those serious issues and distribute to mentors, IPMC members and podlings so that everyone's > expectations are clear. This proposal does not change the need for an IPMC vote on podling releases. Redefining "serious issues" to mean ones that block a release; they should be writeable on the back of a couple of business cards. Taking serious issues as ones that are not actually serious and only graduation blockers; then +1. It should still be short, but a piece of paper seems good :) > Can the board also confirm that the ASF's legal shield would cover people making releases under this proposal? Are the board lawyers? :) Until you have a well-defined list, I doubt anything could be confirmed. I'd go with: "Conceptually what you describe could lead to a situation where a PPMC releases a project fully compliant with the ASF's expectations. " Hen On Thu, 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 > >
