Mailing-List: contact dev-help@airflow.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airflow.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <3F9528F4-9976-4860-9F69-C0FD57C10969@gmail.com>
References: <D44C6845-3A4D-41A0-A9CD-7BFC6FECFBBB@gmail.com>
 <CABYbY7fGP=uf_29HHo22b5jMiVM_DO8wi_EvoQV3UCAJ-Qerpw@mail.gmail.com>
 <CABYbY7d+zb-JnGqZWkAj5TqHRcJ_prQSKqCPazLzF4axtsndhg@mail.gmail.com>
 <CAHEEp7XjQMAGJEmRoWruei=xxTFtV588iiVaGR6Kb0kdoQbWAQ@mail.gmail.com>
 <D3A32EA2.4880E%cnauroth@hortonworks.com> <CABYbY7fY7d=pBqTjGOMvdJWd7LKugE0MNgEk5QpuunFKyNXBSw@mail.gmail.com>
 <3F9528F4-9976-4860-9F69-C0FD57C10969@gmail.com>
From: Chris Riccomini <criccomini@apache.org>
Date: Fri, 8 Jul 2016 13:14:47 -0700
Message-ID: <CABYbY7eqUpw7obuVtEGHD_L_TCPVXLM6R_ZoapXFXF4pMpP0OQ@mail.gmail.com>
Subject: Re: Aiming for an Apache release 1st week of September?
To: dev@airflow.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a1146f1144f708405372574ae
archived-at: Fri, 08 Jul 2016 20:14:57 -0000

--001a1146f1144f708405372574ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey Bolke,

A fast release with the 1.7.1.3 + cherry picks listed above sounds like the
way to go. Then, a second release in sept where we just cut from master.

I'm +1 on this. Lets us get our Apache ducks in a row without worrying
about stabilizing everything simultaneously.

Cheers,
Chris

On Fri, Jul 8, 2016 at 12:32 AM, Bolke de Bruin <bdbruin@gmail.com> wrote:

> This was my assessment as well, thus I agree. My suggestion is to start
> the process and see if we get questions about this that require us the
> change our point of view.
>
> If we do an earlier release I would like to aim for July 19, but that
> might be a bit short notice. If needed I can put myself up as release
> manager till the 21st. If we do 1.7.1.3 + cherry picks I would say
>
> * Licenses
> * Notices
> * Disclaimer
> * Highcharts -> d3
>
> Makes sense? Anything missing here?
>
> - Bolke
>
> > Op 7 jul. 2016, om 18:04 heeft Chris Riccomini <criccomini@apache.org>
> het volgende geschreven:
> >
> >> but it's acceptable to have a soft dependency on an LGPL component, su=
ch
> > 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 a=
n
> > airflow[postgres] package (so `pip install airflow` doesn't even instal=
l
> > it). We went through a very similar exercise with Samza, where we had a
> > dependency on Paramiko (also LGPL [1]), and our (LinkedIn) lawyers talk=
ed
> > 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.co=
m
> >
> > 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 f=
ew
> >> false starts that get voted down, because the policies are complex the
> >> first time around.  Some projects have found it helpful to write a "Ho=
w
> to
> >> Release" web page during the first release, so that they have
> step-by-step
> >> notes to follow during subsequent releases.  Focusing on "latest stabl=
e"
> >> 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 L=
ZO
> >> or include any code that is tightly coupled to it, but the Hadoop
> codebase
> >> does have a notion of a pluggable CompressionCodec, with implementatio=
ns
> >> 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 ou=
r
> >>> 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.or=
g
> >
> >>> wrote:
> >>>
> >>>> One other thing to note is that I'm planning to run the RCs in all o=
f
> >>>> 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 fran=
k.
> >>>> 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 complia=
nt
> >>>> 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=C2=B9t think there are any show stoppers to have an Apach=
e
> >>>> 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 schedu=
le
> >>>> 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=C2=B9t th=
ink
> >>>> there
> >>>> is
> >>>>>> an issue as we are not redistributing psycopg2 ourselves and we ar=
e
> >>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

--001a1146f1144f708405372574ae--