Debian Bug report logs - #681833
developers-reference: please document a package salvaging process

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 18:35:33 -0400

package: developers-reference
severity: normal
version: 3.4.8
tag: patch

Hi,

I've prepared an initial draft of a developers reference patch that
would document a package salvaging process.  Please see below.

Best wishes,
Mike

--- pkgs.dbk.orig	2012-07-16 18:19:56.065047490 -0400
+++ pkgs.dbk	2012-07-16 18:32:20.626439544 -0400
@@ -2257,6 +2257,86 @@

 </section>

+<section id="package-salvaging">
+<title>Package Salvaging</title>
+
+<para>
+Unfortunately over time, certain maintainers become less active without turning
+over their packages via the orphaning process or fully leaving the project.
+This is a natural process, and there is nothing wrong with it, but in the
+meantime their packages suffer bit-rot and bug reports go unanswered.
+Fortunately the NMU process provides a means to inject much needed health into
+these neglected packages.  This is the liberal NMU.
+</para>
+
+<para>
+Also, at times, there can be situations where contributors would like to modify
+a package for a lower severity bug report, but said bug is ignored for a long
+time by an active maintainer.  If the fix is good, it should certainly go into
+the archive.  This is another case where an NMU is appropriate, but it would
+not be considered a liberal NMU.  These cases can be resolved by are a standard
+10-day NMU, and conflicts can be refered to the technical committee as a
+technical dispute.
+</para>
+
+<para>
+Ideally, the liberal NMU is done by uploading the package of interest to the
+DELAYED/10 queue or greater.
+</para>
+
+<para>
+The liberal NMU is also appropriate in general for fixing bugs, but
for packages
+that have not recieved an upload in greater than six months liberal NMUs are
+highly encouraged and can fix issues that are not tracked in the BTS.  Changing
+the build system in a Liberal NMU is still not acceptable, but all
other changes
+are allowed including packages of new upstream versions.
+</para>
+
+<para>
+A mail for each Liberal NMU should be sent to either the maintainer or the BTS
+(which is automatically forwarded to the maintainer) and should include a
+hyperlink to a VCS containing the changeset of this liberal NMU and all of your
+prior liberal NMUs to this package.  A VCS link is preferred to
+an NMU patch in these cases since long-term if the maintainer does not
+resume activity, you will be making many liberal NMUs and ultimately becoming
+its maintainer.  The message body should maintain a positive
+attitude and mention that the maintainer may review and has the option to
+cancel the NMU while it waits in the upload queue for the next 10 or more days.
+</para>
+
+<para>
+Unfortunately the maintainer may reject some of your contributions that you
+disagree with.  In this case, try to find a way to implement the changes in a
+way that the maintain will approve.  Failing that, please refer the matter as a
+technical disagreement to the technical committee.
+</para>
+
+<para>
+Preferably, after you have demonstrated that you can handle the package, the
+maintainer will either step down or approve you to be a part of the packaging
+team.  If the maintainer has been active or not approved this after an
+additional six months after your first liberal NMU, you may petition the tech
+committee to rule on the maintainership of the package.  Please include as much
+information as possible (including bug reports, uploaded versions, VCS links,
+etc.) to make the committee's decision easy.  If the maintainer at some point
+becomes active, and does not want your participation to continue, you may
+petition either accept that request and step down or petition the tech
+committee to rule on the matter.
+</para>
+
+<para>
+If a package has been already been orphaned, you may salvage it without any
+kind of approval.
+</para>
+
+<para>
+Filing a removal request against ftp.debian.org, then reintroducing the package
+with yourself as the maintainer is considered adversarial and is explicitly
+disallowed.
+</para>
+
+</section>
+
 </section>

 <section id="collaborative-maint">

Message #8 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@debian.org>

To: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Tue, 17 Jul 2012 00:55:12 +0200

