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 Fri, 08 Jul 2016 20:14:47 GMT
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, 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