A few comments based on various excellent previous posts: On Sun, Jun 9, 2019 at 12:34 AM Hen <bay...@apache.org> wrote: > I don't see a need to go to the board on this :)
Big +1 to the above. I would strongly suggest trying to resolve this first between IPMC and ASF Legal Committee On Sun, Jun 9, 2019 at 6:33 PM Ted Dunning <ted.dunn...@gmail.com> wrote: > > 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. Agreed 100%. > 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. I would suggest we make it a policy to document those exceptions in the DISCLAIMER file. Later on, whether to allow graduation with non-trivial DISCLAIMER file can be decided on a case-by-case basis. > 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. Agreed. Thanks, Roman. > > > > > > 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 > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