* Michael Gilbert <mgilbert@debian.org>, 2012-07-16, 18:35:
>+<para>
>+If a package has been already been orphaned, you may salvage it without any
>+kind of approval.
>+</para>
>+
>+<para>
>+Filing a removal request against ftp.debian.org, then reintroducing the package
>+with yourself as the maintainer is considered adversarial and is explicitly
>+disallowed.
>+</para>

Is orphaning the package and then uploading it with maintainer set as 
yourself okay or is it "considered adversarial and is explicitly 
disallowed"?

-- 
Jakub Wilk

Message #13 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 20:35:35 -0400

On Mon, Jul 16, 2012 at 6:55 PM, Jakub Wilk wrote:
> * Michael Gilbert, 2012-07-16, 18:35:
>
>> +<para>
>> +If a package has been already been orphaned, you may salvage it without
>> any
>> +kind of approval.
>> +</para>
>> +
>> +<para>
>> +Filing a removal request against ftp.debian.org, then reintroducing the
>> package
>> +with yourself as the maintainer is considered adversarial and is
>> explicitly
>> +disallowed.
>> +</para>
>
>
> Is orphaning the package and then uploading it with maintainer set as
> yourself okay or is it "considered adversarial and is explicitly
> disallowed"?

Interesting condition.  According to Developers Reference 5.9.4,
orphaning is a process that is only supposed to be initiated by the
existing maintainer.

So yes, that would also be disallowed.  Since you are not yet the
maintainer, you cannot orphan the package in order to become the
maintainer.

I would probably go ahead and merge the removal and orphaning
statements together as a change to the above patch.

Best wishes,
Mike

Message #18 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 20:57:31 -0400

As a reminder to myself if these changes were to gain traction,
section 5.9.5 (adopting a package) will also need some rewriting since
certain instructions overlap salvaging.

Best wishes,
Mike

Message #23 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Michael Gilbert <mgilbert@debian.org>

Cc: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 18:37:22 -0700

Michael Gilbert <mgilbert@debian.org> writes:

> Interesting condition.  According to Developers Reference 5.9.4,
> orphaning is a process that is only supposed to be initiated by the
> existing maintainer.

