There are three kinds of release constraints at Apache. Only one is critical for new podlings.
1. Legal constraints on whether Apache has the right to distribute the source code in question and link to any non-source dependencies. This mostly applies to projects coming out of commercial entities, but I would lump adversarial forks of open source projects into this category. Note that GPL inclusions are not a problem at this level, since they still allow us to make a source release legally. My feeling is that this is the only truly non-negotiable item for a podling release made at Apache. 2. Downstream constraints on users. Mature projects at Apache provide good guarantees that using the release will not have limited allowable field of use or strange license terms. This is a MUST-DO for a top-level project release, but it is plausible to allow this for early podling releases with LOTs of disclaimers and warning signs. Examples of this are GPL inclusions, the JSON.org "don't be evil" license, non-commercial licenses and non-optional binary dependencies that are not open source. All of these could plausibly be allowable in an incubating release if the fact that the release doesn't have the normal safety of an Apache release. I would expect that any graduating podling has this under control before graduating and will not make any TLP releases with this kind of defect. 3. Infrastructural impact on Apache itself. This means that a project can't require that infra rebuild their systems just to accommodate some idiosyncratic strangeness of the podling. This is typically a pretty strict constraint, but is reasonable to waive for early releases if, say, the podling uses non-Apache resources on an interim basis or if the project really does have some special needs and infra is willing to help. Again, this issue probably has to be dealt with one way or another before graduation. On Sun, Jun 9, 2019 at 5:41 PM Greg Stein <gst...@gmail.com> wrote: > 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 > > > > >
