Re: [lmi] wx update; pending specification changes

[Vadim Zeitlin]

On Sat, 06 Dec 2014 14:43:41 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-12-06 13:25Z, Vadim Zeitlin wrote:
GC> > On Sat, 06 Dec 2014 11:38:51 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> > Me> [...] whether you apply the above patch or not
GC> > GC> 
GC> > GC> I'm deliberately deferring it in order to focus on 'wx_test' for now.
GC> > 
GC> >  The trouble is that I risk having merge conflicts with this patch when I
GC> > do the other changes to the test (e.g. cleanup ones). I will, of course, 
be
GC> > able to resolve it -- using Git gives me confidence to perform merges I
GC> > would never dream of doing with svn, and this is by far not the worst of
GC> > them -- but it would be even better to not have to do it at all.
GC> 
GC> I feel certain that I recently read a message from you asking that a certain
GC> patch be applied soon to avoid conflicts later. I looked through numerous
GC> messages to try to find that one, but I couldn't find it. And I just now
GC> examined your 2014-11-30T01:04Z that started this thread, but that doesn't
GC> seem to be the one I was looking for. Or is it? Did I reexamine it too
GC> casually? Or is it a different message?

 It's a different message, namely this one:

        http://lists.nongnu.org/archive/html/lmi/2014-12/msg00014.html

GC> > GC> Kim and I have already reviewed several of the automated GUI tests, 
and
GC> > GC> I'm writing specifications that explain what we really want them to 
do.
GC> > GC> Soon I'll commit a modified 'wx_test_about_version.cpp' with a comment
GC> > GC> block indicating the desired behavior. It won't actually describe the 
code
GC> > GC> it precedes, yet; please take is as our request to change the code so 
that
GC> > GC> it does what the comment says.
GC> > 
GC> >  Working on it.
GC> 
GC> In the spirit of coordination...I don't think it's terribly important for
GC> you to prioritize this or any of (thirteen!) similar specification changes
GC> I'm drafting. If I can just get these comments-only changes committed, then
GC> you can address them when convenient. I think the changes they describe will
GC> be mostly confined to the single file in which each comment block occurs.

 I just wanted to do this one to test how this write-specification-comment-
first-then-update-the-code-to-match-it workflow would work. I'd still like
to finish with this one especially because I actually do have questions
about even this, probably simplest of all, test (which I will ask in the
new thread you started).

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

 No, this is a different issue. I prefer to post specifications here first
because I think they may need changing before being actually committed, not
because I'm afraid of conflicts. Another reason I dislike committing these
comments directly is because it's very confusing to have comments not
matching the code and while I fully understand that this is supposed to be
only temporary, I'd still prefer to avoid doing it completely.

 As for the conflicts, they could happen if I worked simultaneously on
these test-specific changes and also global changes such as tests cleanup.
But if I understood you correctly, it would be fine for me to finish the
pending global changes first, so I'll return to this after just finishing
the about dialog version patch in order to make sure we're both fine with
working on all the rest of tests like this.

VZ