On 12/29/15, 11:07 PM, "Alex Harui" wrote:
>
>
>On 12/29/15, 4:23 PM, "Justin Mclean" wrote:
>
>>Hi,
>>
>>Are we concerned that these 5 tests are failing (and seem to have been
>>for quite a while now)? [1]
>
>In the flex-sdk repo, running 'ant test' passes for me on Mac and Win so I
>am not c
On 12/29/15, 4:23 PM, "Justin Mclean" wrote:
>Hi,
>
>Are we concerned that these 5 tests are failing (and seem to have been
>for quite a while now)? [1]
In the flex-sdk repo, running 'ant test' passes for me on Mac and Win so I
am not concerned.
-Alex
Hi,
Are we concerned that these 5 tests are failing (and seem to have been for
quite a while now)? [1]
spark.components::DataGrid_FLEX_34837_Tests.test_removing_selected_item_on_multiple_field_sorted_grid_with_formatter_changed_after_first_sort_and_after_renaming
spark.components::DataGrid_FLE
In the US it's a holiday weekend too... good time for a little traveling.
-Mark
On Sun, Oct 13, 2013 at 9:21 AM, Nicholas Kwiatkowski wrote:
> I personally have a lot less time on the weekends as well. It would help me
> out by extending it so the vote does not primarily occur during a weekend.
lto:e...@ixsoftware.nl]
Envoyé : dimanche 13 octobre 2013 15:18
À : dev@flex.apache.org
Objet : Re: Mustella tests failing and release candidates
If we don't change anything, everything will remain the same.
EdB
On Sunday, October 13, 2013, Justin Mclean wrote:
> Hi,
>
> > MORE re
I personally have a lot less time on the weekends as well. It would help me
out by extending it so the vote does not primarily occur during a weekend.
-Nick
On Sun, Oct 13, 2013 at 12:41 AM, Justin Mclean wrote:
> Hi,
>
> > IIRC, there is precedence for extending the vote past 72 hours when it
ot everyone is going to be able to help with every release and again
> that's OK. If a release candidate doesn't get the 3 +1 votes it's not a
> release end of story.
>
> > we can set up a separate VM (as Fred suggests)
> A separate VM could help out here but it's
e. I prefer if
we can get by with less infrastructure and process if possible.
> Well, this all started because RC1 was cut while there were tests failing.
Last minute checkins caused other failures which turned out to be issues with
the tests (as far as I can see but it's possible t
t's the time it takes to do it right, than that's the time it
takes. If it turns out that your worst case scenario would play out,
we can set up a separate VM (as Fred suggests) and test the RCs on
that and keep testing 'develop' on the current one.
>> I really think this will
> 2) once all contributions have landed, cut the release branch; switch
> all Jenkins jobs and Mustella runs to 'release'; leave the release
> branch alone for 2 days so Mustella can be run in all configs.
Wouldn't it be better if we didn't have to manually switch all of the
Jenkins jobs? And the
erested in, but maybe it's more difficult with git
-Message d'origine-
De : Tom Chiverton [mailto:t...@apache.org]
Envoyé : dimanche 13 octobre 2013 11:03
À : dev@flex.apache.org
Objet : Re: Mustella tests failing and release candidates
On Sunday 13 October 2013 19:58:27 Justin
On Sunday 13 October 2013 19:58:27 Justin Mclean wrote:
> Wouldn't it be better if we didn't have to manually switch all of the
> Jenkins jobs?
For sure. The 'heads up, release coming email' could serve as a reminder to
stop landing patches on develop until the release was done ?
--
Tom
Hi,
> You tell us the current release workflow is too much work and to fragile.
What I would like to do is make release less effort and try and reduce the
number of release candidates and release more frequently. IMO that's the best
way to reduce the workload on the release manager. That and sha
On Sunday 13 October 2013 10:27:56 Erik de Bruin wrote:
> It will take more
> time, sure, but I don't think that is a bad thing in this case.
Works for me.
I'm not aware of a particular set of bugs/features or an active timebox or
anything that pushes us to do a release every N weeks or whatever
Justin,
I'm lost. You tell us the current release workflow is too much work
and to fragile. We suggest way to reduce the workload and make the
process more robust... And you come back telling us the current
workflow is the best way.
What are we missing? What are you asking of us?
I sure hope you
Hi,
> How would this help with running Mustella tests on the release branch,
> which is want Erik's point was?
You don't you keep running them off develop - less effort for all involved I
think that way. Merge often and there's less issues all round.
For instance what happens if after several r
On Saturday 12 October 2013 21:30:51 Alex Harui wrote:
> Another way to cut down on RCs may be to ask on the dev list before you
> cut the RC. Again, you kind of know who might help you out and review the
I'd find a heads up a few days before the the formal vote, as well as a longer
voting perio
Hi,
> But all that merging back and forth is extra work for the release
> manager.
It not a huge amount of work if everyone does it and means there less likely to
be merge issues. The 4.9 release had huge merge issue because we didn't merge
often enough.
Thanks,
Justin
On Oct 12, 2013 11:48 PM, "Justin Mclean" wrote:
>
> Hi.
>
> > Also, I think it might be a good idea that if we include a 'prepare
> > for RC' phase, I can switch the Mustella VM from the 'develop' branch
> > to the 'RC' branch.
> Wouldn't it be easier to just ask people to work in branches and no
>> Also, I think it might be a good idea that if we include a 'prepare
>> for RC' phase, I can switch the Mustella VM from the 'develop' branch
>> to the 'RC' branch.
> Wouldn't it be easier to just ask people to work in branches and not commit
> directly directly to develop unless they want it in
Hi.
> Also, I think it might be a good idea that if we include a 'prepare
> for RC' phase, I can switch the Mustella VM from the 'develop' branch
> to the 'RC' branch.
Wouldn't it be easier to just ask people to work in branches and not commit
directly directly to develop unless they want it in t
Hi,
> All I can say is that from my perspective (from scanning commit emails),
> the RELEASE_NOTES are constantly being fiddled with
I think it safe to assume once it's in a release candidate that they can be
reviewed.
> Giving us 24 hours to react to the latter might save you time and energy
>
On 10/12/13 10:17 PM, "Justin Mclean" wrote:
>Hi,
>
>> I saw you were working towards a new release, but I had no idea what day
>> you were actually going to go package stuff up and post it.
>See my email on the 5th with the title "Apache Flex 4.11 release test", I
>did ask if there was any obj
Also, I think it might be a good idea that if we include a 'prepare
for RC' phase, I can switch the Mustella VM from the 'develop' branch
to the 'RC' branch. That way, we know we're good for an RC if those
runs pass and not if they fail. The 'develop' branch is always in
motion and difficult to sta
Hi,
> I saw you were working towards a new release, but I had no idea what day
> you were actually going to go package stuff up and post it.
See my email on the 5th with the title "Apache Flex 4.11 release test", I did
ask if there was any objections then.
> Therefore I'm not going to bother t
On 10/12/13 9:41 PM, "Justin Mclean" wrote:
>Hi,
>
>> IIRC, there is precedence for extending the vote past 72 hours when it
>> covers weekends and holidays.
>Your assuming that most people has less time over that those periods.
>That's may not be the case as only a few people can work on Apach
Hi,
> IIRC, there is precedence for extending the vote past 72 hours when it
> covers weekends and holidays.
Your assuming that most people has less time over that those periods. That's
may not be the case as only a few people can work on Apache Flex while at their
day job.
> If it were me (and
On 10/12/13 3:41 PM, "Justin Mclean" wrote:
>Hi,
>
>> That said, the fact is that many of the 72 hours
>Do you think that have a RC votes open for 5 days rather than 3 cut down
>on the number of RCs and thus the total time?
IIRC, there is precedence for extending the vote past 72 hours when it
On Oct 12, 2013 3:42 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > That said, the fact is that many of the 72 hours
> Do you think that have a RC votes open for 5 days rather than 3 cut down
on the number of RCs and thus the total time?
+1. I am completely slammed this weekend. Some extra time to t
Hi,
> That said, the fact is that many of the 72 hours
Do you think that have a RC votes open for 5 days rather than 3 cut down on the
number of RCs and thus the total time?
Thanks,
Justin
Hi,
>> We all owe it to the release manager to do as much digging as possible
>> before the next RC is cut.
> IMO that asking far too much of the release manager, it shouldn't be their
> job to find and fix every issue.
Which on second reading is exactly what the point is you're trying to make
Hi,
> We all owe it to the release manager to do as much digging as possible
> before the next RC is cut.
IMO that asking far too much of the release manager, it shouldn't be their job
to find and fix every issue.
Thanks,
Justin
On 10/12/13 6:09 AM, "Erik de Bruin" wrote:
>Actually, it isn't... It's been with us since July 12th, on and off.
There are two failures. One radiobutton issue is new, the DND issue is
old, but I believe it passes on 11.1 player some of the time.
-Alex
Well, that's a good point about a -1 vote causing people to stop looking,
but really, and hopefully, with carryover voting, they shouldn't and
won't. We all owe it to the release manager to do as much digging as
possible before the next RC is cut.
That said, the fact is that many of the 72 hours
Hi,
It would help if PMC members actually followed all the steps in validating a
release before voting -1, that would cut down of the number of RC we need to
go through.
I think we should make it a rule you can't vote -1 or +1 until you have checked
everything, otherwise it's just too much wo
Justin, I appreciate all the effort you put into this, and I
understand that you are trying to make releases as painless and quick
as possible.
If you want me to stop doing what I'm doing, I'm fine with that. Until
such a time, I'll keep hammering on zarro boogs before a release. If
you can get so
Actually, it isn't... It's been with us since July 12th, on and off.
EdB
On Sat, Oct 12, 2013 at 2:58 PM, Justin Mclean wrote:
> Hi,
>
>> The current failure has beenaround for a while now
> Actually this is a new issue, the previous longer standing issues have been
> fixed.
>
> Justin
--
Hi,
> We decided we would do CI for this project
Was a VOTE taken if this stops releases? CI is a tool nothing more, nothing
less and we shouldn't be a slave to it.
> and it doesn't look like it will get much attention if it doesn't block the
> VOTE
And if it does block the vote who will fix i
Hi,
> The current failure has beenaround for a while now
Actually this is a new issue, the previous longer standing issues have been
fixed.
Justin
We decided we would do CI for this project, to monitor the health of
the codebase on a regular basis. While I might agree that on the face
of it, having one test fail might not be a showstopper, I think that
the system only works if we stick to it. The current failure has been
around for a while no
Hi,
The mustella tests are not part of the source release so IMO it's actually not
hugely relevant unless it's a serious issue or causes a regression.
If we fixed 50 bugs and add new functionally I'd say that outweighs a minor
focus issue or an issue with one of the 30,000+ tests and that shoul
Oh, my bad, I've been mixing my issues. But the above is basically the
same for FalconJx. You can find the project here:
https://builds.apache.org/view/E-G/view/Flex/
Select a build as above and view the "Test Result" item on the left.
The console output is same as above.
EdB
On Mon, Jun 3, 2
If you open Chrome, it will open on the Jenkins main page. Click on
the mustella job (top one) and in the bottom left corner you'll see a
list of the most recent builds. Click one. On the left there is an
item named "Console Output"... Or paste this URL:
http://localhost:8080/job/flex-sdk_mustella
Where do we find the Jenkins results and log?
On 6/2/13 10:52 AM, "Erik de Bruin" wrote:
>Hi,
>
>I can't figure this one out: when I run the falconjx tests
>(compiler.jx.tests) on my local Mac and Windows machine, all tests
>pass. But when the tests are run as part of a Jenkins job, several
>tes
Hi,
I can't figure this one out: when I run the falconjx tests
(compiler.jx.tests) on my local Mac and Windows machine, all tests
pass. But when the tests are run as part of a Jenkins job, several
tests that involve external files fail.
Maybe someone can have a look and maybe figure out what's go
Thanks Alex, I was offline a few days.
-Mark
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Sunday, May 12, 2013 2:15 AM
To: dev@flex.apache.org
Subject: Re: Mustella list tests failing
Update: I didn't look into whether validateNow() is truly necessary o
Update: I didn't look into whether validateNow() is truly necessary or not,
but in my analysis, it appears that the tests were relying on the list
drawing at full alpha before the tween kicks in, which I think would run the
risk of a "blink" and Mark's change seems to fix that, so I'm going to go
It was Mark's change for https://issues.apache.org/jira/browse/FLEX-23974
The validateNow() call he added changes the selectiontween timing somehow.
The bitmap captures the tween in action which is why the color isn't final.
I'll look into it more this evening unless Mark gets to it first. The
a
I'm looking into this over the weekend.
On 5/1/13 4:27 PM, "Justin Mclean" wrote:
> Hi,
>
>> Well they are all Failed CompareBitmap right? So we just have to track
>> down graphical changes?
>
>
> The colour of a selected item seem lighter/more transparent, I had a quick
> look through the
Hi,
> Well they are all Failed CompareBitmap right? So we just have to track
> down graphical changes?
The colour of a selected item seem lighter/more transparent, I had a quick look
through the changes and couldn't see anything obvious. I do know it not the
Bitmap changes or the 480 dpi chan
Looking at the images, the only changes seem to be the alpha of the
colors? The example one is pure red and the bad one shows the same image
except the selection is like 0.10 or such of the alpha?
[1]
Flex\mustella\tests\components\List\Styles\Baselines\list_listbase_styles_selectionColor_0x.png
Well they are all Failed CompareBitmap right? So we just have to track
down graphical changes?
On Wed, May 1, 2013 at 6:11 PM, Justin Mclean wrote:
> Hi,
>
> > =
> >Passes: 191
> >Fails: 19
> > =
Hi,
> =
>Passes: 191
>Fails: 19
> =
Looks like one of the recent changes to the List classes has changed something
that the test don't expect. Not sure if it's a real issue or not.
Ju
Ran a mustella test for it [1] and it showed failures [2].
[1] mini_run.sh components/List
[2]
=
Passes: 191
Fails: 19
=
components/List/Styles/ListStyleListBaseTester
list_listbase_st
Hi,
Just run the list tests like so and I'm getting 19 failures.
./mini_run.sh tests/components/List
All are bitmap failures and look like the highlight colour has changed to be
lighter.
Can anyone confirm these tests pass or fail?
Thanks,
Justin
Quoting Erik de Bruin :
Mike,
I've just updated my local projects, but some of the AMD test are
still failing. Is this expected (in the light of your earlier
statement about AMD tests) and should I ignore, or should is this a
problem on my end and should I hold of on commits until we figure ou
Mike,
I've just updated my local projects, but some of the AMD test are
still failing. Is this expected (in the light of your earlier
statement about AMD tests) and should I ignore, or should is this a
problem on my end and should I hold of on commits until we figure out
what it is?
EdB
--
Ix
57 matches
Mail list logo
