Re: [lmi] wx update; pending specification changes

[Greg Chicares]

On 2014-12-06 13:25Z, Vadim Zeitlin wrote:
> On Sat, 06 Dec 2014 11:38:51 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > Me> [...] whether you apply the above patch or not
> GC> 
> GC> I'm deliberately deferring it in order to focus on 'wx_test' for now.
> 
>  The trouble is that I risk having merge conflicts with this patch when I
> do the other changes to the test (e.g. cleanup ones). I will, of course, be
> able to resolve it -- using Git gives me confidence to perform merges I
> would never dream of doing with svn, and this is by far not the worst of
> them -- but it would be even better to not have to do it at all.

I feel certain that I recently read a message from you asking that a certain
patch be applied soon to avoid conflicts later. I looked through numerous
messages to try to find that one, but I couldn't find it. And I just now
examined your 2014-11-30T01:04Z that started this thread, but that doesn't
seem to be the one I was looking for. Or is it? Did I reexamine it too
casually? Or is it a different message?

I'm in much the same position myself. I'm juggling many local changes of my
own, and frequently moving them aside to apply your changes. I anticipate that
your patches will still apply correctly (with "fuzz") as long as I change only
comment blocks in 'wx_test*.cpp'. I'm eager to apply those changes soon so
that Kim can review them and tell me if I've misunderstood her wishes.

But if there's a particular changeset that you'd like me to prioritize, I'll
try to do that.

>  I also wonder about the other test-related patches I am working on (or
> planned to start soon), notably the "test cleanup" patch which adds
> removing of the temporary files and the preservation of configurable
> settings file and recently open files history and also the one adding
> "--gui_test_path" command line option. Without speaking about moving the
> "Test" menu contents into the automated tests, which I didn't start yet,
> but was planning to do next. I can work on several things at once, but I'm
> afraid I start having a bit too many balls in the air to handle all of them
> efficiently...

I feel the same way, so let's work harder on coordination.

> GC> Kim and I have already reviewed several of the automated GUI tests, and
> GC> I'm writing specifications that explain what we really want them to do.
> GC> Soon I'll commit a modified 'wx_test_about_version.cpp' with a comment
> GC> block indicating the desired behavior. It won't actually describe the code
> GC> it precedes, yet; please take is as our request to change the code so that
> GC> it does what the comment says.
> 
>  Working on it.

In the spirit of coordination...I don't think it's terribly important for
you to prioritize this or any of (thirteen!) similar specification changes
I'm drafting. If I can just get these comments-only changes committed, then
you can address them when convenient. I think the changes they describe will
be mostly confined to the single file in which each comment block occurs.

> GC> If that process suits you, I'll commit similar changes to the thirteen
> GC> other 'wx_test*.cpp' files. Or, if you prefer, I could copy the comment
> GC> block of each file here as we modify it, to start a discussion thread.
> 
>  This would be even better for me, as I will almost certainly have
> questions about less trivial tests. And while on the surface it might seem
> that it would be more work for you, I'm not even sure about this, as I
> could just include the comment in my patch implementing the requested
> behaviour, so AFAICS it just replaces writing the comment with writing an
> email for you, which shouldn't be materially different. So, if possible,
> I'd prefer to start with emails.

It's hardly any extra work for me to copy the comment blocks into new
email threads; I figure I'll do a separate one for each file, starting
with the one that I just committed. I strongly prefer to change the
comments in each file and then post them here: I have been trying to
maintain a separate offline list of all the changes, and it's growing
unmanageably large. And if this causes your patches to apply with, say,
"fuzz 22 lines", that's easy for me to deal with. But am I missing some
reason why my proposed method might make things harder for you?