Re: github reviews weirdness

[Romain Manni-Bucau]

Seems you are right Charles, not sure why it happens but found another
place with the exact same content but with writable inputs. Thanks a lot!


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-28 8:45 GMT+01:00 Charles Chen :

> I noticed that GitHub sometimes has two "copies" of a comment thread--the
> first copy, the one that appears first on the page with the original
> commenter, is the only one that allows comments; a second "copy" is created
> when people do reviews.  So maybe you can scroll up to find the right
> "copy" of the thread to comment on.
>
>
> On Tue, Feb 27, 2018, 11:34 PM Romain Manni-Bucau 
> wrote:
>
>> Hey guys,
>>
>> Noticed on some PR it is not possible to comment anymore the reviews
>> comments. This is quite bothering cause it makes the review comments split
>> and at the end quite hard to follow when you get > 1 iteration.
>>
>> Anything important I miss here? Should I use another tool - if so, why
>> not github which is mainstream? Is it a "test" thing?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>

Re: github reviews weirdness

[Charles Chen]

I noticed that GitHub sometimes has two "copies" of a comment thread--the
first copy, the one that appears first on the page with the original
commenter, is the only one that allows comments; a second "copy" is created
when people do reviews.  So maybe you can scroll up to find the right
"copy" of the thread to comment on.

On Tue, Feb 27, 2018, 11:34 PM Romain Manni-Bucau 
wrote:

> Hey guys,
>
> Noticed on some PR it is not possible to comment anymore the reviews
> comments. This is quite bothering cause it makes the review comments split
> and at the end quite hard to follow when you get > 1 iteration.
>
> Anything important I miss here? Should I use another tool - if so, why not
> github which is mainstream? Is it a "test" thing?
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>

github reviews weirdness

[Romain Manni-Bucau]

Hey guys,

Noticed on some PR it is not possible to comment anymore the reviews
comments. This is quite bothering cause it makes the review comments split
and at the end quite hard to follow when you get > 1 iteration.

Anything important I miss here? Should I use another tool - if so, why not
github which is mainstream? Is it a "test" thing?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

By the way, if third party projects based on Beam (Google Dataflow, Talend
DataStream, and others) need a release (including some features), it's better to
 clearly state this on the mailing list.

At Apache Karaf, I have lot of projects based on it (OpenDaylight, OpenHAB,
Websphere,  ...). They just ask for the release schedule and they align with
these release. As a best effort, I'm always trying to move fast when a release
is asked.

So, if 2.4.0 is required by third party, no problem to "ask for a release".

Regards
JB

On 02/28/2018 04:17 AM, Reuven Lax wrote:
> It's been six weeks since you proposed beam 2.3.0. so assuming the same time
> scale for this release, that's 1.5 months between releases. Slightly faster 
> than
> 2 months, but not by much.
> 
> I do seem to remember that the original goal for beam was monthly releases 
> though.
> 
> Reuven
> 
> On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Reuven,
> 
> In a previous thread (about Beam project execution), I proposed a release 
> every
> two months (as a best effort), I will find the e-mail.
> 
> Beam 2.3.0 has been released "officially" on February 16th, so two week 
> ago
> roughly. I would have expected 2.4.0 not before end of March.
> 
> If we have issue we want to fix fast, then 2.3.1 is good. If it's a new 
> release
> in the pace, it's pretty fast and might "confuse" our users.
> 
> That's why I'm curious ;)
> 
> Regards
> JB
> 
> On 02/28/2018 03:50 AM, Reuven Lax wrote:
> > Wasn't the original statement monthly releases? We've never 
> realistically
> > managed that, but Robert's proposed cut will be on a 6-week pace.
> >
> > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré  
> > >> wrote:
> >
> >     Hi Robert,
> >
> >     I'm just curious: it's pretty fast compared to the original plan of 
> a
> release
> >     every two months. What's the reason to cut 2.4.0 now instead of end 
> of
> March ?
> >
> >     I will do the Jira triage and update today.
> >
> >     Regards
> >     JB
> >
> >     On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> >     > I'm planning on cutting the 2.4.0 release branch soon 
> (tomorrow?). I
> see 13
> >     > open issues on JIRA [1], none of which are labeled as blockers. 
> If there
> >     > are any that cannot be bumped to the next release, let me know 
> soon.
> >     >
> >     > - Robert
> >     >
> >     >
> >     > [1]
> >     >
> >   
>  
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> >     >
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

A month is OK for me: I prefer that than longer (as it was before).

The most important is a regular pace: we should avoid a 2.4.0 now and a 2.5.0
four months later. So, it means that 2.5.0 should happen roughly end of April.

I will send a clear statement (as I already did weeks ago) around releases pace
and schedule.

I'm volunteer to drive the releases.

Regards
JB

