failing silently.
Does that work for?
Santhosh
From: Olga Natkovich
To: "dev@pig.apache.org"
Sent: Monday, December 17, 2012 4:16 PM
Subject: Re: Our release process
Hi Jonathan,
I thought I answered your email last week but I just noticed that the a
this respect.
Olga
From: Jonathan Coveney
To: "dev@pig.apache.org" ; Olga Natkovich
Sent: Thursday, December 13, 2012 1:14 PM
Subject: Re: Our release process
Olga,
A related but separate question: what do y'all do when there is a feature
that
ill likely need a private branch if our rules
> are too relaxed.
>
> Olga
>
>
>
> - Original Message -
> From: Julien Le Dem
> To: "dev@pig.apache.org" ; Olga Natkovich <
> onatkov...@yahoo.com>
> Cc:
> Sent: Wednesday, December 12, 2012
ikely need a private branch if our rules are too
relaxed.
Olga
- Original Message -
From: Julien Le Dem
To: "dev@pig.apache.org" ; Olga Natkovich
Cc:
Sent: Wednesday, December 12, 2012 4:54 PM
Subject: Re: Our release process
Agreed. The priority of a change is subject
t; To: "dev@pig.apache.org"
> Sent: Wednesday, December 12, 2012 10:26 AM
> Subject: Re: Our release process
>
> I think we all agree here, let's not jump to conclusions.
> Everything in this branch I am talking about is in Apache Pig. Everything
> we do in Pig is
che.org"
Sent: Wednesday, December 12, 2012 10:26 AM
Subject: Re: Our release process
I think we all agree here, let's not jump to conclusions.
Everything in this branch I am talking about is in Apache Pig. Everything
we do in Pig is contributed.
We have a branch for 0.11 where we keep
ll.
> > >
> > > Olga
> > >
> > >
> > >
> > > From: Julien Le Dem
> > > To: Olga Natkovich
> > > Cc: "dev@pig.apache.org" ; Santhosh M S <
> > santhosh_mut...@yahoo.com>; &
> > From: Julien Le Dem
> > To: Olga Natkovich
> > Cc: "dev@pig.apache.org" ; Santhosh M S <
> santhosh_mut...@yahoo.com>; "billgra...@gmail.com"
> > Sent: Friday, December 7, 2012 3:54 PM
> > Subject: Re: Our release process
> &
approach as well.
>
> Olga
>
>
>
> From: Julien Le Dem
> To: Olga Natkovich
> Cc: "dev@pig.apache.org" ; Santhosh M S
> ; "billgra...@gmail.com"
> Sent: Friday, December 7, 2012 3:54 PM
> Subject: Re: Our release process
>
> Here's my criteria
into branches, we will go with private branch
approach as well.
Olga
From: Julien Le Dem
To: Olga Natkovich
Cc: "dev@pig.apache.org" ; Santhosh M S
; "billgra...@gmail.com"
Sent: Friday, December 7, 2012 3:54 PM
Subject: Re: Our release
he
> criteria stringent enough of if they need to run a private branch.
>
> Olga
>
> --
> *From:* Santhosh M S
> *To:* Julien Le Dem ; "dev@pig.apache.org" <
> dev@pig.apache.org>
> *Cc:* "billgra...@gmail.com"
>
@pig.apache.org; Santhosh M S
Cc: "billgra...@gmail.com"
Sent: Friday, November 30, 2012 5:37 PM
Subject: Re: Our release process
Proposed criteria:
- it makes the tests fail. targets test-commit + test + e2e tests
- a critical bug is reported in a short time frame (definition of
cr
Cc: "billgra...@gmail.com"
Sent: Friday, November 30, 2012 5:37 PM
Subject: Re: Our release process
Proposed criteria:
- it makes the tests fail. targets test-commit + test + e2e tests
- a critical bug is reported in a short time frame (definition of
critical not needed as it is
ts get the release trains going. We can revisit the
> criteria for inclusion of bug fixes when that happens.
>
> Santhosh
>
>
>
> From: Julien Le Dem
> To: dev@pig.apache.org; Santhosh M S
> Cc: "billgra...@gmail.com"
&g
y. If
> not the barrier for inclusion is pretty high and time consuming making it
> harder to develop.
>
> Santhosh
>
>
>
> From: Bill Graham
> To: dev@pig.apache.org
> Sent: Wednesday, November 28, 2012 11:39 AM
> Subject: Re:
nclusion is pretty high and time consuming making it
> harder to develop.
>
> Santhosh
>
>
>
> From: Bill Graham
> To: dev@pig.apache.org
> Sent: Wednesday, November 28, 2012 11:39 AM
> Subject: Re: Our release process
>
> I ag
catch these errors early. If not
the barrier for inclusion is pretty high and time consuming making it harder to
develop.
Santhosh
From: Bill Graham
To: dev@pig.apache.org
Sent: Wednesday, November 28, 2012 11:39 AM
Subject: Re: Our release process
I
; > I am proposing that P2s be included in the released branch only when
> trunk or unreleased versions are known to be backward incompatible or if
> the release is more than a quarter (or two) away.
> >
> > Thanks,
> > Santhosh
> >
> >
e or if the release
> is more than a quarter (or two) away.
>
> Thanks,
> Santhosh
>
>
> From: Olga Natkovich
> To: "dev@pig.apache.org" ; Santhosh M S
>
> Sent: Tuesday, November 27, 2012 10:41 AM
> Subject: Re: Our release proce
,
Santhosh
From: Olga Natkovich
To: "dev@pig.apache.org" ; Santhosh M S
Sent: Tuesday, November 27, 2012 10:41 AM
Subject: Re: Our release process
Hi Santhosh,
What is your definition of P2s?
Olga
- Original Message -
From: Santhosh M S
Hi Santhosh,
What is your definition of P2s?
Olga
- Original Message -
From: Santhosh M S
To: "dev@pig.apache.org" ; Olga Natkovich
Cc:
Sent: Monday, November 26, 2012 11:49 PM
Subject: Re: Our release process
Hi Olga,
I agree that we cannot guarantee backward com
developers to fix issues of significance
without impacting stability.
Thanks,
Santhosh
From: Olga Natkovich
To: "dev@pig.apache.org"
Sent: Monday, November 26, 2012 9:38 AM
Subject: Re: Our release process
Hi Santhosh,
I understand the compatibi
.
Olga
From: Santhosh M S
To: Olga Natkovich ; "dev@pig.apache.org"
Sent: Monday, November 26, 2012 12:00 AM
Subject: Re: Our release process
It takes too long to run. If the e2e tests are run every night or a reasonable
timeframe then it will
From: Olga Natkovich
To: "dev@pig.apache.org" ; Santhosh M S
Sent: Sunday, November 25, 2012 5:56 PM
Subject: Re: Our release process
Hi Santhosh,
Can you clarify why running e2e tests on every checking is a problem?
Olga
___
Hi Santhosh,
Can you clarify why running e2e tests on every checking is a problem?
Olga
From: Santhosh M S
To: "dev@pig.apache.org"
Sent: Monday, November 19, 2012 3:48 PM
Subject: Re: Our release process
The push for an upgrade will work only if
then I am -1 for having to run e2e for every commit to a released branch.
Santhosh
From: Jonathan Coveney
To: "dev@pig.apache.org"
Sent: Tuesday, November 6, 2012 6:34 PM
Subject: Re: Our release process
I think it might be good to clarify (for me
I think it might be good to clarify (for me) a couple of cases:
1. we have branched a new release
2. an existing release
The way I understand things, in the case of 1, we have a backlog of patches
(not all of which are P1 bugs), and that's ok. If a new bad bug comes in
(the subject of debate here
Jonathan, for clarity, are you saying you agree that we should only put bug
fixes in branches or we should only put high priority bug fixes in branches? I
think we all agree on the former, but there appear to be different views on the
latter.
Alan.
On Nov 5, 2012, at 4:53 PM, Jonathan Coveney
This seems to make sense to me. People can always back-port features, and
this encourages them to use the newer ones. It also means we will be more
rigorous about stability, which is good as it is a big plus for Pig. I
think for older branches, stability trumps features in a big way.
2012/11/5 Gi
Hi,
On Mon, Nov 5, 2012 at 10:48 AM, Olga Natkovich wrote:
> Hi Gianmarco,
>
> Thanks for your comments. Here is a little more information.
>
> At Yahoo, we consider the following issues to be P1:
>
> (1) Bugs that cause wrong results being produced silently
> (2) Bugs that cause failures with no
quickly when
things break.
Olga
From: Gianmarco De Francisci Morales
To: dev@pig.apache.org; Olga Natkovich
Sent: Monday, November 5, 2012 10:37 AM
Subject: Re: Our release process
Hi,
Sure we don't want to commit patches that destabilize the code base.
Ho
would go with the private
> git branch.
>
> Olga
>
>
>
> From: Alan Gates
> To: dev@pig.apache.org
> Sent: Friday, November 2, 2012 8:19 PM
> Subject: Re: Our release process
>
> I am all for maintaining stability of branches, and the trunk, as everyone
> benefits
Olga
From: Alan Gates
To: dev@pig.apache.org
Sent: Friday, November 2, 2012 8:19 PM
Subject: Re: Our release process
I am all for maintaining stability of branches, and the trunk, as everyone
benefits from it. But I do not think this means we should limit bug fixing in
the branch
Hi,
I agree with what Alan says and I like his proposal.
However, to make it feasible, we need to make jenkins builds stable,
otherwise a real problem introduced by a patch might be lost in the
hundreds of failures due to clover licenses, minicluster issues, etc...
I don't like too much making je
I am all for maintaining stability of branches, and the trunk, as everyone
benefits from it. But I do not think this means we should limit bug fixing in
the branches to only critical issues. As Pig gets more users we have more and
more people on older branches who will want fixes for bugs with
Hi guys,
Mid next year, we agreed on a release process documented in this thread:
http://www.mail-archive.com/dev@pig.apache.org/msg04172.html.
Since then, we have not really followed either of its two rules:
(1) Frequent (every 3 month releases)
(2) Branch stability (only P1 issues on the b
36 matches
Mail list logo
