Helmut Grohne writes ("Re: copyright precision"):
> On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote:
> > So if there is a problem, shouldn't we start to solve it instead of just
> > ignoring it? Wouldn't it be better to set high standards instead of being
> > guided by convenience?
>
> Documenting problems only makes sense when there is a realistic chance
> to get them fixed. If we end up letting them linger, the effort of
> reporting them is wasted.
Indeed.
> I'm not meaning to imply that we shouldn't fix this. I'm just seeing
> that few people are interested in actually doing what needs doing.
It seems like a lot of work. And indeed, speaking personally:
I would fix any such bug in any package I had responsibility for, and
I might indeed fix any such bug in a package I wanted to do some
nontrivial work on.
But I have no desire to do the necessary legwork to go through the
whole archive to fix this kind of thing.
> Instead of seeing higher standards being applied, I'd like to see better
> tools that support meeting those standards. If generating augmented
> copyright files for binary packages is the way to go, there should be a
> standard, debhelper-supported way of doing so.
Absolutely.
> Thus far I see neither consensus, nor people driving improved copyright
> documentation. Instead I see Andreas' work being blocked[1] based on
> rules that aren't met by the rest of the archive either. And that's sad.
I agree.
Personally, although I am (as I say) dismayed at the poor state of our
archive, things have (apparently) been like this for years and nothing
terrible has come of it. So I don't feel I now say that we should
suddenly start imposing a strict policy.
It is unfair to new packages to give old ones a free pass. Some kind
of flexibility is perhaps justifiable, but at the very least if we are
going to block new packages, we need a recognition that the old
packages are also broken and a time-bounded decision to fix or remove
them.
We also have a problem that our decisionmaking process is not
working well. I think that the right political process is:
ftpmaster and the release team should clearly tell us all whether bugs
of this kind are release critical, and/or reject/removal-worthy.
If they are determined to be RC or reject/removal-worthy, then we
should immediately file bugs of the appropriate severity of all the
popular packages that people in this thread have used as examples.
If the bugs are not determined to be RC or reject/removal-worthy, then
these issues seem to me to still be bugs. If someone has the effort
to improve our tooling, and improve packages, their patches should be
accepted.
Ian.