On 02/28/2018 06:43 AM, Kenneth Knowles wrote:
> To be semver, 2.3.1 should be rollback safe with 2.3.0. Normally that is
> accomplished by cutting 2.3.1 release branch from 2.3.0 release branch and 
> then
> have fixes cherrypicked.
> 
> I think 6 weeks between minor version releases is not too fast. I think a 
> month
> is a good target.
> 
> We tend to have high latency between cut and release, so we should plan on 
> that.
> 
> Kenn
> 
> On Tue, Feb 27, 2018 at 9:16 PM, Jean-Baptiste Onofré  > wrote:
> 
> That's the point of my e-mail indeed. I think it would make more sense for
> users.
> 
> Regards
> JB
> 
> On 02/28/2018 06:04 AM, Romain Manni-Bucau wrote:
> > Thinking out loud: why not trying a 2.3.1 with small fixes only and the 
> 2.4
> > after 6 weeks starting from the 2.3.0 real release date.
> >
> > Le 28 févr. 2018 04:24, "Jean-Baptiste Onofré"  
> > >> a écrit :
> >
> >     OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a 
> release is out,
> >     not when it started.
> >
> >     I don't remember about monthly release (it's too fast IMHO).
> >
> >     Anyway, let me find the thread dealing with release pace and 
> propose a clear
> >     statement. It's important for our users.
> >
> >     Regards
> >     JB
> >
> >     On 02/28/2018 04:17 AM, Reuven Lax wrote:
> >     > It's been six weeks since you proposed beam 2.3.0. so assuming 
> the same time
> >     > scale for this release, that's 1.5 months between releases. 
> Slightly
> >     faster than
> >     > 2 months, but not by much.
> >     >
> >     > I do seem to remember that the original goal for beam was monthly 
> releases
> >     though.
> >     >
> >     > Reuven
> >     >
> >     > On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré 
> 
> >     >
> >     > 
>  >     >
> >     >     Hi Reuven,
> >     >
> >     >     In a previous thread (about Beam project execution), I 
> proposed a
> >     release every
> >     >     two months (as a best effort), I will find the e-mail.
> >     >
> >     >     Beam 2.3.0 has been released "officially" on February 16th, 
> so two
> >     week ago
> >     >     roughly. I would have expected 2.4.0 not before end of March.
> >     >
> >     >     If we have issue we want to fix fast, then 2.3.1 is good. If 
> it's a
> >     new release
> >     >     in the pace, it's pretty fast and might "confuse" our users.
> >     >
> >     >     That's why I'm curious ;)
> >     >
> >     >     Regards
> >     >     JB
> >     >
> >     >     On 02/28/2018 03:50 AM, Reuven Lax wrote:
> >     >     > Wasn't the original statement monthly releases? We've never
> >     realistically
> >     >     > managed that, but Robert's proposed cut will be on a 6-week 
> pace.
> >     >     >
> >     >     > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré
> 
> >     >
> >     >     
> >>
> >     >     > 
> >
> >     
>  wrote:
> >     >     >
> >     >     >     Hi Robert,
> >     >     >
> >     >     >     I'm just curious: it's pretty fast compared to the
> original plan
> >     of a
> >     >     release
> >     >     >     every two months. What's the reason to cut 2.4.0 now
> instead of
> >     end of
> >     >     March ?
> >     >     >
> >     >     >     I will do the Jira triage and update today.
> >     >     >
> >     >     >     Regards
> >     >     >     JB
> >     >     >
> >     >     >     On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> >     >     >     > I'm planning on cutting the 2.4.0 release branch soon
>  

Re: Beam 2.4.0

[Kenneth Knowles]

To be semver, 2.3.1 should be rollback safe with 2.3.0. Normally that is
accomplished by cutting 2.3.1 release branch from 2.3.0 release branch and
then have fixes cherrypicked.

I think 6 weeks between minor version releases is not too fast. I think a
month is a good target.

We tend to have high latency between cut and release, so we should plan on
that.

Kenn

On Tue, Feb 27, 2018 at 9:16 PM, Jean-Baptiste Onofré 
wrote:

> That's the point of my e-mail indeed. I think it would make more sense for
> users.
>
> Regards
> JB
>
> On 02/28/2018 06:04 AM, Romain Manni-Bucau wrote:
> > Thinking out loud: why not trying a 2.3.1 with small fixes only and the
> 2.4
> > after 6 weeks starting from the 2.3.0 real release date.
> >
> > Le 28 févr. 2018 04:24, "Jean-Baptiste Onofré"  > > a écrit :
> >
> > OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a
> release is out,
> > not when it started.
> >
> > I don't remember about monthly release (it's too fast IMHO).
> >
> > Anyway, let me find the thread dealing with release pace and propose
> a clear
> > statement. It's important for our users.
> >
> > Regards
> > JB
> >
> > On 02/28/2018 04:17 AM, Reuven Lax wrote:
> > > It's been six weeks since you proposed beam 2.3.0. so assuming the
> same time
> > > scale for this release, that's 1.5 months between releases.
> Slightly
> > faster than
> > > 2 months, but not by much.
> > >
> > > I do seem to remember that the original goal for beam was monthly
> releases
> > though.
> > >
> > > Reuven
> > >
> > > On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> > 
> > > >> wrote:
> > >
> > > Hi Reuven,
> > >
> > > In a previous thread (about Beam project execution), I
> proposed a
> > release every
> > > two months (as a best effort), I will find the e-mail.
> > >
> > > Beam 2.3.0 has been released "officially" on February 16th, so
> two
> > week ago
> > > roughly. I would have expected 2.4.0 not before end of March.
> > >
> > > If we have issue we want to fix fast, then 2.3.1 is good. If
> it's a
> > new release
> > > in the pace, it's pretty fast and might "confuse" our users.
> > >
> > > That's why I'm curious ;)
> > >
> > > Regards
> > > JB
> > >
> > > On 02/28/2018 03:50 AM, Reuven Lax wrote:
> > > > Wasn't the original statement monthly releases? We've never
> > realistically
> > > > managed that, but Robert's proposed cut will be on a 6-week
> pace.
> > > >
> > > > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> > 
> > > >
> > > > 
> >  > > >
> > > > Hi Robert,
> > > >
> > > > I'm just curious: it's pretty fast compared to the
> original plan
> > of a
> > > release
> > > > every two months. What's the reason to cut 2.4.0 now
> instead of
> > end of
> > > March ?
> > > >
> > > > I will do the Jira triage and update today.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> > > > > I'm planning on cutting the 2.4.0 release branch soon
> > (tomorrow?). I
> > > see 13
> > > > > open issues on JIRA [1], none of which are labeled as
> > blockers. If there
> > > > > are any that cannot be bumped to the next release, let
> me know
> > soon.
> > > > >
> > > > > - Robert
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >   https://issues.apache.org/jira/browse/BEAM-3749?jql=
> project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%
> 22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> >  project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%
> 22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0>
> > > > >
> > > >
> > > > --
> > > > Jean-Baptiste Onofré
> > > > jbono...@apache.org 
> > >
> > > 
> > >>
> > > > http://blog.nanthrax.net
> > > > Talend 

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

That's the point of my e-mail indeed. I think it would make more sense for 
users.

Regards
JB