Orphaning is also done by the QA team, and it's frequently been done by
other people after discussion in debian-devel provided that the same sorts
of checks have been done.  (Membership in the QA team is not well-defined,
so to some extent that's the same thing.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #28 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 22:02:27 -0400

On Mon, Jul 16, 2012 at 9:37 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Interesting condition.  According to Developers Reference 5.9.4,
>> orphaning is a process that is only supposed to be initiated by the
>> existing maintainer.
>
> Orphaning is also done by the QA team, and it's frequently been done by
> other people after discussion in debian-devel provided that the same sorts
> of checks have been done.  (Membership in the QA team is not well-defined,
> so to some extent that's the same thing.)

Thanks for the correction.  3.1.3 does grant that power to the QA
team, which is of course effectively all DDs.

Although once salvaging is in place, and there is a self-directed way
to adopt packages, the need to do orphaning beforehand won't be
necessary.  So then orphaning as a maintainer-only right just makes
more sense.

Just to give you an idea of what I'm thinking long-term: salvaging
will one day obsolete MIA.  If maintainership changes become
self-directed, then ultimately there is no longer a need for a MIA
team to pester people (which no one wants to do anyway).  MIA'ness
will be clear once new maintainers have taken over all of the old
maintainer's packages and removed his name.  That would then give MIA
the go-ahead to say hey, all of your packages have been salvaged,
we'll be closing your account soon if no action is taken.

Best wishes,
Mike

Message #33 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Michael Gilbert <mgilbert@debian.org>

Cc: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Mon, 16 Jul 2012 19:28:22 -0700

Michael Gilbert <mgilbert@debian.org> writes:

> Just to give you an idea of what I'm thinking long-term: salvaging will
> one day obsolete MIA.  If maintainership changes become self-directed,
> then ultimately there is no longer a need for a MIA team to pester
> people (which no one wants to do anyway).  MIA'ness will be clear once
> new maintainers have taken over all of the old maintainer's packages and
> removed his name.  That would then give MIA the go-ahead to say hey, all
> of your packages have been salvaged, we'll be closing your account soon
> if no action is taken.

The other half of the replacement for MIA would be the periodic WAYT pings
(hopefully that's still a plan to do that ongoing) to confirm that people
still want to be active in the project.  Just because someone has no
packages doesn't mean that we should close their account; they're still
entitled to vote for as long as they wish, IMO.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #38 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Bart Martens <bartm@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Tue, 17 Jul 2012 06:52:59 +0000

On Mon, Jul 16, 2012 at 06:35:33PM -0400, Michael Gilbert wrote:
> I've prepared an initial draft of a developers reference patch that
> would document a package salvaging process.  Please see below.

Hi Mike,

I'm not convinced that we need an additional procedure for package salvaging
because we already have procedures addressing that.  I suggest that you propose
improvements to the existing procedures if you want them improved.  I also
doubt that some things you propose are improvements.  I comment in detail on
your patch:

> +<section id="package-salvaging">
> +<title>Package Salvaging</title>
> +
> +<para>
> +Unfortunately over time, certain maintainers become less active without turning
> +over their packages via the orphaning process or fully leaving the project.
> +This is a natural process, and there is nothing wrong with it, but in the
> +meantime their packages suffer bit-rot

Anyone interested can prevent such bit-rot via NMU.
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

> and bug reports go unanswered.

Anyone interested can answer bug reports.

> +Fortunately the NMU process provides a means to inject much needed health into
> +these neglected packages.

Yes, the NMU procedure already addresses that.

>  This is the liberal NMU.

If you want the NMU procedure to allow more "liberal" changes then I suggest
that you propose a change to the NMU procedure:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

> +</para>
> +
> +<para>
> +Also, at times, there can be situations where contributors would like to modify
> +a package for a lower severity bug report, but said bug is ignored for a long
> +time by an active maintainer.

If the maintainer has no time to answer the bug report, then anyone interested
can answer the bug report and/or update the package via NMU.

>  If the fix is good, it should certainly go into
> +the archive.

Not without permission from the active maintainer.  The NMU procedure allows
the active maintainer to object against the NMU.

>  This is another case where an NMU is appropriate, but it would
> +not be considered a liberal NMU.  These cases can be resolved by are a standard
> +10-day NMU,

The NMU procedure already mentiones delays and also the use of the DELAYED
queues.

You seem to propose that anyone can just go ahead with uploading NMUs in
DELAYED/10 for fixing lower severity bug reports ignored by an active
maintainer.  I object against that.

> and conflicts can be refered to the technical committee as a
> +technical dispute.
> +</para>

This is obviously already described elsewhere.

> +
> +<para>
> +Ideally, the liberal NMU is done by uploading the package of interest to the
> +DELAYED/10 queue or greater.
> +</para>

So far your term "liberal NMU" seems to mean "any fix anyone feels as a good
fix".  If your proposal would be that "anything goes via DELAYED/10 queue or
greater", then I would absolutely object against that.

If you want to describe in more detail when the DELAYED/10 queue can be used
for NMU's, then I suggest that you propose changes to the NMU procedure.

> +
> +<para>
> +The liberal NMU is also appropriate in general for fixing bugs, but
> for packages
> +that have not recieved an upload in greater than six months liberal NMUs are
> +highly encouraged and can fix issues that are not tracked in the BTS.  Changing
> +the build system in a Liberal NMU is still not acceptable, but all
> other changes
> +are allowed including packages of new upstream versions.
> +</para>

You seem to propose a change to what is allowed via NMU.  Such changes clearly
belong in the text of the NMU procedure, not in a separate text.

> +
> +<para>
> +A mail for each Liberal NMU should be sent to either the maintainer or the BTS
> +(which is automatically forwarded to the maintainer) and should include a
> +hyperlink to a VCS containing the changeset of this liberal NMU and all of your
> +prior liberal NMUs to this package.  A VCS link is preferred to
> +an NMU patch in these cases since long-term if the maintainer does not
> +resume activity, you will be making many liberal NMUs and ultimately becoming
> +its maintainer.  The message body should maintain a positive
> +attitude and mention that the maintainer may review and has the option to
> +cancel the NMU while it waits in the upload queue for the next 10 or more days.
> +</para>

The NMU procedure describes that "you must send a patch with the differences
between the current package and your proposed NMU to the BTS".

A VCS link is, in my opinion, not preferred.  If the maintainer no longer
maintains the package, then we already have this procedure:
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

And you seem to repeat that a "liberal NMU" can go in the DELAYED/10 queue.

> +
> +<para>
> +Unfortunately the maintainer may reject some of your contributions that you
> +disagree with.  In this case, try to find a way to implement the changes in a
> +way that the maintain will approve.

That is already part of the NMU procedure.

>  Failing that, please refer the matter as a
> +technical disagreement to the technical committee.
> +</para>

That is already documented elsewhere.

> +
> +<para>
> +Preferably, after you have demonstrated that you can handle the package, the
> +maintainer will either step down or approve you to be a part of the packaging
> +team.

Sounds like just a friendly package maintenance handover or just adding a
co-maintainer.

If you mean that the current maintainer is forced to step down, then this
procedure applies:
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

If you want the MIA procedure improved, then I suggest that you propose changes
to that.

>  If the maintainer has been active or not approved this after an
> +additional six months after your first liberal NMU, you may petition the tech
> +committee to rule on the maintainership of the package.  Please include as much
> +information as possible (including bug reports, uploaded versions, VCS links,
> +etc.) to make the committee's decision easy.

So you propose to ignore the MIA procedure and to go directly to the tech
committee.  Has the tech committee taken over the MIA procedure ?

>  If the maintainer at some point
> +becomes active, and does not want your participation to continue, you may
> +petition either accept that request and step down or petition the tech
> +committee to rule on the matter.
> +</para>

The maintainer can simply refuse further NMU's.  I don't see any reason to
challenge the maintainer's position before the tech committee in this context.

> +
> +<para>
> +If a package has been already been orphaned, you may salvage it without any
> +kind of approval.
> +</para>

This is already documented in the part about adopting orphaned packages.

> +
> +<para>
> +Filing a removal request against ftp.debian.org, then reintroducing the package
> +with yourself as the maintainer is considered adversarial and is explicitly
> +disallowed.
> +</para>

You seem to want to prevent hijacking a package via removal and reintroduction.
I don't see how that could be possible, because ftpmaster doesn't remove
packages without good reason.

Also, some packages must be removed asap, for example when the software is
undistributable.  After that removal, if the copyright and license issues are
solved, then the software can be reintroduced by anyone interested via an ITP.
I see no problem with that.

Regards,

Bart Martens

Message #41 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@debian.org>

To: 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Tue, 17 Jul 2012 09:10:32 +0200

* Bart Martens <bartm@debian.org>, 2012-07-17, 06:52:
>ftpmaster doesn't remove packages without good reason.

Sure they do.

-- 
Jakub Wilk

Message #46 received at 681833@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, 681833@bugs.debian.org

Subject: Re: Bug#681833: developers-reference: please document a package salvaging process

Date: Fri, 7 Sep 2012 08:08:07 +0200

Hi!

On Mon, 2012-07-16 at 18:35:33 -0400, Michael Gilbert wrote:
> package: developers-reference
> severity: normal
> version: 3.4.8
> tag: patch

> I've prepared an initial draft of a developers reference patch that
> would document a package salvaging process.  Please see below.

Bart has already covered some other parts which I agree with, I just
wanted to expand on some of the proposed changes.

> --- pkgs.dbk.orig	2012-07-16 18:19:56.065047490 -0400
> +++ pkgs.dbk	2012-07-16 18:32:20.626439544 -0400
> @@ -2257,6 +2257,86 @@

> +<para>
> +Also, at times, there can be situations where contributors would like to modify
> +a package for a lower severity bug report, but said bug is ignored for a long
> +time by an active maintainer.  If the fix is good, it should certainly go into
> +the archive.  This is another case where an NMU is appropriate, but it would
> +not be considered a liberal NMU.  These cases can be resolved by are a standard
> +10-day NMU, and conflicts can be refered to the technical committee as a
> +technical dispute.
> +</para>

> +<para>
> +The liberal NMU is also appropriate in general for fixing bugs, but for packages
> +that have not recieved an upload in greater than six months liberal NMUs are
> +highly encouraged and can fix issues that are not tracked in the BTS.  Changing
> +the build system in a Liberal NMU is still not acceptable, but all other changes
> +are allowed including packages of new upstream versions.
> +</para>

Maybe it's just me, but my first assumption when confronted with a “lower
severity” bug from a known active maintainer, which has gone unanswered
(even if it has got a patch) is that either:

 a) There's something that needs (further) (lengthy) investigation.
 b) A fix might seem trivial but it's not: might need major work like
    a coordinated transition, might cause breakage elsewhere, the patch
    might be misdesigned or wrong, etc.
 c) There's been more important or urgent things the maintainer has had
    to deal with (this might include reading a book or going to the
    beach too! happy maintainers are better maintainers).
 d) The maintainer might prefer to queue a bunch of changes instead of
    doing single item uploads.
 e) Something else.

