Bug#459427: Patch seeking seconds on changelog vs. NEWS handling
Sean Whitton wrote:
> On Wed 25 Jul 2018 at 07:01PM -0700, Jonathan Nieder wrote:
>> I share gregor's discomfort: I don't think we've thought this through.
>
> I too want Policy to be as correct as possible, but this bug has been
> open for ten years and one thing upon which there is certainly consensus
> is that the current text is not satisfactory. We should not let the
> perfect be the enemy of the good, at least in this case.
*puzzled* I am not asking for Policy to be more correct. I'm asking
for it to provide guidance that can help me with my own packages.
I'm providing the data point that for me, the proposed patch to this bug
does not work at all. It is way too restrictive, and the argument being
presented in favor of it is that I am allowed to ignore it. This
isn't about the perfect being the enemy of the good. This is about
wanting Policy to help me at all.
Your response also feels dismissive. I've tried to be very concrete
in the input I provide here and I am wondering if this is appreciated
at all or if you consider my contributions to be a nuisance.
>> Can you summarize the goals for me?
>
> 1. Stop encouraging the installation of changelogs, which sometimes has
> the effect of causing our package maintainers to request such logs
> from upstream. This is not a good use of anyone's time.
In that case, why don't we remove the requirement altogether?
That would be a simple change, and it would achieve the goal, if that
is our main goal.
> 2. Explicitly encourage installing release notes and have a sensible
> filename for them.
I don't see a need for policy to do the first of those two things.
Packagers already install release notes when available, without
requiring any nudge from policy.
As for a sensible filename, I don't see this conversation having
developed toward any consensus (unless changelog.gz is that filename).
[...]
>> 4. Some licenses require distributing source-level changelogs.
>
> Could you give me an example of such a license, please?
The GPL contains the following:
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the terms of
section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
[...]
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also [...]
If Debian modifies a package, we comply with this prominent notice
requirement using the Debian changelog. If the immediate upstream of
Debian modifies a package, then we ought to indicate when the
immediate upstream has modified the code, and the upstream changelog
accomplishes that.
This isn't too unusual. The Apache license also contains a similar
provision about indicating that files have been modified, for example.
[...]
>> ii. We don't impose any requirement on filename other than that they
>> go in /usr/share/doc/<package>/.
>
> I disagree.
>
> It is useful to be able to just type `zless
> /usr/share/doc/foo/known-filename` rather than having to look at the
> filenames and guess what they are.
How do you do that on existing packages? This bug was opened because
there isn't a consistent practice.
>> iii. We come up with what format requirements we want to impose on
>> the changelogs, if any.
>
> This is far out of scope for this bug.
If we set the filename and want people to type zless, then we are
imposing a format requirement (gzip).
Hope that helps,
Jonathan
Reply to: