Hi everyone,
At this point, I would like to suggest we table this debate until Bertrand
gets a chance to look at the latest version of the new release process
proposal. If he’s ok with the proposal, then we put it up for a vote.
Thanks,
-Alex
On 12/7/14, 12:34 AM, "OmPrakash Muppirala" wrote:
On Dec 7, 2014 12:24 AM, "Justin Mclean" wrote:
>
> Hi,
>
> > 'Fairly' accurate is not good enough.
>
> I not done the stats on every release but you would have to agree it's
happened many times. The fact we don't have only 1 or 2 RC for each
release confirms it. I'd estimate that 80%+ of the rel
Hi,
> 'Fairly' accurate is not good enough.
I not done the stats on every release but you would have to agree it's happened
many times. The fact we don't have only 1 or 2 RC for each release confirms
it. I'd estimate that 80%+ of the releases have had more than 2 RCs I think
"fairly accurate
On Dec 6, 2014 9:13 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > You are doing it again :-)
>
> IMO It was a fairly accurate representation of the state of affairs. You
do realise when I write "PMC" I'm including myself? For instance look at
the amount of feedback from the the "test" RC of TourDeFlex
Hi,
> You are doing it again :-)
IMO It was a fairly accurate representation of the state of affairs. You do
realise when I write "PMC" I'm including myself? For instance look at the
amount of feedback from the the "test" RC of TourDeFlex (RC0) and then the
issues found in RC1 and RC2. Other r
On Dec 6, 2014 4:08 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > Here's my suggested release (non-) process.
>
> As far as I can see we been doing all of that with the old process [1]
with the exception that we usually make multiple RCs. Here's an example
JIRA for the 4.12 release. [2]
>
> So why mult
Hi,
> Here's my suggested release (non-) process.
As far as I can see we been doing all of that with the old process [1] with the
exception that we usually make multiple RCs. Here's an example JIRA for the
4.12 release. [2]
So why multiple RCs? The PMC usually puts off testing / checking thing
We don't mention it explicitly in the 'less-RC' article (since it's a
long time and good practice Justin set up way back when), but we also
use your suggested method of using JIRA tickets to track the release
progress [1].
EdB
1: https://issues.apache.org/jira/browse/FLEX-34560
On Sat, Dec 6,
On Sat, Dec 6, 2014 at 10:13 AM, Erik de Bruin wrote:
> ...that is a very accurate summary of the 'less-RC' process [1]
> we've been working on for our future releases...
Oh cool! For some reason that felt more complicated when I looked at
it - I'll have another look after the week-end!
-Bertran
Bertrand, that is a very accurate summary of the 'less-RC' process [1]
we've been working on for our future releases.
Thanks,
EdB
1: https://cwiki.apache.org/confluence/x/2oH0Ag
On Sat, Dec 6, 2014 at 10:05 AM, Bertrand Delacretaz
wrote:
> Hi Flex team,
>
> Reviewing your activities to try a
Hi Flex team,
Reviewing your activities to try and help this community run in a
smoother way, I'm wondering why you need release candidates.
Those were useful during your Apache incubation, to allow "total
strangers" who don't have the right tools for example to review your
releases, but in a sma
11 matches
Mail list logo