On 02/28/2018 06:04 AM, Romain Manni-Bucau wrote:
> Thinking out loud: why not trying a 2.3.1 with small fixes only and the 2.4
> after 6 weeks starting from the 2.3.0 real release date.
> 
> Le 28 févr. 2018 04:24, "Jean-Baptiste Onofré"  > a écrit :
> 
> OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a release is 
> out,
> not when it started.
> 
> I don't remember about monthly release (it's too fast IMHO).
> 
> Anyway, let me find the thread dealing with release pace and propose a 
> clear
> statement. It's important for our users.
> 
> Regards
> JB
> 
> On 02/28/2018 04:17 AM, Reuven Lax wrote:
> > It's been six weeks since you proposed beam 2.3.0. so assuming the same 
> time
> > scale for this release, that's 1.5 months between releases. Slightly
> faster than
> > 2 months, but not by much.
> >
> > I do seem to remember that the original goal for beam was monthly 
> releases
> though.
> >
> > Reuven
> >
> > On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré  
> > >> wrote:
> >
> >     Hi Reuven,
> >
> >     In a previous thread (about Beam project execution), I proposed a
> release every
> >     two months (as a best effort), I will find the e-mail.
> >
> >     Beam 2.3.0 has been released "officially" on February 16th, so two
> week ago
> >     roughly. I would have expected 2.4.0 not before end of March.
> >
> >     If we have issue we want to fix fast, then 2.3.1 is good. If it's a
> new release
> >     in the pace, it's pretty fast and might "confuse" our users.
> >
> >     That's why I'm curious ;)
> >
> >     Regards
> >     JB
> >
> >     On 02/28/2018 03:50 AM, Reuven Lax wrote:
> >     > Wasn't the original statement monthly releases? We've never
> realistically
> >     > managed that, but Robert's proposed cut will be on a 6-week pace.
> >     >
> >     > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré 
>  
> >     >
> >     > 
>  >     >
> >     >     Hi Robert,
> >     >
> >     >     I'm just curious: it's pretty fast compared to the original 
> plan
> of a
> >     release
> >     >     every two months. What's the reason to cut 2.4.0 now instead 
> of
> end of
> >     March ?
> >     >
> >     >     I will do the Jira triage and update today.
> >     >
> >     >     Regards
> >     >     JB
> >     >
> >     >     On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> >     >     > I'm planning on cutting the 2.4.0 release branch soon
> (tomorrow?). I
> >     see 13
> >     >     > open issues on JIRA [1], none of which are labeled as
> blockers. If there
> >     >     > are any that cannot be bumped to the next release, let me 
> know
> soon.
> >     >     >
> >     >     > - Robert
> >     >     >
> >     >     >
> >     >     > [1]
> >     >     >
> >     >   
> >   
>   
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> 
> 
> >     >     >
> >     >
> >     >     --
> >     >     Jean-Baptiste Onofré
> >     >     jbono...@apache.org 
> >
> >     
> >>
> >     >     http://blog.nanthrax.net
> >     >     Talend - http://www.talend.com
> >     >
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Beam 2.4.0

[Romain Manni-Bucau]

Thinking out loud: why not trying a 2.3.1 with small fixes only and the 2.4
after 6 weeks starting from the 2.3.0 real release date.

Le 28 févr. 2018 04:24, "Jean-Baptiste Onofré"  a écrit :

> OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a release is
> out,
> not when it started.
>
> I don't remember about monthly release (it's too fast IMHO).
>
> Anyway, let me find the thread dealing with release pace and propose a
> clear
> statement. It's important for our users.
>
> Regards
> JB
>
> On 02/28/2018 04:17 AM, Reuven Lax wrote:
> > It's been six weeks since you proposed beam 2.3.0. so assuming the same
> time
> > scale for this release, that's 1.5 months between releases. Slightly
> faster than
> > 2 months, but not by much.
> >
> > I do seem to remember that the original goal for beam was monthly
> releases though.
> >
> > Reuven
> >
> > On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Reuven,
> >
> > In a previous thread (about Beam project execution), I proposed a
> release every
> > two months (as a best effort), I will find the e-mail.
> >
> > Beam 2.3.0 has been released "officially" on February 16th, so two
> week ago
> > roughly. I would have expected 2.4.0 not before end of March.
> >
> > If we have issue we want to fix fast, then 2.3.1 is good. If it's a
> new release
> > in the pace, it's pretty fast and might "confuse" our users.
> >
> > That's why I'm curious ;)
> >
> > Regards
> > JB
> >
> > On 02/28/2018 03:50 AM, Reuven Lax wrote:
> > > Wasn't the original statement monthly releases? We've never
> realistically
> > > managed that, but Robert's proposed cut will be on a 6-week pace.
> > >
> > > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> > 
> > > >> wrote:
> > >
> > > Hi Robert,
> > >
> > > I'm just curious: it's pretty fast compared to the original
> plan of a
> > release
> > > every two months. What's the reason to cut 2.4.0 now instead
> of end of
> > March ?
> > >
> > > I will do the Jira triage and update today.
> > >
> > > Regards
> > > JB
> > >
> > > On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> > > > I'm planning on cutting the 2.4.0 release branch soon
> (tomorrow?). I
> > see 13
> > > > open issues on JIRA [1], none of which are labeled as
> blockers. If there
> > > > are any that cannot be bumped to the next release, let me
> know soon.
> > > >
> > > > - Robert
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >  https://issues.apache.org/jira/browse/BEAM-3749?jql=
> project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%
> 22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org 
> > >
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a release is out,
not when it started.

I don't remember about monthly release (it's too fast IMHO).

Anyway, let me find the thread dealing with release pace and propose a clear
statement. It's important for our users.

Regards
JB