And my first reaction, if for whatever reason the bug is relevant or
important to me, would be:

 1) If the bug seems trivial or obvious enough to me:
    - Try to diagnose the problem or provide a way to reproduce it,
      if that's still missing.
    - Try to provide a patch, if there's none.
 2) Otherwise, ask (if no one did before) on the bug report if the
    maintainer has done some investigation or started working on a
    fix already; might need help tracking it down, testing a patch,
    coordinating or getting a transition done, or implementing a fix;
    or if the bug has a patch on it, ask if the maintainer would ack
    it or required upstream to ack it, and suggest if an NMU might be
    of help, by offering to prepare it and handling any aftermath.
 3) If the bug is extremely important to me, or maybe I feel like it
    that day, try to get acquainted with the code base, or learn the
    programming language, etc; then goto (1).
 4) _Patiently_ wait; goto (3) after some time or goto (2) but
    certainly not before at least several months or more have passed
    (i.e. “Do not pester nor whine”).

In addition, not all bugs are made equal. For some it seems to me NMUs
are the right tool if enough time has passed, those would include
segfaults, crashes, build failures, data loss, security issues, policy
violations, etc, in general what would apply for most RC bugs. Some
others of lower severity seems to me can also be fine for NMUs too,
like translation updates, typo fixes, patches cherry picked from
upstream, even new upstream releases (as long as the maintainer has
not stated explicitly there might be problems with packaging such
newer version).

