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? maaaaaaaybe 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 <justinmcl...@me.com> 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 > >