On 02/28/2018 04:17 AM, Reuven Lax wrote:
> It's been six weeks since you proposed beam 2.3.0. so assuming the same time
> scale for this release, that's 1.5 months between releases. Slightly faster 
> than
> 2 months, but not by much.
> 
> I do seem to remember that the original goal for beam was monthly releases 
> though.
> 
> Reuven
> 
> On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Reuven,
> 
> In a previous thread (about Beam project execution), I proposed a release 
> every
> two months (as a best effort), I will find the e-mail.
> 
> Beam 2.3.0 has been released "officially" on February 16th, so two week 
> ago
> roughly. I would have expected 2.4.0 not before end of March.
> 
> If we have issue we want to fix fast, then 2.3.1 is good. If it's a new 
> release
> in the pace, it's pretty fast and might "confuse" our users.
> 
> That's why I'm curious ;)
> 
> Regards
> JB
> 
> On 02/28/2018 03:50 AM, Reuven Lax wrote:
> > Wasn't the original statement monthly releases? We've never 
> realistically
> > managed that, but Robert's proposed cut will be on a 6-week pace.
> >
> > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré  
> > >> wrote:
> >
> >     Hi Robert,
> >
> >     I'm just curious: it's pretty fast compared to the original plan of 
> a
> release
> >     every two months. What's the reason to cut 2.4.0 now instead of end 
> of
> March ?
> >
> >     I will do the Jira triage and update today.
> >
> >     Regards
> >     JB
> >
> >     On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> >     > I'm planning on cutting the 2.4.0 release branch soon 
> (tomorrow?). I
> see 13
> >     > open issues on JIRA [1], none of which are labeled as blockers. 
> If there
> >     > are any that cannot be bumped to the next release, let me know 
> soon.
> >     >
> >     > - Robert
> >     >
> >     >
> >     > [1]
> >     >
> >   
>  
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> >     >
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Beam 2.4.0

[Reuven Lax]

It's been six weeks since you proposed beam 2.3.0. so assuming the same
time scale for this release, that's 1.5 months between releases. Slightly
faster than 2 months, but not by much.

I do seem to remember that the original goal for beam was monthly releases
though.

Reuven

On Tue, Feb 27, 2018, 9:12 PM Jean-Baptiste Onofré  wrote:

> Hi Reuven,
>
> In a previous thread (about Beam project execution), I proposed a release
> every
> two months (as a best effort), I will find the e-mail.
>
> Beam 2.3.0 has been released "officially" on February 16th, so two week ago
> roughly. I would have expected 2.4.0 not before end of March.
>
> If we have issue we want to fix fast, then 2.3.1 is good. If it's a new
> release
> in the pace, it's pretty fast and might "confuse" our users.
>
> That's why I'm curious ;)
>
> Regards
> JB
>
> On 02/28/2018 03:50 AM, Reuven Lax wrote:
> > Wasn't the original statement monthly releases? We've never realistically
> > managed that, but Robert's proposed cut will be on a 6-week pace.
> >
> > On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Robert,
> >
> > I'm just curious: it's pretty fast compared to the original plan of
> a release
> > every two months. What's the reason to cut 2.4.0 now instead of end
> of March ?
> >
> > I will do the Jira triage and update today.
> >
> > Regards
> > JB
> >
> > On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> > > I'm planning on cutting the 2.4.0 release branch soon (tomorrow?).
> I see 13
> > > open issues on JIRA [1], none of which are labeled as blockers. If
> there
> > > are any that cannot be bumped to the next release, let me know
> soon.
> > >
> > > - Robert
> > >
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

Hi Reuven,

In a previous thread (about Beam project execution), I proposed a release every
two months (as a best effort), I will find the e-mail.

Beam 2.3.0 has been released "officially" on February 16th, so two week ago
roughly. I would have expected 2.4.0 not before end of March.

If we have issue we want to fix fast, then 2.3.1 is good. If it's a new release
in the pace, it's pretty fast and might "confuse" our users.

That's why I'm curious ;)

Regards
JB

On 02/28/2018 03:50 AM, Reuven Lax wrote:
> Wasn't the original statement monthly releases? We've never realistically
> managed that, but Robert's proposed cut will be on a 6-week pace.
> 
> On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Robert,
> 
> I'm just curious: it's pretty fast compared to the original plan of a 
> release
> every two months. What's the reason to cut 2.4.0 now instead of end of 
> March ?
> 
> I will do the Jira triage and update today.
> 
> Regards
> JB
> 
> On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> > I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I 
> see 13
> > open issues on JIRA [1], none of which are labeled as blockers. If there
> > are any that cannot be bumped to the next release, let me know soon.
> >
> > - Robert
> >
> >
> > [1]
> >
> 
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> >
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Beam 2.4.0

[Reuven Lax]

Wasn't the original statement monthly releases? We've never realistically
managed that, but Robert's proposed cut will be on a 6-week pace.

On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré  wrote:

> Hi Robert,
>
> I'm just curious: it's pretty fast compared to the original plan of a
> release
> every two months. What's the reason to cut 2.4.0 now instead of end of
> March ?
>
> I will do the Jira triage and update today.
>
> Regards
> JB
>
> On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> > I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see
> 13
> > open issues on JIRA [1], none of which are labeled as blockers. If there
> > are any that cannot be bumped to the next release, let me know soon.
> >
> > - Robert
> >
> >
> > [1]
> >
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Beam 2.4.0

[Jean-Baptiste Onofré]

Hi Robert,

I'm just curious: it's pretty fast compared to the original plan of a release
every two months. What's the reason to cut 2.4.0 now instead of end of March ?

I will do the Jira triage and update today.

Regards
JB

On 02/27/2018 09:21 PM, Robert Bradshaw wrote:
> I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see 13
> open issues on JIRA [1], none of which are labeled as blockers. If there
> are any that cannot be bumped to the next release, let me know soon.
> 
> - Robert
> 
> 
> [1]
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Python 3 flake 8: splitting up on the errors?

[Holden Karau]

How would folks feel about splitting up some of the Python 3 migration work
by the different flake8 errors in Py3? This might allow us to parallelize
some of the work while still keeping things fairly small?

-- 
Twitter: https://twitter.com/holdenkarau

Re: Beam 2.4.0

[Reuven Lax]

The issue isn't that we miss teardown, it's that WaitUntilFinish doesn't
wait until all teardown calls have finished. However this is nearly as bad
as not calling teardown at all, and can result in flaky tests.