But other classes of bugs I strongly think should be considered off the
table if the maintainer has not acked them, because if supposedly NMUs
are a tool to help the maintainer (as it has been promoted in recent
times, to make them more widely accepted) then imposing on the
maintainer for example a delta from upstream when the maintainer might
have a zero-divergence policy would not be acceptable, less so if it
ends up being rejected by upstream, in which case it's much more work
for the maintainer. Full disclosure, I've never had any issue with
diverging greatly from upstream, but then I'm the one deciding what
future work I'm imposing on myself, and knowing one's upstream also
helps in predicting what solution or implementation has chances of
being accepted.

So, I strongly disagree with this liberal NMU concept for active
maintainers. And for inactive maintainers, there's already the MIA
process.

> +<para>
> +A mail for each Liberal NMU should be sent to either the maintainer or the BTS
> +(which is automatically forwarded to the maintainer) and should include a
> +hyperlink to a VCS containing the changeset of this liberal NMU and all of your
> +prior liberal NMUs to this package.  A VCS link is preferred to
> +an NMU patch in these cases since long-term if the maintainer does not
> +resume activity, you will be making many liberal NMUs and ultimately becoming
> +its maintainer.  The message body should maintain a positive
> +attitude and mention that the maintainer may review and has the option to
> +cancel the NMU while it waits in the upload queue for the next 10 or more days.
> +</para>

