On Mon, May 04, 2020 at 10:58:03PM -0000, Chris Lamb wrote:
> It was sad to read that you do not consider that Lintian itself could
> be updated to prevent all of these wasted brain cycles on a question
> that you have seen raised multiple times.
I consider that, and I think I tried to contribute in a bunch of similar
discussions in the past, as well as filing reports whenever I thought
there were possible improvements around.
I'm just somewhat bothered because it feels that recent times (...
1/2/3 years maybe?) it started to be much more common for me to find
unactionable or inapplicable tags, even if they could later be "tuned
down" in a subsequent update.
> Once a tag has been added we can always refine, replace or remove it
> and the maintainers of Lintian have done so on a number of occasions
> once they were made aware of it.
What I'm getting at, is that as soon as a tag is added, it will
immediately affects at least dozens but most likely hundreds of people
in likely a single day, and if it stays around more than a day it'll
soon touch the thousands.
I'm convinced that tag additions should be pondered much more before
adding them, rather than considering that they will be improved further
on. By the time somebody is annoyed enough to file a bug (because,
after all, a person will ponder if it's easier to just ignore something
rather than writing a report about it) it will have already caused
enough lost brain cycles.
> This is even more of an unfortunate stance to take given that a simple
> one-line improvement (such as to not emit this new tag in the case of
> backporting) would appear to be sufficient.
That is simply not true for this particular case: the problem of this
tag is that it is emitted *for unstable* builds. It doesn't make sense
for it to be hidden during backports, as by then its "harm" will be
already done when the developer removed the --as-needed flag during the
unstable upload. You'd have to know if that particular package *will
be* *in the future* backported, to understand whether it's appropriate
or not to drop that flag.
> It is regrettable that so many Debian Developers hold such pessimistic
> and fatalistic views regarding change in our project. Our collective
> sense of fulfilment and enjoyment would no doubt improve if we were to
> take small steps in reframing how we view these matters of this nature.
I'm sure you know that I hold anything but fatalistic views when
thinking of changes within the Project :) Just know that I'm regularly
amongst the first to bump the debhelper compat level, and I've been
asked by multiple parties multiple time to wait before doing so!
But, however fast you want to change something, I agree proper and
careful steps always need to be taken.
In this particular case, there is not improvement whatsoever in removing
that flag, except removing possible cruft from d/rules. Surely that
cruft can stay there another year or two, when opposed to the risk of
overlinking binaries and accidentally creating possibly heavy
dependencies in stable systems (because that's where backports are).
In other cases, there is a need to balance the view of thousands of
maintainers and their needs.
In this, my personal thought is that you, not you lamby but the Lintian
maintainers as a whole, need to take more care about what you are
including within the lintian checks, because whilst it's true that
anything can be better tuned later after the release, as the end user of
the tool being repeatedly irked by overzealous tags that need to be
first ignored for a while, then reported, discussed and finally
days/weeks later see in production can easily turn tiresome.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature