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 <bay...@apache.org> 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 <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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