I disagree a VCS link should be preferred (I think it's obviously fine
as an optional addition though), patches should go to the BTS, where
they cannot be lost, those VCS can (and tend to) disappear or get
relocated over time, and the normal way to review stuff anyway is
through patches not remote branches.

> +<para>
> +Unfortunately the maintainer may reject some of your contributions that you
> +disagree with.  In this case, try to find a way to implement the changes in a
> +way that the maintain will approve.  Failing that, please refer the matter as a
> +technical disagreement to the technical committee.
> +</para>

There appears to be this relatively recent, continued and increasing
trend in some parts of the project to switch to some kind of autocratic
regime, instigated by some to give life to the tech-ctte, turn it into
an interventionist body, and make forceful resolutions a trivialized
day-to-day thing which the project should be somehow proud and happy
about. It's not clear to me if this is just a cultural thing or
particular to some of the individuals pushing for this, but escalation
to this kind of body and the subsequent forceful resolutions are very
confrontational and polarizing, or superfluous if agreement has emerged
elsewhere. Not to mention that being continuously given “direction”
(technical or otherwise) from up there by the “authority” feels
rather insulting.

To me this is a very sad and concerning trend... that I'd like and
I'd expect (?) the project to eventually reject, once enough people
have either been alienated and/or left in disgust, so that we can go
back to the previous decentralized and organic self-organizing way of
doing things; in the same way the excess of GRs in the recent past
got stopped. Although I've to say I'd rather see the project decide
extreme or globally reaching controversial cases through GRs than
through the tech-ctte.

And just to be clear my current position on this is not a direct
consequence of the multi-arch “overruling”, I've had this opinion
for a very long time now; just one recentish example:

  <http://lists.debian.org/debian-ctte/2010/04/msg00005.html>

> +<para>
> +Preferably, after you have demonstrated that you can handle the package, the
> +maintainer will either step down or approve you to be a part of the packaging
> +team.  If the maintainer has been active or not approved this after an
> +additional six months after your first liberal NMU, you may petition the tech
> +committee to rule on the maintainership of the package.  Please include as much
> +information as possible (including bug reports, uploaded versions, VCS links,
> +etc.) to make the committee's decision easy.  If the maintainer at some point
> +becomes active, and does not want your participation to continue, you may
> +petition either accept that request and step down or petition the tech
> +committee to rule on the matter.
> +</para>

Here it seems to me you are proposing as an acceptable outcome that
the current maintainer would end up having to work with the person
escalating the forceful inclusion of co-maintainership to the tech-ctte.
Either that, or trivializing taking over maintainership by force.

Having to “work closely” with people who have taken you to the tech-ctte
is already extremely annoying, displeasing and demotivating; and I think
being forced to work with them on a team when that was not the case
before would reach a new level of affront. And again it probably is just
me, but I think the right and respectful way to get into an existing
“team” (if no other procedures are in place) is by invitation, not by
forcing oneself in.

regards,
guillem

Message #51 received at 681833-close@bugs.debian.org (full text, mbox, reply):

From: Tobias Frost <tobi@debian.org>

To: 681833-close@bugs.debian.org

Subject: Bug#681833: fixed in developers-reference 3.4.21

Date: Tue, 25 Sep 2018 21:49:11 +0000

Source: developers-reference
Source-Version: 3.4.21

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 681833@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Tobias Frost <tobi@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)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 25 Sep 2018 23:21:04 +0200
Source: developers-reference
Binary: developers-reference developers-reference-de developers-reference-fr developers-reference-ja developers-reference-ru developers-reference-it
Architecture: source
Version: 3.4.21
Distribution: unstable
Urgency: medium
Maintainer: Developers Reference Maintainers <debian-policy@lists.debian.org>
Changed-By: Tobias Frost <tobi@debian.org>
Description:
 developers-reference - guidelines and information for Debian developers
 developers-reference-de - guidelines and information for Debian developers, in German
 developers-reference-fr - guidelines and information for Debian developers, in French
 developers-reference-it - guidelines and information for Debian developers, in Italian
 developers-reference-ja - guidelines and information for Debian developers, in Japanese
 developers-reference-ru - guidelines and information for Debian developers, in Russian