I think we should make an effort to get this fix into 2.4.0, but I also
don't think we should block 2.4.0 on it. The reason being is that this is a
long-standing issue (it's been a bug since Teardown was introduced) and
it's not a production data-correctness issue; in the past we've stated that
we will not block releases for bugs like this, however we will make an
attempt to include the bugfixes if possible.

Reuven


On Tue, Feb 27, 2018 at 1:42 PM Romain Manni-Bucau 
wrote:

> Not sure when it appeared but running any test you miss the teardown which
> is:
>
> 1. A part you cant test today cause of that
> 2. Leaking and can impact other tests depending the impl and setup
> 3. Prevent any correct concurrency plannification of tests (even using the
> random of the direct runner you can plan it but not with teardown leaks
> leading to numerous unexpected threads)
>
> Can work for simple cases like the IO in beam but this week (since
> yesterday ;)) already 2 users reported me broken executions due to that and
> I was only able to say the PR was ready since weeks :(. Since code fix is
> here I think it should make it as a minimum to make the directrunner usable
> for tests. Cleanup of the code - dont think there is any - can come later
> if needed but normally all was addressed anyway and doesnt impact code
> quality.
>
> Le 27 févr. 2018 22:34, "Reuven Lax"  a écrit :
>
>> Can you explain "unusable?" We have hundreds of direct-runner tests that
>> appear to still be running just fine. Is this a new regression, or old
>> behavior?
>>
>>
>> On Tue, Feb 27, 2018 at 1:30 PM Romain Manni-Bucau 
>> wrote:
>>
>>> Updated 3409 as blocker since it makes direct runner - and therefore any
>>> test - unusable at all (leaks+unexpected wait times + retry strategy
>>> required+no real alternative even for dofn now dofntester is deprecated).
>>>
>>> Le 27 févr. 2018 21:45, "Chamikara Jayalath"  a
>>> écrit :
>>>
 Looks like previous URL was broken. Created
 https://s.apache.org/beam-2.4.0-burndown.

 - Cham

 On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
 wrote:

> I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I
> see 13
> open issues on JIRA [1], none of which are labeled as blockers. If
> there
> are any that cannot be bumped to the next release, let me know soon.
>
> - Robert
>
>
> [1]
>
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
>

Re: Beam 2.4.0

[Romain Manni-Bucau]

Not sure when it appeared but running any test you miss the teardown which
is:

1. A part you cant test today cause of that
2. Leaking and can impact other tests depending the impl and setup
3. Prevent any correct concurrency plannification of tests (even using the
random of the direct runner you can plan it but not with teardown leaks
leading to numerous unexpected threads)

Can work for simple cases like the IO in beam but this week (since
yesterday ;)) already 2 users reported me broken executions due to that and
I was only able to say the PR was ready since weeks :(. Since code fix is
here I think it should make it as a minimum to make the directrunner usable
for tests. Cleanup of the code - dont think there is any - can come later
if needed but normally all was addressed anyway and doesnt impact code
quality.

Le 27 févr. 2018 22:34, "Reuven Lax"  a écrit :

> Can you explain "unusable?" We have hundreds of direct-runner tests that
> appear to still be running just fine. Is this a new regression, or old
> behavior?
>
>
> On Tue, Feb 27, 2018 at 1:30 PM Romain Manni-Bucau 
> wrote:
>
>> Updated 3409 as blocker since it makes direct runner - and therefore any
>> test - unusable at all (leaks+unexpected wait times + retry strategy
>> required+no real alternative even for dofn now dofntester is deprecated).
>>
>> Le 27 févr. 2018 21:45, "Chamikara Jayalath"  a
>> écrit :
>>
>>> Looks like previous URL was broken. Created https://s.apache.org/
>>> beam-2.4.0-burndown.
>>>
>>> - Cham
>>>
>>> On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
>>> wrote:
>>>
 I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I
 see 13
 open issues on JIRA [1], none of which are labeled as blockers. If there
 are any that cannot be bumped to the next release, let me know soon.

 - Robert


 [1]
 https://issues.apache.org/jira/browse/BEAM-3749?jql=
 project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%
 22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0

>>>

Re: Beam 2.4.0

[Reuven Lax]

Ok, I see. This bug is specifically about Teardown behavior.


On Tue, Feb 27, 2018 at 1:33 PM Reuven Lax  wrote:

> Can you explain "unusable?" We have hundreds of direct-runner tests that
> appear to still be running just fine. Is this a new regression, or old
> behavior?
>
>
> On Tue, Feb 27, 2018 at 1:30 PM Romain Manni-Bucau 
> wrote:
>
>> Updated 3409 as blocker since it makes direct runner - and therefore any
>> test - unusable at all (leaks+unexpected wait times + retry strategy
>> required+no real alternative even for dofn now dofntester is deprecated).
>>
>> Le 27 févr. 2018 21:45, "Chamikara Jayalath"  a
>> écrit :
>>
>>> Looks like previous URL was broken. Created
>>> https://s.apache.org/beam-2.4.0-burndown.
>>>
>>> - Cham
>>>
>>> On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
>>> wrote:
>>>
 I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I
 see 13
 open issues on JIRA [1], none of which are labeled as blockers. If there
 are any that cannot be bumped to the next release, let me know soon.

 - Robert


 [1]

 https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0

>>>

Re: Beam 2.4.0

[Reuven Lax]

Can you explain "unusable?" We have hundreds of direct-runner tests that
appear to still be running just fine. Is this a new regression, or old
behavior?


On Tue, Feb 27, 2018 at 1:30 PM Romain Manni-Bucau 
wrote:

> Updated 3409 as blocker since it makes direct runner - and therefore any
> test - unusable at all (leaks+unexpected wait times + retry strategy
> required+no real alternative even for dofn now dofntester is deprecated).
>
> Le 27 févr. 2018 21:45, "Chamikara Jayalath"  a
> écrit :
>
>> Looks like previous URL was broken. Created
>> https://s.apache.org/beam-2.4.0-burndown.
>>
>> - Cham
>>
>> On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
>> wrote:
>>
>>> I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see
>>> 13
>>> open issues on JIRA [1], none of which are labeled as blockers. If there
>>> are any that cannot be bumped to the next release, let me know soon.
>>>
>>> - Robert
>>>
>>>
>>> [1]
>>>
>>> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
>>>
>>

Re: Beam 2.4.0

[Romain Manni-Bucau]

Updated 3409 as blocker since it makes direct runner - and therefore any
test - unusable at all (leaks+unexpected wait times + retry strategy
required+no real alternative even for dofn now dofntester is deprecated).

Le 27 févr. 2018 21:45, "Chamikara Jayalath"  a
écrit :

> Looks like previous URL was broken. Created https://s.apache.org/
> beam-2.4.0-burndown.
>
> - Cham
>
> On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
> wrote:
>
>> I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see
>> 13
>> open issues on JIRA [1], none of which are labeled as blockers. If there
>> are any that cannot be bumped to the next release, let me know soon.
>>
>> - Robert
>>
>>
>> [1]
>> https://issues.apache.org/jira/browse/BEAM-3749?jql=
>> project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%
>> 22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
>>
>

Re: Beam 2.4.0

[Chamikara Jayalath]

Looks like previous URL was broken. Created
https://s.apache.org/beam-2.4.0-burndown.

- Cham

On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw 
wrote:

> I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see 13
> open issues on JIRA [1], none of which are labeled as blockers. If there
> are any that cannot be bumped to the next release, let me know soon.
>
> - Robert
>
>
> [1]
>
> https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0
>

Beam 2.4.0

[Robert Bradshaw]

I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see 13
open issues on JIRA [1], none of which are labeled as blockers. If there
are any that cannot be bumped to the next release, let me know soon.

- Robert


[1]
https://issues.apache.org/jira/browse/BEAM-3749?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.4.0

Re: Euphoria Java 8 DSL - proposal

[Davor Bonaci]

(Sounds good, thanks! We'll follow-up there.)

On Tue, Feb 27, 2018 at 10:49 AM, David Morávek 
wrote:

> Hi Davor,
>
> sorry for the delay, we were blocked by our legal department. I've send
> both SGA and CCLA to priv...@apache.beam.org, please let me know if you
> need anything else.
>
> Regards,
> David
>
> On Mon, Feb 19, 2018 at 6:13 AM, Jean-Baptiste Onofré 
> wrote:
>
>> Hi Davor,
>>
>> We still have some discussion/paperwork on Euphoria side (SGA, ...).
>>
>> So, it's on track but it takes a little more time than expected.
>>
>> Regards
>> JB
>>
>> On 02/19/2018 05:40 AM, Davor Bonaci wrote:
>> > I may have missed things, but any update on the progress of this
>> donation?
>> >
>> > On Tue, Jan 2, 2018 at 10:52 PM, Jean-Baptiste Onofré > > > wrote:
>> >
>> > Great !
>> >
>> > Thanks !
>> > Regards
>> > JB
>> >
>> > On 01/03/2018 07:29 AM, David Morávek wrote:
>> >
>> > Hello JB,
>> >
>> > Perfect! I'm already on the Beam Slack workspace, I'll contact
>> you once
>> > I get to the office.
>> >
>> > Thanks!
>> > D.
>> >
>> > On Wed, Jan 3, 2018 at 6:19 AM, Jean-Baptiste Onofré <
>> j...@nanthrax.net
>> >  > > >> wrote:
>> >
>> > Hi David,
>> >
>> > absolutely !! Let's move forward on the preparation steps.
>> >
>> > Are you on Slack and/or hangout to plan this ?
>> >
>> > Thanks,
>> > Regards
>> > JB
>> >
>> > On 01/02/2018 05:35 PM, David Morávek wrote:
>> >
>> > Hello JB,
>> >
>> > can we help in any way to move things forward?
>> >
>> > Thanks,
>> > D.
>> >
>> > On Mon, Dec 18, 2017 at 4:28 PM, Jean-Baptiste Onofré
>> > 
>> > >
>> > 
>> > > wrote:
>> >
>> >  Thanks Jan,
>> >
>> >  It makes sense.
>> >
>> >  Let me take a look on the code to understand the
>> "interaction".
>> >
>> >  Regards
>> >  JB
>> >
>> >
>> >  On 12/18/2017 04:26 PM, Jan Lukavský wrote:
>> >
>> >  Hi JB,
>> >
>> >  basically you are not wrong. The project
>> started about
>> > three or
>> > four
>> >  years ago with a goal to unify batch and
>> streaming
>> > processing into
>> >  single portable, executor independent API.
>> Because of
>> > that, it is
>> >  currently "close" to Beam in this sense. But
>> we don't
>> > see much
>> > added
>> >  value keeping this as a separate project, with
>> one of
>> > the key
>> >  differences to be the API (not the model
>> itself), so we
>> > would
>> > like to
>> >  focus on translation from Euphoria API to
>> Beam's SDK.
>> > That's why we
>> >  would like to see it as a DSL, so that it
>> would be
>> > possible to use
>> >  Euphoria API with Beam's runners as much
>> natively as
>> > possible.
>> >
>> >  I hope I didn't make the subject even more
>> unclear, if
>> > so, I'll
>> > be happy
>> >  to explain anything in more detail. :-)
>> >
>> >  Jan
>> >
>> >
>> >  On 12/18/2017 04:08 PM, Jean-Baptiste Onofré
>> wrote:
>> >
>> >  Hi Jan,
>> >
>> >  Thanks for your answers.
>> >
>> >  However, they confused me ;)
>> >
>> >  Regarding what you replied, Euphoria seems
>> like a
>> > programming
>> >  model/SDK "close" to Beam more than a DSL
>> on top of an
>> > existing Beam
>> >  SDK.
>> >
>> >  Am I wrong ?
>> >
>> >  Regards
>> >  JB
>> >
>> >  On 12/18/2017 03:44 PM, Jan Lukavský wrote:
>> >
>> >  Hi Ismael,
>> >
>> >  basically we adopted the Beam's design
>> regarding
>> > partitioning
>> >  

