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 <jus...@classsoftware.com> 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 > >
