"3.1.4. Coordination with upstream developers" says

"You have to forward these bug reports to the upstream developers so that they
can be fixed in a future upstream release."

That's not the current/best practice for a number of packages, either because
of the sheer volume of bug reports/size of the package or because some of the
bugs are very specific to the reporters setup and having the Debian maintainer
as a middle person forwarding information back and forth would be useless
(e.g. for the Linux kernel where a lot of bug reports are hardware-specific).

The current formulation will cause false expections for end users.

Maybe alternatively make this

"You can either forward these bug reports to the upstream developers yourself
or ask the reporter to report them upstream, so that they can be fixed in a
future upstream release."

Cheers,
        Moritz

I respectfully disagree.

In just as many cases, the middle person is necessary, because it’s
a burden to the end user (and often enough virtually impossible) to

• register an account on 10'000 upstream bugtrackers, with 30 different
  kinds of bug tracking systems (if any), themselves (one for each pak‐
  kage they use)

  ‣ finding the tracker in the first place

  ‣ reporting it in the correct tracker, against the correct
    component, in the correct format, etc.

• keep track of the state of these bugs (we have debbugs with a sub‐
  scription interface as a single consistent interface for a reason)

• respond to back-questions from upstream (which version, compile
  options, why did you patch X, etc)

  ‣ deal with upstreams not interested in bugreports for anything stable

• tell upstream convincingly enough that no, you can’t just build
  and use their git master

  ‣ (the real package maintainers could pick the proposed fix and
    put it in experimental, though, or prepare, if necessary, a
    special build for the reporter to test back)

• well, build the proposed fix for testing

• reproduce the bug with older (think oldstable-security) or newer
  (think sid, for a stable user) versions

• keep track of whatever upstream versions and whatever Debian
  versions carry the fix (those can differ quite a lot)

• be able to judge whether it’s a security-relevant problem

• speak upstream’s language (both programming and human) well
  enough for both sides to understand stuff

• etc.

Furthermore, it’s considered nice to upstream to filter out
Debian-specific bugs instead.

One could even argue with Social Contract §4 here, but I’m
not going quite as far.

Yes, I’ve also been guilty of asking users to report things
upstream as they aren’t packaging-specific. (I’d still move
or copy them upstream if the reporter is unable or unwilling.)
However, I *still* think the language of DevRef should be
*strongly* urging DDs (and other package maintainers) towards
being a bidirectional bug report gateway, at least for real
problems (I can understand being annoyed with upstream feature
requests).

Yes, that doesn’t scale when you maintain “a lot of” packages.
However, it *is* something you have signed up for when you
started maintaining your first package. Perhaps you should
look for help (bug triage and forwarding could even be done,
in part, by less involved people).

I also think that upstreams, conversely, should have an eye
on packaging bugtrackers, but that can explode quickly… I’m
trying for mine (Debian, CentOS/RedHat, Gentoo, Arch seems
to be a manageable subset, and I pick up weird ones like Void
on the occasion).

So, perhaps upstream can help those “a lot of” maintainers, too.

This also means that there should be a good relationship
between the package maintainers and upstreams. In those,
it’s easier to deal with bugreports than when someone
totally unknown goes to upstream and reports a bug (“uh,
a clueless end user… meh, let’s ignore it”). It’s basically
the *definition* of a distribution and its maintainers to
coordinate between upstreams, other packages and distro-wide
policies, and users and other downstreams. It’s your *job*!

I’m trying to be constructive here, but in the end, I still
think that this was something package maintainers (at least
DDs) have read beforehand and signed up for, so there’s no
room to complain now, and I strongly believe that the current
wording should either not be changed at all, or changed in a
way that still strongly supports users unable (by lack of
knowledge, skills, or just time) to report directly upstream.

Thanks for having read till the end,
//mirabilos

Good. Please subscribe to the PTS, I take that as an offer
by you to take care of forwarding Debian kernel bugs to upstream.

Cheers,
        Moritz

I would like something stronger.

To me, the core message of the current text is that you should ensure
that bug reports which are not Debian-specific end up with upstream,
*somehow*, whether by the maintainers forwarding it to upstream
themselves or by them asking the reporter to do so. Your proposed new
text weakens that, and I think that's not a good idea.

I agree that it's perfectly fine for a maintainer to say "this is an
upstream bug, please report it upstream", which the current text doesn't
allow for. Having said that, I *don't* think it's fine for a maintainer
to say "never ever report upstream bugs for this package to Debian"; for
someone not familiar with the software in question, determining whether
something is a Debian-specific bug or an upstream one is not always
possible.

While we're at it, I think we should also point out that if upstream
uses an issue tracker that is supported by bts-link, it might be nice to
keep upstream bug reports that were filed in the Debian bts open, but
mark them as forwarded to the correct URL so that bts-link will tag them
"fixed-upstream" when relevant. That should probably not be a
requirement though.

