airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Riccomini <criccom...@apache.org>
Subject Re: Aiming for an Apache release 1st week of September?
Date Thu, 07 Jul 2016 16:04:08 GMT
> but it's acceptable to have a soft dependency on an LGPL component, such
that a user could deploy the LGPL component separately to enable additional
optional features

This is precisely what I believe is going on with Airflow. It's under an
airflow[postgres] package (so `pip install airflow` doesn't even install
it). We went through a very similar exercise with Samza, where we had a
dependency on Paramiko (also LGPL [1]), and our (LinkedIn) lawyers talked
to Apache, and agreed that it was fine.

[1] https://github.com/paramiko/paramiko/blob/master/LICENSE

On Wed, Jul 6, 2016 at 10:16 PM, Chris Nauroth <cnauroth@hortonworks.com>
wrote:

> Here are more details on Apache release requirements:
>
> http://www.apache.org/dev/release-publishing.html
>
>
> http://www.apache.org/dev/release
>
>
> To summarize, it's much more focused on compliance with licensing, signing
> and Apache infrastructure requirements.  That's the kind of scrutiny that
> a release candidate will get from the Incubator PMC rather than deep
> testing for verification of new features or bug fixes.
>
> For that reason, I think it makes sense for a podling's first Apache
> release to focus on nothing but those ASF policy requirements.  It's
> completely normal for a podling's early release candidates to have a few
> false starts that get voted down, because the policies are complex the
> first time around.  Some projects have found it helpful to write a "How to
> Release" web page during the first release, so that they have step-by-step
> notes to follow during subsequent releases.  Focusing on "latest stable"
> with a few additional patches sounds like a great plan to me, because it
> decouples the challenges of your first ASF release from other software
> development pressures, such as pressure from a user base to ship a new
> feature quickly.
>
> Regarding the LGPL question, in general, the answer is that we are
> prohibited from redistributing any LGPL component, but it's acceptable to
> have a soft dependency on an LGPL component, such that a user could deploy
> the LGPL component separately to enable additional optional features.
> More details are here:
>
> http://www.apache.org/legal/resolved.html#prohibited
>
>
> A specific example of this is Apache Hadoop's integration with LZO
> compression, which uses a GPL license.  Hadoop does not redistribute LZO
> or include any code that is tightly coupled to it, but the Hadoop codebase
> does have a notion of a pluggable CompressionCodec, with implementations
> of the interface discoverable at runtime.  This setup supports users
> downloading and installing a separate LZO integration library onto
> Hadoop's classpath.
>
> --Chris Nauroth
>
>
>
>
> On 7/6/16, 9:36 PM, "Maxime Beauchemin" <maximebeauchemin@gmail.com>
> wrote:
>
> >Hi,
> >
> >This sounds very reasonable to me, though we may be able to do an earlier
> >release as a practice run for an Apache release with a snapshot of our
> >production which would consists of the latest release plus a set of cherry
> >picked PRs.
> >
> >How does an Apache release differ from a standard release again?
> >
> >Max
> >
> >On Wed, Jul 6, 2016 at 7:59 PM, Chris Riccomini <criccomini@apache.org>
> >wrote:
> >
> >> One other thing to note is that I'm planning to run the RCs in all of
> >>our
> >> environments to exercise things. We should make sure that we're all
> >> committed (as well as the community) to burning the RCs in on our
> >> respective environments for a few weeks.
> >>
> >> On Wed, Jul 6, 2016 at 7:58 PM, Chris Riccomini <criccomini@apache.org>
> >> wrote:
> >>
> >> > Hey Bolke,
> >> >
> >> > > should we aim for a release 1st week of September
> >> >
> >> > Sounds good to me!
> >> >
> >> > > I would want to aim earlier, but due to holidays I guess it might
be
> >> > smarter to schedule it a bit after?
> >> >
> >> > So would I, personally. I'd be OK with starting RCs now, to be frank.
> >> What
> >> > do others think?
> >> >
> >> > > Should we vote on the above?
> >> >
> >> > No need, IMO. A discuss like this is enough, assuming there are no
> >> > objections.
> >> >
> >> > Re: psycopg2, I don't think it's an issue, but we should probably
> >>file a
> >> > LEGAL [1] just to be sure. In any case, we don't have to be compliant
> >> for a
> >> > release in incubator, I believe. We just need to be moving in that
> >> > direction.
> >> >
> >> > Cheers,
> >> > Chris
> >> >
> >> > [1] https://issues.apache.org/jira/browse/LEGAL
> >> >
> >> > On Wed, Jul 6, 2016 at 1:24 PM, Bolke de Bruin <bdbruin@gmail.com>
> >> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> As I don¹t think there are any show stoppers to have an Apache
> >>release
> >> >> should we aim for a release 1st week of September? I would want to
> >>aim
> >> >> earlier, but due to holidays I guess it might be smarter to schedule
> >>it
> >> a
> >> >> bit after?
> >> >>
> >> >> - RC last week of August giving about two weeks to have it run in
> >> >> production in our environments
> >> >> - Guess voting needs to happen at the IPMC
> >> >> - Release (Champagne!)
> >> >>
> >> >> Earlier there was some discussion about psycopg2 / postgres
> >> >> interoperability (psycopg2 being LGPL). Personally I don¹t think
> >>there
> >> is
> >> >> an issue as we are not redistributing psycopg2 ourselves and we are
> >>not
> >> >> dependent on it to function. An company can choose thus what they
> >>want
> >> >> without being `tainted` by the LGPL. Any remarks on this?
> >> >>
> >> >> Should we vote on the above?
> >> >>
> >> >> - Bolke
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
>
>

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