Re: [IMPORTANT] Board proposal on podling releases
Hi, As mentioned in the board report (under actions) and requested by Roman I’ve raised this issue over on legal-discuss. 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
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. > 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. > We should decouple (a copy of) the disclaimer. Put it next you KEYS > perhaps. Our desire for atomic artifacts causes a lot of our pain. I think that’s an interesting idea. Thanks, Justin
Re: Incubation Pain Points
Speaking on behalf of myself only, though note I am PMC chair of NetBeans, which went through a protracted (nice way of saying ‘complex’) incubation because of its size (‘very large’) and history (20+ years) — the key to any new culture is to adopt its traditions and to fight them as little as possible. And one can’t really understand the culture until one is in it. It’s hard to really prepare — other than to admire projects like Maven or TomEE and to want and aim to be like them, regardless of the contortions required to get there. Gj On Thu, 13 Jun 2019 at 21:10, Dave Fisher wrote: > Hi - > > Here are some thoughts I have to improving Incubation. These are not > really new, but I think we should discuss where and how best to apply these. > > (1) Champions need to very clear that the ASF expects Community decisions > not BDFLs. Burnout is one factor to highlight why community is important. > Vendor independence is important and part of why BDFLs don’t fly. In the > last few years we have deemphasized the role of Champion and I think we > need to list out some of the duties a Champion has to both the prospective > podling community and the Incubator. > > (2) We should help existing communities plan their entry into Incubation > with their proposals. Currently TVM is moving their community over before > repositories. That might be a better approach for many communities as it > will assure that (a) the existing community keeps its current velocity and > (b) they are making community decisions on list before actual development > is moved over. > > (3) Having a lower impedance to release and code changes would really > help. We are already having this discussion. A very radical idea might be > to move a lot of the License, Notice and Dependency work away from the > Release Vote and instead do periodic and potentially automated audits of > repositories. This would follow the REVIEW suggestion, but make it more > automated and based on tooling. > > (4) Relinquishing control of admin rights on GitHub repos is an impedance. > I understand why this is done from an Apache Infrastructure perspective, > but it is a surprise to podling communities. Making sure that a new podling > knows fully what to expect before transferring repos would really help > manage expectations. > > (5) Failure to incubate is not failure. Currently 63 podlings have retired > and there are two or three additional retirements soon. 4 or 5 podlings > moved on or back to where they were. The why of retirement could be > analyzed, but it would need to look into mailing list archives because the > information in podlings.xml is not always clear and is sometimes more > diplomatic than the reality. > > See https://projects.apache.org for an intriguing chart. > > Regards, > Dave > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Incubation Pain Points
Hi - Here are some thoughts I have to improving Incubation. These are not really new, but I think we should discuss where and how best to apply these. (1) Champions need to very clear that the ASF expects Community decisions not BDFLs. Burnout is one factor to highlight why community is important. Vendor independence is important and part of why BDFLs don’t fly. In the last few years we have deemphasized the role of Champion and I think we need to list out some of the duties a Champion has to both the prospective podling community and the Incubator. (2) We should help existing communities plan their entry into Incubation with their proposals. Currently TVM is moving their community over before repositories. That might be a better approach for many communities as it will assure that (a) the existing community keeps its current velocity and (b) they are making community decisions on list before actual development is moved over. (3) Having a lower impedance to release and code changes would really help. We are already having this discussion. A very radical idea might be to move a lot of the License, Notice and Dependency work away from the Release Vote and instead do periodic and potentially automated audits of repositories. This would follow the REVIEW suggestion, but make it more automated and based on tooling. (4) Relinquishing control of admin rights on GitHub repos is an impedance. I understand why this is done from an Apache Infrastructure perspective, but it is a surprise to podling communities. Making sure that a new podling knows fully what to expect before transferring repos would really help manage expectations. (5) Failure to incubate is not failure. Currently 63 podlings have retired and there are two or three additional retirements soon. 4 or 5 podlings moved on or back to where they were. The why of retirement could be analyzed, but it would need to look into mailing list archives because the information in podlings.xml is not always clear and is sometimes more diplomatic than the reality. See https://projects.apache.org for an intriguing chart. Regards, Dave - 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 Thu, Jun 13, 2019 at 02:53 Justin Mclean wrote: > HI, > > > I think that serious = release blocker; > > That would also be my meaning. People / podlings have requested that > release blockers be allowed in podling releases. > > > I'd love to hear some examples. I suspect they are all legal. > > Sure some recent examples (without mentioning any pooling name, but I can > supply links if you want): > - Including code license under a category B license Boring imo. You have to try hard to screw up Cat B (though I’ve seen it done). > - Including code under an unknown license Case by case. Many would be (temporarily) okay imo under a “well it’s clearly published for folk to use”. > - including code under a permissive license, which required you to include > the copyright and license text, but not including that text anywhere > (LICENSE file or file header) Put it on website/release announcements. That partly argues to the disclaimer being partially I dependent of the release > > The last one is probably the most common, especially with Javascript when > license headers seem to be optional. IMO those projects are inducing users to not comply by failing to self-attribute. Any project including jQuery or Bootstrap immediately encounters this as > they have embedded 3rd party code without license headers. > > We’ve allowed all of these situations, although I can also point to > Category B inclusions where we have not allowed them. > > We’ve also allowed GPL dependancy and I think GPL inclusion (would need to > check) with VP legal/VP incubator OK on a once off basis a while back. The > provision being that it was fixed next release. > > All of those would be against the terms of the license, which I assume you > mean by legal? Or do you mean something else by that term? 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. > > > I'd definitely like to see change. My feeling is that there's a lot we > can > > make that falls comfortably within the scope of the Incubator PMC. > > As Roman also suggested, we should discuss this with the legal committee > and come up with a list to give podlings clearer guidance. > > > IIRC the release policies came out of the Incubator; I don't recall > there being a > > request for the board to ratify them, but I might be failing to remember > > something a decade+ ago :) > > From several discussion it been made clear that we don’t own them, the > board does. Interesting enough this say legal affairs does [1] when we’ve > also been told they don’t. :-) In some cases there's been a nice triangle, > where legal, infra and the board all say it someone else responsibility but > not the incubators :-) I’ll agree on that :) personally I speculate that the incubator went over-bureaucracy on the topic a decade ago and there was a unofficial “slowdown” push back that should have been more clearly owned. > > > By that are you suggesting that the text implies a guarantee that those > are > > the only issues? > > Issues can be found in the IPMC vote not the podling vote, so some of > these serious issues won’t be listed in the disclaimer when the IPMC votes > on it. > We should decouple (a copy of) the disclaimer. Put it next you KEYS perhaps. Our desire for atomic artifacts causes a lot of our pain. > Thanks, > Justin > > 1. http://www.apache.org/legal/release-policy.html#administration > > > - > 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 Thu, Jun 13, 2019 at 01:15 Greg Stein wrote: > 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. I hearby suggest we modify TLP policy :) Alex is right. > > > -g > > [deleting entire rest of irrelevant goo] Ever the diplomat ;) > >
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019 at 12:09 PM Bertrand Delacretaz wrote: > ...IOW, base those exceptions on a strictly managed list of acceptable > issues... And add the URL of that list to the DISCLAIMER, so users know what to expect. -Bertrand - 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, On Thu, Jun 13, 2019 at 11:53 AM Justin Mclean wrote: > > I think that serious = release blocker; >...People / podlings have requested that release blockers be allowed in >podling releases... Ok, "release blocker" says much more to me than "serious issues" to which I objected as being too vague. I think this can only work backed by a list of issues (each with a unique ID) which are acceptable for podlings, even though they would not be for a TLP. Then, if new issues are discovered that we think fall into that category, add them to the list subject to Incubator PMC approval. IOW, base those exceptions on a strictly managed list of acceptable issues. -Bertrand - 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 think that serious = release blocker; That would also be my meaning. People / podlings have requested that release blockers be allowed in podling releases. > I'd love to hear some examples. I suspect they are all legal. Sure some recent examples (without mentioning any pooling name, but I can supply links if you want): - Including code license under a category B license - Including code under an unknown license - including code under a permissive license, which required you to include the copyright and license text, but not including that text anywhere (LICENSE file or file header) The last one is probably the most common, especially with Javascript when license headers seem to be optional. Any project including jQuery or Bootstrap immediately encounters this as they have embedded 3rd party code without license headers. We’ve allowed all of these situations, although I can also point to Category B inclusions where we have not allowed them. We’ve also allowed GPL dependancy and I think GPL inclusion (would need to check) with VP legal/VP incubator OK on a once off basis a while back. The provision being that it was fixed next release. All of those would be against the terms of the license, which I assume you mean by legal? Or do you mean something else by that term? > I'd definitely like to see change. My feeling is that there's a lot we can > make that falls comfortably within the scope of the Incubator PMC. As Roman also suggested, we should discuss this with the legal committee and come up with a list to give podlings clearer guidance. > IIRC the release policies came out of the Incubator; I don't recall there > being a > request for the board to ratify them, but I might be failing to remember > something a decade+ ago :) From several discussion it been made clear that we don’t own them, the board does. Interesting enough this say legal affairs does [1] when we’ve also been told they don’t. :-) In some cases there's been a nice triangle, where legal, infra and the board all say it someone else responsibility but not the incubators :-) > By that are you suggesting that the text implies a guarantee that those are > the only issues? Issues can be found in the IPMC vote not the podling vote, so some of these serious issues won’t be listed in the disclaimer when the IPMC votes on it. Thanks, Justin 1. http://www.apache.org/legal/release-policy.html#administration - 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 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
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, then so can podlings, and the IPMC can let more things go without really needing another decision from the board. Or maybe the only question for board or some authority is: Can the IPMC be authorized to allow CatX in podling releases? Ted gave an example in this thread of a legal issue where an attribution required by a dependency's license is missing. I believe I've seen some long-timers say that those are not showstoppers. Nobody is going to sue the ASF over that legal mistake as long as we respond positively towards fixing it in the next release. I also think Ted explained in this thread the "why" behind many release policies more clearly and in fewer words than I recall from incubator documentation when I was in the incubator in 2012. And that might better educate podlings and TLPs on how to make good choices on what can be deferred to a future release. Seems like the only showstoppers for TLPs are: 1) content we have no right to distribute 2) content that distribution would break a law (maybe export restrictions, adult content) 3) CatX content Maybe other legal issues like missing attributions MUST be fixed in the next release. Other release policy violations SHOULD be fixed in the next release. Not sure where to put inclusion of CatB source. Would that also be a showstopper? Podlings would be given flexibility on CatX/CatB, but also have showstoppers for A) missing DISCLAIMER B) missing "-incubating" in the source artifact package name. My 2 cents, -Alex On 6/12/19, 11:44 PM, "Hen" wrote: On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean wrote: > 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? > I don't think we're using the same word meanings. I think that serious = release blocker; but I equally think there are very few items that are serious. > > > 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. > > I'd love to hear some examples. I suspect they are all legal. Speculating hypothetically: * We should never make a release that we know there is some content in that we explicitly do not have permission to publish. * We should never make a release that we know contains content that is criminal (for whatever that would mean). Other than that... I'm not sure what else would come under 'all legal' label. > > 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. > > Yeah. We need a third category for "MehNotBlockingPleaseFix". > > 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. > I'd definitely like to see change. My feeling is that there's a lot we can make that falls comfortably within the scope of the Incubator PMC. IIRC the release policies came out of the Incubator; I don't recall there being a request for the board to ratify them, but I might be failing to remember something a decade+ ago :) > > >> 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. > Gotya :) > > > "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? > By that are you suggesting that the text implies a guarantee that those are the only issues? (Otherwise I'm off into philosophy of whether the unknown can exist when the only test makes it known :) ). "The Foo Project have currently identified the following issues that will need to be resolved before the project
Re: [IMPORTANT] Board proposal on podling releases
On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean wrote: > 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? > I don't think we're using the same word meanings. I think that serious = release blocker; but I equally think there are very few items that are serious. > > > 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. > > I'd love to hear some examples. I suspect they are all legal. Speculating hypothetically: * We should never make a release that we know there is some content in that we explicitly do not have permission to publish. * We should never make a release that we know contains content that is criminal (for whatever that would mean). Other than that... I'm not sure what else would come under 'all legal' label. > > 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. > > Yeah. We need a third category for "MehNotBlockingPleaseFix". > > 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. > I'd definitely like to see change. My feeling is that there's a lot we can make that falls comfortably within the scope of the Incubator PMC. IIRC the release policies came out of the Incubator; I don't recall there being a request for the board to ratify them, but I might be failing to remember something a decade+ ago :) > > >> 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. > Gotya :) > > > "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? > By that are you suggesting that the text implies a guarantee that those are the only issues? (Otherwise I'm off into philosophy of whether the unknown can exist when the only test makes it known :) ). "The Foo Project have currently identified the following issues that will need to be resolved before the project can graduate to an Apache vetted Top Level Project” Any better? > > 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”? > Nope. I was being defensive in my broad statements. For the given question; sure, someone might manage a perfect release someday :) Hen