I would like something stronger.

To me, the core message of the current text is that you should ensure
that bug reports which are not Debian-specific end up with upstream,
*somehow*, whether by the maintainers forwarding it to upstream
themselves or by them asking the reporter to do so. Your proposed new
text weakens that, and I think that's not a good idea.

I agree that it's perfectly fine for a maintainer to say "this is an
upstream bug, please report it upstream", which the current text doesn't
allow for. Having said that, I *don't* think it's fine for a maintainer
to say "never ever report upstream bugs for this package to Debian"; for
someone not familiar with the software in question, determining whether
something is a Debian-specific bug or an upstream one is not always
possible.

While we're at it, I think we should also point out that if upstream
uses an issue tracker that is supported by bts-link, it might be nice to
keep upstream bug reports that were filed in the Debian bts open, but
mark them as forwarded to the correct URL so that bts-link will tag them
"fixed-upstream" when relevant. That should probably not be a
requirement though.

Hello Moritz,

you seem to be deliberately misunderstanding me.

I’m not a maintainer of the Debian Linux kernel. I exhibit
a few of the things I mentioned, such as, not being know‐
ledgeable enough about the stuff. In this instance, I’m the
user / bug reporter.

Not “all DDs must forward bugs about *all* packages to *all*
upstreams”, but “package maintainers must forward bugs about
*their* packages (and perhaps others, if interested and capable)
to those upstreams”.

I try to do so for my packages and a couple others (I’d even
be more involved in klibc if upstream and maks weren’t such
a wall of silence).

bye,
//mirabilos

+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Hi Wouter,

In theory, I could agree to that, were it not for a number of
points I outlined earlier:

• the variety of upstream bug trackers and having to register
  an account with each of them

• the problems dealing with upstream reactions (questions,
  patches, etc.) especially for less technical users (or
  merely these not knowledgeable about that particular
  package’s internals)

• the lack of familiarity between upstream and distro end user

Now that I write it again, there’s another point:

• the package maintainers not being involved in the discussion
  (dangerous if e.g. upstream suggests a fix that won’t work
  in the distro for some reason, and the end user not knowing
  about that, and them agreeing to that fix)

I’m still convinced that package maintainers should at least
forward patches from end users and keep an eye on them, and
that, if/when it’s okay to ask the end user to report upstream
themselves, they help whenever needed and perhaps also keep an
eye on the upstream bugs.

bye,
//mirabilos

Thorsten Glaser writes ("Bug#908155: Coordination with upstream developers not universally applied"):

I think it is usually better if the Debian maintainer can do this.
I would like to encourage maintainers do do it.  But I really don't
think we can make this mandatory.

Ian.

Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers not universally applied"):

How about this

   These bug reports should be forwarded to the upstream developers so
   that they can be fixed in a future upstream release.  Usually it is
   best if you can do this, but alternatively, you may ask the bug
   submitter to do it.

?

Ian.

Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers not universally applied"):

How about this

   These bug reports should be forwarded to the upstream developers so
   that they can be fixed in a future upstream release.  Usually it is
   best if you can do this, but alternatively, you may ask the bug
   submitter to do it.

?

Ian.

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers not universally applied"):
something.  Package maintainers "should" fix all bugs in their
packages.

But we have limited effort.  It is better to have a package in Debian,
but where users have to do some more of the work, than no package.

Or to put it another way: if you see something that "should" be done,
but which is not being done, why are you not volunteering to do it ?
Or are you saying that maintainers should step down and orphan the
package instead ?

Ian.

LGTM.

Cheers,
        Moritz

LGTM.

Cheers,
        Moritz

Uhm… it’s been mandatory the last couple of years.

Good point.

As I wrote in <alpine.DEB.2.21.1809071504120.5896@tglase.lan.tarent.de>
I don’t think it’s sensible to _forbid_ maintainers to ask users to
report upstream. My concerns is more about cases in which that is
a big burden on the users. Tons of bug trackers come to mind, or being
unskilled in the interna of a particular package.

