incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Mon, 10 Jun 2019 02:30:05 GMT
A few comments based on various excellent previous posts:

On Sun, Jun 9, 2019 at 12:34 AM Hen <bayard@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.dunning@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 <gstein@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 <justinmclean@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-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message