From: Stan Shebs <stanshebs@earthlink.net>
To: gdb-patches@sourceware.org
Subject: Re: [RFC] Merge mi-cli.exp and mi2-cli.exp
Date: Tue, 11 Sep 2012 21:53:00 -0000 [thread overview]
Message-ID: <504FB2D3.9030108@earthlink.net> (raw)
In-Reply-To: <504F5592.6000102@redhat.com>
On 9/11/12 8:15 AM, Pedro Alves wrote:
> On 09/05/2012 01:29 AM, Stan Shebs wrote:
>> On 9/3/12 2:08 AM, Vladimir Prus wrote:
>>> On 31.08.2012 17:29, Yao Qi wrote:
>>>> Unless I miss something, the intention of copying tests here is to test
>>>> both '-i=mi' and '-i=mi2' respectively. However, this duplicates the code,
>>>> and increase the effort to maintain, IMO.
>>> Yep, that was the intent -- with the extra twist that tests for MI and MI2 are not necessary
>>> identical. In other words, MI2 tests are tests for MI2 when MI2 was declared "done", and the
>>> idea was that the output with "-i=mi2" would remain the same for years. -i=mi is our current
>>> version of MI, which may evolve, and when MI3 is declared "done", the current tests will
>>> be copied to mi3-* tests to keep backward compatibility in future.
>>>
>>> I am not quite sure how relevant this plan is these days.
>>
>> That plan has pretty much fallen by the wayside. We should probably declare the current MI behavior as the "done" form of MI3, and disallow any incompatible changes. If someone wants to get ambitious, they are free to specify and implement MI4. :-)
> I agree the plan has fallen by the wayside, but because the introduction of MI3
> as a valid setting was premature and a mistake. MI2 is "done" in the sense that we
> will never change MI2's grammar and input/output in a backward incompatible way.
> We're free to add new output records, new commands, etc., but that isn't considered
> backward incompatible. That's all still layered on the same protocol.
>
> [...]
> But more than that, in reality, we stopped supporting MI1 almost 10 years ago:
>
> http://sourceware.org/ml/gdb-patches/2004-02/msg00352.html
That's a good point, seemed like it was just yesterday. :-) A little
poking around the net shows that it's been quite a while since anybody
has used MI1.
> So my opinion is that we revisit the policy a bit, and backtrack a the
> mi-.*exp vs mi2-.*exp idea, get rid of the duplication, and call everything
> "MI2", as it is in practice (must be, because that's how we run the tests).
> When we really introduce an incompatible change that actually justifies MI3,
> _then_ we should revisit the policy of whether to mass copying/rename tests, or
> share them, depending on how big the difference between the versions would be,
> and therefore depending on the practicality of the different options.
>
Sounds like a fine idea - and MI1 has already been deprecated for a long
time, so we can just whack things now. I'd also like to scrub the
comment references to what MI3 will do. While it makes sense for
comments to mention ideas for future work, it's misleading to imply that
we've committed our future selves to make any particular change on any
particular schedule.
Stan
stan@codesourcery.com
next prev parent reply other threads:[~2012-09-11 21:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 13:29 Yao Qi
2012-09-03 9:08 ` Vladimir Prus
2012-09-03 15:55 ` Yao Qi
2012-09-05 0:29 ` Stan Shebs
2012-09-10 20:09 ` Tom Tromey
2012-09-11 15:15 ` Pedro Alves
2012-09-11 21:53 ` Stan Shebs [this message]
2012-09-12 15:28 ` Pedro Alves
2012-09-12 13:59 ` Yao Qi
2012-09-19 11:22 ` Yao Qi
2012-09-19 13:47 ` Pedro Alves
2012-09-21 8:40 ` Yao Qi
2012-09-28 0:04 ` [PATCH 0/11] Cleanup MI test cases Yao Qi
2012-09-28 0:04 ` [PATCH 05/11] mi-pthreads.exp Yao Qi
2012-09-28 0:04 ` [PATCH 02/11] mi-var-block.exp Yao Qi
2012-09-28 0:05 ` [PATCH 11/11] mi-syn-frame.exp Yao Qi
2012-09-28 0:05 ` [PATCH 06/11] mi-break.exp Yao Qi
2012-09-28 0:05 ` [PATCH 01/11] Remove mi-FOO.exp which are identical to mi2-FOO.exp Yao Qi
2012-09-28 0:05 ` [PATCH 09/11] mi-console.exp Yao Qi
2012-09-28 0:05 ` [PATCH 08/11] mi-var-display.exp Yao Qi
2012-09-28 0:05 ` [PATCH 03/11] mi-file.exp Yao Qi
2012-09-28 0:05 ` [PATCH 04/11] mi-basics.exp Yao Qi
2012-09-28 0:05 ` [PATCH 10/11] mi-stack.exp Yao Qi
2012-09-28 0:05 ` [PATCH 07/11] mi-var-cmd.exp Yao Qi
2012-09-28 19:36 ` [PATCH 0/11] Cleanup MI test cases Pedro Alves
2012-10-12 9:47 ` Yao Qi
2012-10-12 10:05 ` Pedro Alves
2012-10-14 12:25 ` [committed] : " Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=504FB2D3.9030108@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox