Bug 62241 – rebaseline-chromium-webkit-tests: fix baselining order for linux, linux_x86_64

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Dirk Pranke]

rebaseline-chromium-webkit-tests: fix baselining order for linux, linux_x86_64

[Dirk Pranke]

Created attachment 96315 [details]
Patch

[Dirk Pranke]

When we made the 64-bit port the "generic" chromium-linux port, we forgot to switch the ordering of the ports in port.ALL_BASELINE_VARIANTS, which is used by rebaseline-chromium-webkit-tests to figure out which baselines to pull in which order.

Without this change, we'd end up generating duplicate baselines for both linux variants and they wouldn't get deduped.

[Tony Chang]

Comment on attachment 96315 [details]
Patch

Can we write a test for this?

[Dirk Pranke]

(In reply to comment #3)
> (From update of attachment 96315 [details])
> Can we write a test for this?

It depends. what would you want to test? The _unittest file does test that, for example, if the Vista dir duplicates the Win dir, then deduping works, so there is already a test for the deduping logic by itself.

But, if you wanted to test that the linux 32 port was deduped into the base linux port, all it would be testing was that the ports were listed in the right order in the same constant, creating another place to update if we change the order.

[Tony Chang]

(In reply to comment #4)
> But, if you wanted to test that the linux 32 port was deduped into the base linux port, all it would be testing was that the ports were listed in the right order in the same constant, creating another place to update if we change the order.

Yes, I think that would be valuable.

[Dirk Pranke]

(In reply to comment #5)
> (In reply to comment #4)
> > But, if you wanted to test that the linux 32 port was deduped into the base linux port, all it would be testing was that the ports were listed in the right order in the same constant, creating another place to update if we change the order.
> 
> Yes, I think that would be valuable.

Well, you would have had to know to change the test and change the list when you made your actual change. Since you missed the one place, you probably would've missed the other, so I don't think the test would've actually caught anything.

More generally, if you wanted to test this particular case, presumably you'd test that all of the other deduping works as you'd expect (e.g., xp dups vista, etc.). That seems like a lot of work for little reward.

[Dirk Pranke]

Comment on attachment 96315 [details]
Patch

Clearing flags on attachment: 96315

Committed r88281: <http://trac.webkit.org/changeset/88281>

[Dirk Pranke]

All reviewed patches have been landed.  Closing bug.