Re: Euphoria Java 8 DSL - proposal

[David Morávek]

Hi Davor,

sorry for the delay, we were blocked by our legal department. I've send
both SGA and CCLA to priv...@apache.beam.org, please let me know if you
need anything else.

Regards,
David

On Mon, Feb 19, 2018 at 6:13 AM, Jean-Baptiste Onofré 
wrote:

> Hi Davor,
>
> We still have some discussion/paperwork on Euphoria side (SGA, ...).
>
> So, it's on track but it takes a little more time than expected.
>
> Regards
> JB
>
> On 02/19/2018 05:40 AM, Davor Bonaci wrote:
> > I may have missed things, but any update on the progress of this
> donation?
> >
> > On Tue, Jan 2, 2018 at 10:52 PM, Jean-Baptiste Onofré  > > wrote:
> >
> > Great !
> >
> > Thanks !
> > Regards
> > JB
> >
> > On 01/03/2018 07:29 AM, David Morávek wrote:
> >
> > Hello JB,
> >
> > Perfect! I'm already on the Beam Slack workspace, I'll contact
> you once
> > I get to the office.
> >
> > Thanks!
> > D.
> >
> > On Wed, Jan 3, 2018 at 6:19 AM, Jean-Baptiste Onofré <
> j...@nanthrax.net
> >   > >> wrote:
> >
> > Hi David,
> >
> > absolutely !! Let's move forward on the preparation steps.
> >
> > Are you on Slack and/or hangout to plan this ?
> >
> > Thanks,
> > Regards
> > JB
> >
> > On 01/02/2018 05:35 PM, David Morávek wrote:
> >
> > Hello JB,
> >
> > can we help in any way to move things forward?
> >
> > Thanks,
> > D.
> >
> > On Mon, Dec 18, 2017 at 4:28 PM, Jean-Baptiste Onofré
> > 
> > >
> > 
> >  wrote:
> >
> >  Thanks Jan,
> >
> >  It makes sense.
> >
> >  Let me take a look on the code to understand the
> "interaction".
> >
> >  Regards
> >  JB
> >
> >
> >  On 12/18/2017 04:26 PM, Jan Lukavský wrote:
> >
> >  Hi JB,
> >
> >  basically you are not wrong. The project
> started about
> > three or
> > four
> >  years ago with a goal to unify batch and
> streaming
> > processing into
> >  single portable, executor independent API.
> Because of
> > that, it is
> >  currently "close" to Beam in this sense. But we
> don't
> > see much
> > added
> >  value keeping this as a separate project, with
> one of
> > the key
> >  differences to be the API (not the model
> itself), so we
> > would
> > like to
> >  focus on translation from Euphoria API to
> Beam's SDK.
> > That's why we
> >  would like to see it as a DSL, so that it would
> be
> > possible to use
> >  Euphoria API with Beam's runners as much
> natively as
> > possible.
> >
> >  I hope I didn't make the subject even more
> unclear, if
> > so, I'll
> > be happy
> >  to explain anything in more detail. :-)
> >
> >  Jan
> >
> >
> >  On 12/18/2017 04:08 PM, Jean-Baptiste Onofré
> wrote:
> >
> >  Hi Jan,
> >
> >  Thanks for your answers.
> >
> >  However, they confused me ;)
> >
> >  Regarding what you replied, Euphoria seems
> like a
> > programming
> >  model/SDK "close" to Beam more than a DSL
> on top of an
> > existing Beam
> >  SDK.
> >
> >  Am I wrong ?
> >
> >  Regards
> >  JB
> >
> >  On 12/18/2017 03:44 PM, Jan Lukavský wrote:
> >
> >  Hi Ismael,
> >
> >  basically we adopted the Beam's design
> regarding
> > partitioning
> >  (https://github.com/seznam/
> euphoria/issues/160
> > 
> >  > >
> >   euphoria/issues/160

Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

[Reuven Lax]

Thanks for fixing the manual cleanup issue! This is something we kept
punting on in previous releases.


On Mon, Feb 26, 2018 at 7:14 PM Jean-Baptiste Onofré 
wrote:

> Hi Alan,
>
> Honestly,  it was an easy and smooth release, similar to other Apache
> project
> release.
>
> Maybe the points where we could a little bit improve are:
>
> 1. The website update was pretty long as @asfgit merge didn't work (due to
> a out
> of sync on the github mirror). I think the website publish PR can be
> automatized.
> 2. Upload to pylib required manual action (like renaming the files)
>
> Thanks to the change I did on the assembly, the artifacts don't require any
> manual cleanup (whereas it was the case in previous release).
>
> Regards
> JB
>
> On 02/26/2018 10:54 PM, Alan Myrvold wrote:
> > Is there a list of pain points during the 2.3.0 release and improvements
> that
> > can be made to the 2.4.0 release process?
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Jenkins build is back to normal : beam_SeedJob #1178

