Re: [lmi] wx update; pending specification changes

[Greg Chicares]

On 2014-12-06 14:53Z, Vadim Zeitlin wrote:
> 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> I feel certain that I recently read a message from you asking that a 
> certain
> GC> patch be applied soon to avoid conflicts later.
[...]
>  It's a different message, namely this one:
> 
>       http://lists.nongnu.org/archive/html/lmi/2014-12/msg00014.html

Okay, I'll do that next.

> GC> > GC> Soon I'll commit a modified 'wx_test_about_version.cpp' with a 
> comment
> GC> > GC> block indicating the desired behavior.
[...]
> 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
[...]
>  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).

Okay, this is all good.

> 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 BDFL I try not to issue ukases too often, yet I'm really feeling quite
adamant about committing these specification changes into the files to
to which they pertain. If they require revision, that's on me. Let me
offer to add a prominent comment after each block such as
    /// BEWARE! The documentation above describes changes that have
    /// not yet been made to the code!
which will not be removed without your permission. Alternatively, or in
addition, we could have a block that says something like
    /// Not yet implemented:
    ///   [e.g.:] this test is not yet conditioned on the command-line
    ///   '--distribution' option because that option hasn't been coded.

>  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.

Agreed.