I agree with this. Splitting the deprecation phan issues out to a separate
non-voting job sounds like a good idea (and should be easily supported by
phan with its issue whitelist/blacklist config directive)
Ideally we would have a phan plugin that generates warnings for hard
deprecations (wfDeprecated()), so that those could be voting.
--
brian
On Tuesday, December 19, 2017, James Hare <jamesmhare(a)gmail.com> wrote:
I’m not entirely familiar with how we use Phan, but if
it’s like the
other tests we run with Gerrit, what we could do is have a test for
deprecated APIs that passes or fails as you might expect, but have it be a
non-voting test. This way a failure is a signal to check something out, but
it doesn’t stop the build altogether.
> On Dec 19, 2017, at 10:01 AM, Stas Malyshev <smalyshev(a)wikimedia.org>
wrote:
Hi!
I've noticed a certain problem in our workflow that I'd like to discuss.
From time to time, we deprecate certain APIs in core or extensions. The
idea of deprecation is that we have gradual transition - existing code
keeps working, and we gradually switch to the new API over time, instead
of removing old API at one sweep and breaking all the existing code.
This is the theory, and it is solid.
Also, we have phan checks on the CI builds, which prevent us from using
deprecated APIs. Right now if phan detects deprecated API, it fails the
build.
Now, combining this produces a problem - if somebody deprecates an API
that I use anywhere in my extension (and some extensions can be rather
big and use a lot of different APIs), all patches to that extension
immediately have their builds broken - including all those patches that
have nothing to do with the changed API. Of course, the easy way is just
to add @suppress and phan shuts up - but that means, the deprecated
function is completely off the radar, and nobody probably would remember
to look at it again ever.
I see several issues here with this workflow:
1. Deprecation breaks unrelated patches, so I have no choice but to shut
it up if I want to continue my work.
2. It trains me that the reaction to phan issues should be to add
@suppress - which is the opposite of what we want to happen.
3. The process kind of violates the spirit of what deprecation is about
- existing code doesn't keep working without change, at least as far as
the build is concerned, and constantly @suppress-ing phan diminishes the
value of having those checks in the first place.
I am not sure what would be the best way to solve this, so I'd like to
hear some thoughts on this from people. Do you also think it is a
problem or it's just me? What would be the best way to improve it?
Thanks,
--
Stas Malyshev
smalyshev(a)wikimedia.org
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l