airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <>
Subject Re: Aiming for an Apache release 1st week of September?
Date Thu, 07 Jul 2016 05:16:04 GMT
Here are more details on Apache release requirements:

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:

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" <> wrote:

>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?
>On Wed, Jul 6, 2016 at 7:59 PM, Chris Riccomini <>
>> One other thing to note is that I'm planning to run the RCs in all of
>> 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 <>
>> 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]
>> >
>> > On Wed, Jul 6, 2016 at 1:24 PM, Bolke de Bruin <>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> As I don¹t think there are any show stoppers to have an Apache
>> >> should we aim for a release 1st week of September? I would want to
>> >> earlier, but due to holidays I guess it might be smarter to schedule
>> 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
>> is
>> >> an issue as we are not redistributing psycopg2 ourselves and we are
>> >> dependent on it to function. An company can choose thus what they
>> >> without being `tainted` by the LGPL. Any remarks on this?
>> >>
>> >> Should we vote on the above?
>> >>
>> >> - Bolke
>> >>
>> >>
>> >>
>> >>
>> >

View raw message