airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siddharth anand <san...@apache.org>
Subject Re: Aiming for an Apache release 1st week of September?
Date Thu, 14 Jul 2016 23:44:12 GMT
+1

On Thu, Jul 14, 2016 at 4:42 PM, Chris Riccomini <criccomini@apache.org>
wrote:

> (might want to have a look at
> http://incubator.apache.org/guides/releasemanagement.html as well)
>
> On Thu, Jul 14, 2016 at 4:41 PM, Chris Riccomini <criccomini@apache.org>
> wrote:
> > @bolke, is the release ready for an RC? If so, I can ship to our
> > environments and vote accordingly.
> >
> > On Mon, Jul 11, 2016 at 3:28 PM, Chris Riccomini <criccomini@apache.org>
> wrote:
> >>> If we need to update this branch I prefer very much to have commits
> that
> >>> are also applied against master.
> >>
> >> Absolutely +1 to this. Everything must go through master first.
> >>
> >> On Mon, Jul 11, 2016 at 7:06 AM, Bolke de Bruin <bdbruin@gmail.com>
> wrote:
> >>>
> >>> Ok. I created a “branch-1.7.2-apache” branch based on airbnb_rb1.7.1_4
> to
> >>> which I added cherry-picked commits to establish Apache compliancy (I
> >>> think!). If we need to update this branch I prefer very much to have
> commits
> >>> that are also applied against master.
> >>>
> >>> - Bolke
> >>>
> >>>
> >>> > Op 11 jul. 2016, om 15:16 heeft Bolke de Bruin <bdbruin@gmail.com>
> het
> >>> > volgende geschreven:
> >>> >
> >>> > Ok. I am seeing a “airbnb_rb1.7.1_4” branch, I am assuming this
is
> the
> >>> > branch to start from (?).
> >>> >
> >>> > I will work on applying the commits that are required to become
> >>> > compliant.
> >>> >
> >>> > - Bolke
> >>> >
> >>> >
> >>> >> Op 11 jul. 2016, om 05:22 heeft Maxime Beauchemin
> >>> >> <maximebeauchemin@gmail.com> het volgende geschreven:
> >>> >>
> >>> >> +1
> >>> >>
> >>> >> On Fri, Jul 8, 2016 at 5:16 PM, Dan Davydov
> >>> >> <dan.davydov@airbnb.com.invalid>
> >>> >> wrote:
> >>> >>
> >>> >>> +1 the minimal apache cherrypick release makes sense to me.
> >>> >>>
> >>> >>> On Fri, Jul 8, 2016 at 1:14 PM, Chris Riccomini
> >>> >>> <criccomini@apache.org>
> >>> >>> wrote:
> >>> >>>
> >>> >>>> 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