On 11/5/14, 1:32 PM, "Justin Mclean" wrote:
>Hi,
>
>I'll also point out that what is currently being looked at it identical
>to RC0 that I called a vote on a week ago, so there would be no need to
>cancel that vote and call another one.
I think the MD5s probably changed. SWFs built at differe
Hi,
I'll also point out that what is currently being looked at it identical to RC0
that I called a vote on a week ago, so there would be no need to cancel that
vote and call another one.
There's only been one change made to the release branch which was an addition
of a MD5 check by Alex and IM
Hi,
> If the people who said they were looking at something have reported back,
> if all promised fixes have been committed and if all tweaks to the docs
> have been made - in other words, when the release branch has stabilised
> the RM decides when to call the vote.
IMO That is currently the ca
>
> OK we currently have two (minor) issues which I'm unable to produce
> locally. And I have no idea if any PMC members have checked the important
> things like hashes and the like. How do we progress from here? How does the
> RM decide when it's time call a vote? So far this process has taken lon
Hi,
OK we currently have two (minor) issues which I'm unable to produce locally.
And I have no idea if any PMC members have checked the important things like
hashes and the like. How do we progress from here? How does the RM decide when
it's time call a vote? So far this process has taken longe
+1 to this.
-Original Message-
I like this idea to have a special nightly build for releases during the
release process. It seems to me that it should simplify the process all
around.
Harbs
The nightly source builds can be found here:
http://apacheflexbuild.cloudapp.net:8080/job/flex-utilities_tour-de-flex-release/lastSuccessfulBuild/artifact/TourDeFlex/TourDeFlex3/out/
The nightly 'binary' build can be viewed here (for the time being, until I
figure out a way to archive that proper
Waiting on for the 'flex-sdk' job to finish so I can try the new TDF
release build.
EdB
On Tue, Nov 4, 2014 at 9:18 AM, Justin Mclean
wrote:
> Hi,
>
> > That is not at all what I wrote. Please read emails more carefully
>
> I did read it carefully you said "It takes very little effort for the
Hi,
> That is not at all what I wrote. Please read emails more carefully
I did read it carefully you said "It takes very little effort for the release
manager to set up a copy of the build of the develop branch".
Given it takes very little effort and you now say that it's not the release
mana
>
> > That was very selective quoting ... I clearly state "the latest HEAD from
> > the release branch."
>
> So we would need to either alter existing CI jobs and add additional ones
> every time a release branch is made?
>
That is not at all what I wrote. Please read emails more carefully ... I
r
Hi,
> That was very selective quoting ... I clearly state "the latest HEAD from
> the release branch."
So we would need to either alter existing CI jobs and add additional ones every
time a release branch is made?
> It takes very little effort for the release manager to set up a copy of the
> b
I like this idea to have a special nightly build for releases during the
release process. It seems to me that it should simplify the process all around.
Harbs
On Nov 4, 2014, at 9:38 AM, Erik de Bruin wrote:
>>
>>> I'd go (and will go) one further, and use nightlies during this phase.
>>
>>
>
> > I'd go (and will go) one further, and use nightlies during this phase.
>
> How would that be possible given nightly are off the develop branch not a
> release branch. Other people may check stuff into develop that we don't
> want in the release under consideration. Also currently there are no
Hi,
> I'd go (and will go) one further, and use nightlies during this phase.
How would that be possible given nightly are off the develop branch not a
release branch. Other people may check stuff into develop that we don't want in
the release under consideration. Also currently there are no nig
On 11/3/14, 11:24 PM, "Justin Mclean" wrote:
>Hi,
>
>>> For TDF, because it is an “app”, if you want more feedback, it might be
>>> reasonable to post a deployed version of TDF somewhere like your
>>>personal
>>> folder
>
>It will take an hour or so to upload a tar of the files via scp to
>peop
Hi,
>> For TDF, because it is an “app”, if you want more feedback, it might be
>> reasonable to post a deployed version of TDF somewhere like your personal
>> folder
It will take an hour or so to upload a tar of the files via scp to
people.apache.org. Part of the reason we don't have a binary r
>
> > If issues are found during the discussion phase, you can just drop a
> new package over the old package.
>
> -1 to this as this will cause all sort of confusion to exactly what
> version an issue was in or what version people tested and this could more
> RCs rounds not less and a lot more wo
Hi,
> I expected the next step is that you put up a release candidate and open a
> [DISCUSS] thread, but not a [VOTE] thread.
Fair enough. I have opens a discuss thread but had very little response. Given
we had a discussion open for over a week and no major issues have been found
what do you r
+1
Excellent summary!
EdB
On Tuesday, November 4, 2014, Alex Harui wrote:
>
>
> On 11/3/14, 3:30 PM, "Justin Mclean" > wrote:
>
> >Hi,
> >
> >I asked for feedback over a period of a week and only feedback was to
> >change a title. Without a release candidate is seens to me that people are
>
19 matches
Mail list logo