[PATCH 2 of 2 RFC] dispatch: try and identify third-party extensions as sources of tracebacks

[Matt Mackall]

On Mon, 2011-07-25 at 21:55 -0500, Augie Fackler wrote:
> # HG changeset patch
> # User Augie Fackler <durin42 at gmail.com>
> # Date 1311622871 18000
> # Node ID 245f5bbe00788d00ed4e6d6bd27a22c5163365f1
> # Parent  e59468fa239985828ce199d3ae8cb1768987525c
> dispatch: try and identify third-party extensions as sources of tracebacks

For anyone who's missed the discussion surrounding this, the basic idea
is that every extension has a list like this:

testedwith = ['1.8', '1.9', '2.0']

and extensions.py has:

apiver = '2.0'

When a traceback happens, we check each extensions to see if:

a) it appears in the traceback
b) apiver doesn't appear in its testedwith list

..and then point the finger of blame at it.

We had some more discussion about this on IRC, I want to try to clarify
the use-cases I care about.

1)

User has Mercurial 2.0 and hg-foo last updated for 1.9. hg-foo triggers
breakage. We'd like to find hg-foo in the traceback and let the user
know it's not been tested with Mercurial 2.0.

This case is pretty straightforward and is the bulk of our current
issues in this area.

2)

Tester has a _pre-release_ version of Mercurial 2.0 and hg-foo last
updated for 1.9. They're testing during the 2.0 code freeze call for
testing and the internal API is effectively locked down. Again, we want
them to get pointed to hg-foo for support, and hopefully trigger hg-foo
to make sure they're release-ready before the release date.

I think it's important this this happens. We want to get to a point
where we have sufficient pre-release testing that post-release users
will in fact be able to download working updates.

3)

User has a default branch checkout of Mercurial post-1.9 and hg-foo last
updated for 1.9. The internal API may change one or more times between
now and the release. Ideally we'd like hg-foo devs to get an early
heads-up that things have changed so they don't have to scramble during
the code freeze.


So at some point, we need to say "this is the 2.0 API". The problem is
case 3: if we mark the API as "2.0" on the default branch when we
release 1.9, hg foo might only update once after that and we might get
false negatives in case (2). If we wait until the freeze to mark the
API, we may instead get false negatives in case (3) and lose the
opportunity to update the extension early.

-- 
Mathematics is the supreme nostalgia of our time.