Re: Unifying testsuite policy and getting rid of CSS exceptions

So when that happens, I believe our current approach will basically fall
back to treating the moved tests as new tests and baselining them from
scratch. The old baselines/expectations will become orphaned and removed.
This is not ideal either, but seems to work alright so far.

On Sep 19, 2017 00:18, "Geoffrey Sneddon" <me@gsnedders.com> wrote:

> That seems like it'll be relatively brittle, given tests moving are
> often accompanied by changing paths that appear within them. 100% just
> seems too strong.
>
> /g
>
> On Tue, Sep 19, 2017 at 4:21 AM, Robert Ma <robertma@google.com> wrote:
> > We use `git diff -M100% --diff-filter=[D,R]` under the hood to detect
> > deleted and renamed/moved tests respectively. Based on the git output,
> > we move the baselines and modify expectation lines accordingly.
> >
> > Code can be found here:
> > https://cs.chromium.org/chromium/src/third_party/
> WebKit/Tools/Scripts/webkitpy/w3c/test_importer.py?l=522&rcl=
> c0e9500011d99dfd43654e5217253c3107e3f4ec
> >
> > On Sat, Sep 16, 2017 at 8:31 AM, Philip Jägenstedt <foolip@google.com>
> wrote:
> >> On Sat, Sep 16, 2017 at 1:00 AM James Graham <james@hoppipolla.co.uk>
> wrote:
> >>>
> >>> On 16/09/17 04:51, Philip Jägenstedt wrote:
> >>> > On Thu, Sep 14, 2017 at 6:42 PM Alan Stearns <stearns@adobe.com>
> wrote:
> >>> >
> >>> >> Given that there are costs associated with moving tests around, I’m
> >>> >> slightly in favor of leaving current tests where they are.
> >>> >>
> >>> >
> >>> > Can you elaborate a bit on this? I don't disagree that there is
> *some*
> >>> > cost, but at least from my vantage point it seems quite acceptable.
> When
> >>> > tests are renamed we deal with it in the Chromium import process, and
> >>> > doesn't require us to treat all of the renamed files as if they were
> >>> > new.
> >>> > If there are other bits of tooling that don't handle renames well, I
> >>> > wouldn't mind investing a bit of time fixing that.
> >>>
> >>> Our import process doesn't (currently) deal with moving tests well. We
> >>> can and should improve that. However a one-time patch moving lots of
> >>> paths is something that we could deal with manually, so that shouldn't
> >>> be a blocker to choosing a better organisation.
> >>
> >>
> >> I see. Quinten, Robert, can you share something about how the rename
> >> detection for our import works, does it only handle change-free
> renames, or
> >> is there a similarity threshold of sorts?
> >>
> >> In any case, it's good to hear that simple directory renames aren't an
> issue
> >> for Gecko.
> >>
> >> Would directory renaming create trouble for anyone else?
> >
> >
>