incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Mon, 10 Jun 2019 00:41:21 GMT
The entire note below sounds like "business as usual. we haven't learned

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.


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
> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message