TB24 inclusion for new minor feature (thread-sorting pref)

The Wanderer wanderer at fastmail.fm
Mon Aug 12 12:32:55 UTC 2013


On 08/12/2013 03:35 AM, acelists at atlas.sk wrote:

> Hi. In the bug we couldn't find many tests testing sorting behaviour.

At the time, we were only looking at mozmill tests. (IIRC, we didnt
actually find any at all that actually tested sorting, just a few that
changed sorting in the course of testing something else.)

Since then, I've found a few message-sorting-related xpcshell tests, 
including at least one which involves threads - but even that one 
appears to only test whether messages inside an expanded thread are 
sorted correctly, rather than testing the sort order of threads 
themselves. None of them seem to be related to the behavior I'm 
changing, and all of them pass with the fix applied.

> Maybe you could create some in exchange for including the patch and
> to prove it does not break anything? :)

I had that idea myself, and I wouldn't be opposed to it. However:

A, it seemed a bit awkward trying to get a new-tests patch accepted on
what was by that point a RESOLVED FIXED bug.

B, the most closely related existing tests (and thus, most adaptable
existing code) are xpcshell-based - but not only does this not sound
like the sort of test which fits under the umbrella of what MDN
describes as xpcshell's domain, I don't have my head around xpcshell. At
the very least, I'd probably need a fair bit of hand-holding through
parts of the process.

C, due to bug 890877, the process of building and testing is excessively
clunky for me at present. It involves at least three additional steps
compared to the "normal" build/test process, which take a good half an
hour each; add in the time required to build and the time required to
run tests (since none of the documented "run a single test without first
running all the others" methods seem to work for me), and it's at least
two and a half hours per "test of the just-written code" (with manual
intervention several times in the middle), which makes the iterative
development process a royal pain. I would far rather avoid trying to
learn to write tests until that's fixed, so that I can test what I've
written in a more reasonable fashion.

D, creating such tests would take time - and we're already close enough
to the TB24 really-absolutely-final-we-mean-it-this-time deadline, i.e.
the actual release date, as it stands. I'd rather make the request as
far before that deadline as possible, to at least get some indication of
whether there's a chance to get the fix accepted in the first place,
rather than spring it on people even later because I took the extra time
to create those tests first. (If there isn't a chance to get the fix
accepted into the TB24 release line, then there's far less of a rush to
create the tests, and the potential to be much more careful about doing
so.)

I'd actually like to have thread-sort-order tests in place; if they had
existed at the time of the original regression, it would probably have
been noticed immediately, and might have been fixed much sooner than
this. I don't particularly have a problem with being the one to create
them, either. Due to the above, however, this might not be the best time
for it.

-- 
    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger



More information about the tb-planning mailing list