As long as it’s a “should” in the same sense as “should fix bugs in
their packages”, and package maintainers keep an eye on users’ bug
reports and, when necessary, help them (providing infos to upstream,
packages to test to users who can’t (easily) build themselves, and,
yes, definitely *also* forward bugs upstream, occasionally.

Does this sound like an option?

bye,
//mirabilos

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers not universally applied"):

In some packages this will not be possible at least for some bug
reports.  You've seen the poor quality and hard-to-follow-up bug
reports that some packages get in large numbers.  And it is precisely
the bug reporters who would need the most help to deal with upstream,
where doing the work for them is the most difficult.

We will just have to accept that not all bug reports will be properly
investigated.  We should focus our effort on the bug reports that are
most likely to lead to improvements in the software, given available
levels of effort.  And we should therefore not write things in our
documents that discourage maintainers from prioritising appropriately.


I get the impression that you are looking at this from the point of
view of the user, who wants their bug fixed, and is perhaps not able
or willing to report it upstream.  Such a user does have a problem,
and when one is such a user, it is frustrating.

But, the main point of bug reports, from Debian's point of view, is
not to help users.  As the Information for GNU maintainers has it:

  The main purpose of bug reports is to help you contribute to the
  community by improving the next version of the program. Many of the
  people who report bugs don't realize this - they think that the
  point is for you to help them individually.  Some will ask you to
  focus on that instead of on making the program better.  If you
  comply with their wishes, you will have been distracted from the job
  of maintaining the program.

This means that many users will go un-helped.  That is, sadly,
inevitable.  We in Debian cannot possibly be the support desk for all
our users.  The more successful we become, the less possible that is.

Our responsibility is to enable others, nearer the users, to help
them, by making our software Free and accessible, by providing
appropriate documentation, by (scaleable) outreach activities, and so
on.


What did you think of the text I proposed just over <- there, that
Moritz was happy with ?

Ian.

Short answer (slightly drunk and short on time), more later:
[…]

Yes, but that does not mean we should make it permitted by the rules
to slack in that “duty”.

A “should” may be violated within reason, so keep it that.
Not commenting on the text in between for now.

Just answering because of this: I think it way too lax still.

bye,
//mirabilos

An arguably small point, but the Developer's Reference is explicitly
*not* "the rules".

Its own scope statement makes this clear:

<quote>
Furthermore, this document is not an expression of formal policy. It
contains documentation for the Debian system and generally agreed-upon
best practices. Thus, it is not what is called a ``normative''
document.
</quote>

Regards,

Adam

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers not universally applied"):

I find this rhetoric, that overwhelmed maintainers who are not able to
deal individually with every bug report, are "slacking" in their
"duty", quite objectionable, I'm afraid.

You should perhaps propose a countertext, but given what you say above
I doubt it would find consensus.

Ian.

I think that's better, yes.

It doesn't incorporate my other suggestion about bts-link, though. How about this:

   In cases where a bug report is forwarded upstream, it may be helpful
   to remember that the bts-link service can help with synchronizing
   states between the upstream bug tracker and the Debian one.

?

I think that's better, yes.

It doesn't incorporate my other suggestion about bts-link, though. How about this:

   In cases where a bug report is forwarded upstream, it may be helpful
   to remember that the bts-link service can help with synchronizing
   states between the upstream bug tracker and the Debian one.

?

Hello,

Bug #908155 in developers-reference reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/developers-reference/commit/65fd955090f0a69e28bd2a9eb98992ebbc553861
------------------------------------------------------------------------
developer-duties.dbk: improve paragraph about coordinating with upstreams. Closes: #908155.

Signed-off-by: Holger Levsen <holger@layer-acht.org>
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908155

We believe that the bug you reported is fixed in the latest version of
developers-reference, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 908155@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Holger Levsen <holger@debian.org> (supplier of updated developers-reference package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 17 Feb 2019 13:44:03 +0100
Source: developers-reference
Architecture: source
Version: 3.4.23
Distribution: unstable
Urgency: medium
Maintainer: Developers Reference Maintainers <debian-policy@lists.debian.org>
Changed-By: Holger Levsen <holger@debian.org>
Closes: 376590 430889 483232 494470 775740 817914 839885 855320 908155
Changes:
 developers-reference (3.4.23) unstable; urgency=medium
 .
   [ Holger Wansing ]
   * Globally change "new maintainer" into "new member". Closes: #817914.
 .
   [ Holger Levsen ]
   * scope.dbk: extend: s#Debian developers#Debian developers and maintainers#
   * tools.dbk:
     - stop recommending remote signing of packages, especially using debrsign.
       Closes: #855320. Thanks to Daniel Kahn Gillmor.
     - slightly reword existing paragraph about dch and debchange.
       Closes: #494470.
   * best-pkging-practices.dbk: add another example of a multi binary source
     package. Closes: #430889.
   * l10n.dbk: drop paragraph about Debian specific manpages maintained in cvs.
   * developer-duties.dbk: improve paragraph about coordinating with upstreams.
     Closes: #908155. Thanks to Ian Jackson and Wouter Verhelst for the
     wording.
   * pkgs.dbk:
     - clarify the recipients of 123-submitter@b.d.o. Closes: #775740.
       Thanks to Josch Schauer for the wording.
     - don't suggest to test downgrading packages. Closes: #376590.
       Thanks to Justin Pryzby.
     - add a paragraph to the section about reintroducing packages to check and
       update the security tracker metadata. Closes: #839885.
       Thanks to Paul Wise.
   * beyond-pkging.dbk: mention mass-bugs for reporting bugs against many
     packages. Closes: #483232. Thanks to Sandro Tosi for the suggestion.
   * common.ent:
     - drop url-cvsweb.
     - switch five http urls to https, leaving one http url.
   * d/control: mark all binary packages as multiarch: foreign.
   * Update po4a/po/developers-reference.pot and po4a/po/*.po for the new and
     changed strings.
   * README.contributing:
     - renamed from README-contrib.
     - update instructions how to update .po files.
   * d/TODO: remove some ancient entries and clarify that only the BTS should
     be used in the long term.
Checksums-Sha1:
 dba327e74fe2ec51e98c6bf7a72c4c8ed742a78a 2398 developers-reference_3.4.23.dsc
 b83a10cf5cb15bd841e2d8bcb2787d286f85199c 671300 developers-reference_3.4.23.tar.xz
 4962327916996a353f4efcd7cad927c31c02fdd6 5187 developers-reference_3.4.23_source.buildinfo
Checksums-Sha256:
 b88ea3b436d735fdaaf022c9c26c099f374f2bcf9dd89db6a2813ddfd76ce90f 2398 developers-reference_3.4.23.dsc
 9abe6d60c2975bcf7cd25e930d6d0f1b0f6d150a41f41d09d3cd36115dde2477 671300 developers-reference_3.4.23.tar.xz
 013c4eccc6a890552db717cd51cd555de56705dbede2c78644f821b86db14bc1 5187 developers-reference_3.4.23_source.buildinfo
Files:
 8c01664a739cc087e8f72d5aa3d394ef 2398 doc optional developers-reference_3.4.23.dsc
 fb58bbc7005b1138a860805fdb8e76da 671300 doc optional developers-reference_3.4.23.tar.xz
 136e8bd2cdf29eeb8cae33094c999338 5187 doc optional developers-reference_3.4.23_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAlxpW1UACgkQCRq4Vgaa
qhwoOw/8C5bb4KxQuciKRuTJIQ4ns4H76V8UFHJafR8iVym/iXIgm2xf9XRaHrz1
psRIZVroGJiyDjLy7ZaFaePgsod/aLAlGeerx2hEH1niWJDj0lItR+6UcCvDJuV+
mpWb/3565dbb78n5C/lhgg2E7D2AqGq4WcUHU8UxGH67+/oetG0yo0WJ/SMdcB6E
scHXk53byImiridkPiOnCtKlHb+UMy0/Llm7MZX9/tSTj+mASo3fjy/LGoaQpzFk
hdxKr+hAumAxbzTD8ohyi7dPq9fe5zNvMJ6eVgO46SNnYDwXGFTxC5yia/58m3Vm
ky1e2fY7vdPEdABTXlVp+2FJ0jacjIBljdkm2C+d0571ZgjADBZ128u3D6t2xw7g
hMzGNnOD7glqZyz/Nq1H4srMWNhTQf3q9D8cFdmIYfHW+7bmrGvqvL6PblghKCJg
ntX4t23utp/tOWI8SiaPyKjrH2ZuK/ibJ1/X836/I+b6Js4jVaU9haLyPS2J9kMy
FO8slTAtqir7CU5CDcDf7jJ8VuFpJ0lkys7NS0L5bH0eEkrvd0yP3GVq0zoM73Ib
k02QETc/TRzqIjlPeMpn9zIwWV7SgWDNLCxYO8lOksHaSWv4Yt0nEcd3eDhYp5G+
OFuU8acYQiMhwpht8pDTXSMFoqdTUNzaj90FqzbXHyuU/m3Df1Q=
=l6/N
-----END PGP SIGNATURE-----

There seems to have been a regression, maybe this got lost in the Sphinx conversion?

The current version in unstable (11.0.10) again reads:

| If it's an upstream problem, you have to forward it to the upstream author.
| Forwarding a bug is not enough, you have to check at each release if the
| bug has been fixed or not.

Cheers,
        Moritz

Hi Moritz,

where exactly do you see this? I don't see it on https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#coordination-with-upstream-developers
nor in source/developer-duties.rst in the source git repo.

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of
their very eyes...

tags 908155 + patch
thanks,

hi,

here's a patch for #908155, which (given the textual overlap) also includes the
(previously sent) patch for #757274.

wrt #908155:

- Ian's proposed wording about forwarding upstream issues and Wouter's about
  bts-link have both been included under "Coordination with upstream developers"
  as of 3.4.23
- the proposed patch removes the "regression" pointed out by Moritz (under "Bug
  housekeeping"; might already have been there, rather than having been
  introduced by 3.4.23), in favor of guidance in "Coordination with upstream
  developers"

thanks,
serafi

version: 14.7