Closes: 681833 879863 907535 907605 908867
Changes:
 developers-reference (3.4.21) unstable; urgency=medium
 .
   [ Tobias Frost ]
   * Team upload.
   * Fix Alioth references in README-contrib (Closes: #907605)
   * Add package-salvaging text (Closes: #681833, #907535).
   * Move shell snippet in §6.4 to common.ent.
   * Update German translation. (Closes: #908867)
 .
   [ Nicholas D Steeves ]
   * Change priority extra to optional in §6.7.7 (Closes: #879863).
Checksums-Sha1:
 ca6921080acc2685ee4ec30df92c9d5ed22f186f 2401 developers-reference_3.4.21.dsc
 fb8ffd8e407332c3c31d4e0933adbb9daf7a7065 662040 developers-reference_3.4.21.tar.xz
 6e8913f5490eed60c21697d1eebb2958b60ab881 5658 developers-reference_3.4.21_source.buildinfo
Checksums-Sha256:
 6aad631876340abb61cfefe64646614662e384f96683c165d7cccd1174edcc6f 2401 developers-reference_3.4.21.dsc
 c088401811702a83a8bebc079fac58c47da9da8da3e7d6e96dc1e39e9fb9007e 662040 developers-reference_3.4.21.tar.xz
 36049a5a27abfe2577fe69d4e5502024cc5ccf02d2c3572c40fc3bf8bf3dc013 5658 developers-reference_3.4.21_source.buildinfo
Files:
 3147202685fd1b2d603081dfa117c80e 2401 doc optional developers-reference_3.4.21.dsc
 3c76053d94159add6f5dd6f86953d183 662040 doc optional developers-reference_3.4.21.tar.xz
 31b15b65df7fd490a2c3f8fb05788d29 5658 doc optional developers-reference_3.4.21_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAluqp/oACgkQkWT6HRe9
XTb0vhAAhJKZgYpSDbzM9V58FnRz+u2xoDAqJNa5OSlVZZF5JCmkz2ANI9CPTdRr
jJOR+OdMo88yQUFtm4VUyvjPyC6IzQ4X9W1pGmlJpT5fbyWAJIR/emmX3XTPgJjw
HF7OIJdA5qp8LQcGkWSjgEciPwWN6Et+d4ExGMIj9Qb7+EsVOguHxYBI5cIW7Igs
SmuWB1+O7MhRAxuF4JuVT20n/v7QK0jvSrsEnPQS36ltP2jvGFuYZhGXK45Oxwuw
KlNDXNbsxHzEfhf0WYp6eLNkMRTcyT9gIdHQS4qTy6zWximIYtV/AaCW1dAC0oMI
qBaurhFGlubPt25HjMR6vMoJASsKIcP8V5qzAscWtPtGUOJxqRDjJlLShpB8ZRUN
Za4fLgRKqrixmF6VbRxnVJgPaOOBsTCjILm07x6kMyNmzpYLmpMjYbOlocdQl7Fs
OvDU8X6ZiYH6Qph9jkAqIpXEM6dX39UxysMxoJ53dg5D7JIqL5cnGbNJ1cNvvLWJ
1K+3aTG9Ct1MGFwk2FBwvUAXrzjKC7HEK98mj4qim/89r++pedAKRESeGmDssR7L
jCSpkYz29LSBAZw4eSX4S0aypWozS4mi4i+waoUy/eDg7AyRj4MiIb3c4Z/lDQQO
JvVu5bzqbTXXjo5sNODMb4MRr34UmaFdYi7BILKktHrjKdWK5Ec=
=qQgj
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.