Hi Simon,
Simon McVittie wrote:
> Control: unblock 1006348 by -1
Thanks!
> #1007002 was marked as blocking #1006348 "lintian: Tag
> improbable-bug-number-in-closes condition considers 7-digit bug numbers
> improbable", but I think that was a side-effect of the merge
Definitely. All three unmerged bug reports had that block.
> and I don't consider #1007002 to be RC or a blocker for #1006348, so
> I'm removing that metadata.
Actually it was still on my TODO list to find out which of the bug
reports was related to #1006348 and why. You reduced that part of my
TODO list to 2/3 by no more having to check this bug report. Thanks!
:-)
> > Since at least I will not revert such huge changes, I'll tag #1007002
> > as "wontfix" for now and downgrade it to its original severity.
> >
> > We can continue working on that bug report if we find someone who
> > either will work on reverting all the related work (although I think,
> > it's both, too late and also probably way too much work given all the
> > other recent changes) or, probably much better, provide either a
> > migration script or some code which also accepts the old override
> > formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon,
> > I generally agree with #1007002, but we currently have way more severe
> > issues with Lintian than #1007002. Hence I also didn't remove the
> > confirmed tag.)
Oh, JFTR: This refers to Lintian as it was in Git when I took over.
There are parts of that tag format transition already committed in Git
which aren't yet in Debian Unstable. :-/ There were nearly 200 commits
in git since 2.114.0 before I started working again on Lintian. I
won't triage and revert them either unless they are outright buggy in
a technical sense. Sorry. As mentioned it would need much more man
power to "fix" this issue, even with what is so far only in git.
And with Felix and Chris left the Lintian development, there's much
less man power so far. At least so far I'm the only one who did
commits since then, but there were at least three DDs asking for group
membership on Salsa (Thanks!), so I hope they will start working on
Lintian as well. I'm also updating the development how-tos where I
notice that they're outdated.
> That makes sense to me. I should have reported #1007002 earlier
No offence meant.
> (or, ideally, a Lintian co-maintainer should have pointed out the
> problems with a major tag format transition before it got that far),
That's more a thing. Actually I already thought if we should setup a
similar rule for Lintian tag syntaxes as we did for using epoch in
package versions, maybe just not as stringent. I'm though not sure
where such a rule should be placed. The Debian Policy seems the wrong
place. So that rule should be probably documented inside Lintian
itself or so.
> which would have made pausing or reverting the transition
> lower-cost.
Ack.
> Thank you for picking up this package! It's an important QA tool and
> I'm glad someone is looking after it again.
Should have noticed the resignation of Felix and Chris (or looked for
such a thing after noticing that there were no lintian uploads for a
while) earlier, too. Probably would have been less (or at least more
distributed) work to get it back in shape as the remainder of Debian
Unstable didn't stand still while Lintian did.
Especially I found one case where the amount of lines replacing the
#DEBHELPER# token caused test suite failures after a debhelper update
seem to have added some lines. Took a few hours to understand what
went wrong and why. (Granted, because many things I knew about
Lintian's test suite had changed since I last used it, I first had to
relearn how to use the current setup and this took probably some of
that time as well.)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