[Apache Jenkins Server]

See 

Build failed in Jenkins: beam_SeedJob #1177

[Apache Jenkins Server]

See 

--
GitHub pull request #4758 of commit 4b0a07f826103899d5b7884490059b5498f064f3, 
no merge conflicts.
Setting status of 4b0a07f826103899d5b7884490059b5498f064f3 to PENDING with url 
https://builds.apache.org/job/beam_SeedJob/1177/ and message: 'Build started 
sha1 is merged.'
Using context: Jenkins: Seed Job
[EnvInject] - Loading node environment variables.
Building remotely on beam4 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/beam.git # timeout=10
Fetching upstream changes from https://github.com/apache/beam.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/beam.git 
 > +refs/heads/*:refs/remotes/origin/* 
 > +refs/pull/4758/*:refs/remotes/origin/pr/4758/*
 > git rev-parse refs/remotes/origin/pr/4758/merge^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/pr/4758/merge^{commit} # timeout=10
Checking out Revision 3b654109162fe1710de67230645886ed34d6cb44 
(refs/remotes/origin/pr/4758/merge)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3b654109162fe1710de67230645886ed34d6cb44
Commit message: "Merge 4b0a07f826103899d5b7884490059b5498f064f3 into 
a7501289a23e2d8a3a7e5a3b9f5e920702d4d634"
First time build. Skipping changelog.
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Processing DSL script job_00_seed.groovy
Processing DSL script job_beam_Java_Build.groovy
Processing DSL script job_beam_Java_CodeHealth.groovy
Processing DSL script job_beam_Java_IntegrationTest.groovy
Processing DSL script job_beam_Java_UnitTest.groovy
Processing DSL script job_beam_PerformanceTests_Dataflow.groovy
Processing DSL script job_beam_PerformanceTests_FileBasedIO_IT.groovy
Processing DSL script job_beam_PerformanceTests_HadoopInputFormat.groovy
ERROR: (job_beam_PerformanceTests_HadoopInputFormat.groovy, line 64) No such 
property: context for class: javaposse.jobdsl.dsl.jobs.FreeStyleJob

Build failed in Jenkins: beam_SeedJob #1176

[Apache Jenkins Server]

See 

--
GitHub pull request #4758 of commit bc16e32ab7046caa7d031710fa1056b226fa3b2f, 
no merge conflicts.
Setting status of bc16e32ab7046caa7d031710fa1056b226fa3b2f to PENDING with url 
https://builds.apache.org/job/beam_SeedJob/1176/ and message: 'Build started 
sha1 is merged.'
Using context: Jenkins: Seed Job
[EnvInject] - Loading node environment variables.
Building remotely on beam4 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/beam.git # timeout=10
Fetching upstream changes from https://github.com/apache/beam.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/beam.git 
 > +refs/heads/*:refs/remotes/origin/* 
 > +refs/pull/4758/*:refs/remotes/origin/pr/4758/*
 > git rev-parse refs/remotes/origin/pr/4758/merge^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/pr/4758/merge^{commit} # timeout=10
Checking out Revision 1e99d8f52e88119f32ea513e0710e2d1c328e392 
(refs/remotes/origin/pr/4758/merge)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1e99d8f52e88119f32ea513e0710e2d1c328e392
Commit message: "Merge bc16e32ab7046caa7d031710fa1056b226fa3b2f into 
a7501289a23e2d8a3a7e5a3b9f5e920702d4d634"
First time build. Skipping changelog.
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Processing DSL script job_00_seed.groovy
Processing DSL script job_beam_Java_Build.groovy
Processing DSL script job_beam_Java_CodeHealth.groovy
Processing DSL script job_beam_Java_IntegrationTest.groovy
Processing DSL script job_beam_Java_UnitTest.groovy
Processing DSL script job_beam_PerformanceTests_Dataflow.groovy
Processing DSL script job_beam_PerformanceTests_FileBasedIO_IT.groovy
Processing DSL script job_beam_PerformanceTests_HadoopInputFormat.groovy
ERROR: (job_beam_PerformanceTests_HadoopInputFormat.groovy, line 64) No such 
property: context for class: javaposse.jobdsl.dsl.jobs.FreeStyleJob

Build failed in Jenkins: beam_SeedJob #1175

[Apache Jenkins Server]

See 

--
GitHub pull request #4758 of commit e5b6fd79420a4cfccf5c5dce40e0a0233c8bd7f2, 
no merge conflicts.
PR merge status couldn't be retrieved, maybe GitHub hasn't settled yet
Setting status of e5b6fd79420a4cfccf5c5dce40e0a0233c8bd7f2 to PENDING with url 
https://builds.apache.org/job/beam_SeedJob/1175/ and message: 'Build started 
sha1 is merged.'
Using context: Jenkins: Seed Job
[EnvInject] - Loading node environment variables.
Building remotely on beam4 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/beam.git # timeout=10
Fetching upstream changes from https://github.com/apache/beam.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/beam.git 
 > +refs/heads/*:refs/remotes/origin/* 
 > +refs/pull/4758/*:refs/remotes/origin/pr/4758/*
 > git rev-parse refs/remotes/origin/pr/4758/merge^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/pr/4758/merge^{commit} # timeout=10
Checking out Revision 1e99d8f52e88119f32ea513e0710e2d1c328e392 
(refs/remotes/origin/pr/4758/merge)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1e99d8f52e88119f32ea513e0710e2d1c328e392
Commit message: "Merge bc16e32ab7046caa7d031710fa1056b226fa3b2f into 
a7501289a23e2d8a3a7e5a3b9f5e920702d4d634"
First time build. Skipping changelog.
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Processing DSL script job_00_seed.groovy
Processing DSL script job_beam_Java_Build.groovy
Processing DSL script job_beam_Java_CodeHealth.groovy
Processing DSL script job_beam_Java_IntegrationTest.groovy
Processing DSL script job_beam_Java_UnitTest.groovy
Processing DSL script job_beam_PerformanceTests_Dataflow.groovy
Processing DSL script job_beam_PerformanceTests_FileBasedIO_IT.groovy
Processing DSL script job_beam_PerformanceTests_HadoopInputFormat.groovy
ERROR: (job_beam_PerformanceTests_HadoopInputFormat.groovy, line 64) No such 
property: context for class: javaposse.jobdsl.dsl.jobs.FreeStyleJob

Jenkins build is back to normal : beam_SeedJob #1174

[Apache Jenkins Server]

See 

Build failed in Jenkins: beam_SeedJob #1173

[Apache Jenkins Server]

See 

--
GitHub pull request #4758 of commit f29eb797d86ad20e2653e7dd0596c05f4287bca3, 
no merge conflicts.
Setting status of f29eb797d86ad20e2653e7dd0596c05f4287bca3 to PENDING with url 
https://builds.apache.org/job/beam_SeedJob/1173/ and message: 'Build started 
sha1 is merged.'
Using context: Jenkins: Seed Job
[EnvInject] - Loading node environment variables.
Building remotely on beam6 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/beam.git # timeout=10
Fetching upstream changes from https://github.com/apache/beam.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/beam.git 
 > +refs/heads/*:refs/remotes/origin/* 
 > +refs/pull/4758/*:refs/remotes/origin/pr/4758/*
 > git rev-parse refs/remotes/origin/pr/4758/merge^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/pr/4758/merge^{commit} # timeout=10
Checking out Revision 702e33896abf35396def935a801487ca2432106f 
(refs/remotes/origin/pr/4758/merge)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 702e33896abf35396def935a801487ca2432106f
Commit message: "Merge f29eb797d86ad20e2653e7dd0596c05f4287bca3 into 
a7501289a23e2d8a3a7e5a3b9f5e920702d4d634"
First time build. Skipping changelog.
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Processing DSL script job_00_seed.groovy
Processing DSL script job_beam_Java_Build.groovy
ERROR: startup failed:
workspace:/.test-infra/jenkins/common_job_properties.groovy: 262: Apparent 
variable 'WORKSPACE' was found in a static scope but doesn't refer to a local 
variable, static field or class. Possible causes:
You attempted to reference a variable in the binding or an instance variable 
from a static context.
You misspelled a classname or statically imported field. Please check the 
spelling.
You attempted to use a method 'WORKSPACE' but left out brackets in a place not 
allowed by the grammar.
 @ line 262, column 35.
   String kubeconfigLocation = "${WORKSPACE}/config-${namespace}"
 ^

1 error