FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-28-2012, 04:48 PM
Arno Töll
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hello,

we may all agree that the maintenance of some (many?) packages in Debian
is in a unclear situation. There is a transient state, where people are
interested to bring a package in shape but the strong role of a package
maintainer in Debian effectively blocks any commitment beyond fixing
important issues in minimally invasive non-maintainer uploads.

I realize this is going to be controversial (a bit?), but eventually I'm
hoping to allow people to make Debian better. Truth is, as a good
citizen of Debian Town, there few possibilities for unapproved changes
someone else's packages.

Therefore, this is not an approach to take packages away from people.
Instead, I'm trying to find a procedure where people don't need to be
afraid of the good work they are interested to deliver, while there is a
good chance, the original maintainer is unavailable and unresponsive for
a substantial time. Our goal ought to be to make Debian better - if
people are interested to make a package better, why should we refuse
their work?

Prior discussion on that matter was on this year's DebConf [6][7]. While
I didn't base my work directly on the argumentation from that DebConf
BoF, many ideas I am proposing are being derived from it. I tried to
address concerns, but also problems mentioned there.

Some more work was approached by Michael Gilbert in #681833 [8],
introducing "liberal NMUs", a concept to weaken the NMU requirements in
case of a maintainer missing in action. Note, my proposal (somewhat) is
in conflict with this proposal.

The actual proposal follows below, but first let me address some questions:

Q: Why do you call it a salvage, not hijack? You DO eventually hijack a
package

Well, that's right. As for me, I do not mind continue to call my salvage
process a hijack, if people prefer. However, the term hijacking has a
negative connotation, implying a rude and hostile action. My "weak
hijack", however, tries to be as nice to (previous) maintainers as
possible. Also, I'm trying to work out explicitly what I mean by
"salvaging" and what I still consider to be a "hijack".

Having that said, I am not interested to debate later on whether a
package was salvaged or whether it was hijacked ("You waited 23 seconds
too little - you hijacked it!"). So, please, let's concentrate on facts,
not wording.

Q: What? You only want to wait X weeks before considering a package
unmaintained? or, alternatively: What? Why do you want me to wait so
long, until the package is finally considered orphaned?

Truth is, we won't ever agree on that. I tried to find a compromise
being longer than any usual or typical vacation or "work has caught me"
period, but shorter than a typical Debian release cycle letting people
time to actually work on a package.

Having that said, I'm entirely open to any other waiting times, people
may find more appropriate.


While I am taking the blame for piping this proposal to a larger
audience, I'd like to thank gregor herrmann, Laurent Bigonville, David
Prévot, Stuart Prescott and Steve McIntyre, Jakub Wilk for commenting
previously and working out this proposal together with me.

Actual proposal follows:

Adopting an unmaintained package
===========================

Packages being marked as orphaned, or those being up for adoption can be
immediately taken over. This is currently the status quo. The wnpp
pseudo-package [1][2] holds packages being up for adoption ("RFA" bugs),
or being orphaned ("O" bugs). Moreover, packages maintained by the QA
Team [3] can be taken over without further discussion.

Salvaging a package
=================

Salvaging is the process by which, one attempts to save a package from a
state where it is poorly maintained or appears not maintained at all,
without being officially orphaned. This is a weaker and faster procedure
than orphaning a package officially through powers of the MIA team [4].
Salvaging a package is not meant to replace MIA handling, and in
contrast to it, it does not comment about the overall activity of a
maintainer. Instead, it handles a package maintainer transition for a
single package only, leaving any other package or Debian membership or
upload rights (when applicable) untouched. However, during the salvage
process, the MIA team will be informed (see below). This might be
considered by them as a kick-off to start the MIA procedure as well.
That's a desired side effect when found beneficial by MIA team members.


Reasons to salvage a package
----------------------------------------
The package is in clear need of some love and care, i.e. there are open
bugs, missing upstream releases, or there is work needed from a
quality-assurance perspective; AND there is the need to upload the
package to deal with these issues; AND at least one of these criterias
applies:

* There is no visible activity regarding the package [5] for /six months/.

* There is no visible activity regarding the package [5], and the
maintainer of the package in question is tracked in the MIA database
already, and there was no recorded activity in the MIA tracker for
/three months/.

* A previous NMU was not acknowledged, and at least another issue
justifying another NMU is pending for /one month/ [5].

* The last upload was an NMU and there was no maintainer upload within
/one year/.

* The package blocks a sourceful transition or the implementation of a
release goal for /six months/ after a transition or release goal bug was
filed against the package in question.


Procedure to salvage a package
-----------------------------------------
If any of the criteria denoted above are fulfilled, anyone interested
can start the salvage procedure. For Debian Developers, it should be
checked whether they are on vacation.

1) A bug with severity "serious" against the package in question must be
filed, expressing the intent to take over maintainership of the package.
The reporter may also offer co-maintenance of the package.

2) The maintainer, or any current uploader of the package in question
may object publicly in response to the bug filed within 14 days. Of
course, current maintainers may also agree to the intent to salvage a
package by filing a (signed) public response to the bug. In such a case,
a new package can be uploaded immediately thereafter by the new
maintainer(s).

3) After waiting at least the required 14 days, another warning must be
sent to the bug report, this time also the MIA team shall be informed
and all maintainers or uploaders of the package shall be contacted
explicitly as well.

4) After waiting another 14 days, the package can be salvaged. An upload
replacing the former maintainers of the package can be made. The salvage
bug should be closed by maintainer upload, and the DELAYED/7 queue
should be used for the upload.


Hijacking a package
================
Hijacking a package should be considered as a very last step. Hijacking
a package happens, whenever a package does not qualify for the salvaging
criteria above, and was not formally orphaned by the MIA team either.
Also, any case where any salvage criterion is fulfilled, but the current
maintainer of a package explicitly objects to give up his package is
considered a hijack, if no agreement can be found otherwise.
In such cases the maintainer must be overruled by a resolution of the
Technical Committee (tech-ctte).


[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp
[2] http://wnpp.debian.net/?sort=installs;desc
[3] http://qa.debian.org/developer.php?login=packages@qa.debian.org
[4] http://wiki.debian.org/qa.debian.org/MIATeam
[5] Activity may be defined in favor of the maintainer if in doubt. A
maintainer may ask for help or welcome a NMU. This counts as activity
with respect to salvage criterias. If a package lacks uploads, there is
no visible bug triaging, and - if applicable - the source package's VCS
does not show commits this is an indication, a package lacks an active
maintainer.
[6] http://penta.debconf.org/dc12_schedule/events/926.en.html
[7] https://lists.debian.org/debian-project/2012/07/msg00003.html
[8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681833

--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 
Old 09-28-2012, 05:52 PM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi Arno,

On Fri, Sep 28, 2012 at 06:48:22PM +0200, Arno Töll wrote:
> Actual proposal follows:

The proposal adds a new procedure that overlaps/bypasses existing procedures.

We have discussed that before in this thread :
http://lists.debian.org/debian-devel/2012/07/msg00540.html

What we essentially need, is a lightweight procedure to orphan individual
packages. I propose this :

| Anyone can mark a package as orphaned after the following steps have been
| completed : Someone submits an "intent to orphan" in the bts with an
| explanation of why he/she thinks that the package needs a new maintainer.
| Anyone can submit this "intent to orphan". At least three DD's second the
| "intent to orphan" on the same bug report with a cc to the maintainer. And the
| maintainer does not respond within one month after the the third second.

After the package is orphaned, the rest of the "salvaging" fits in the existing
procedures.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120928175223.GA2966@master.debian.org">http://lists.debian.org/20120928175223.GA2966@master.debian.org
 
Old 09-28-2012, 08:51 PM
Ricardo Mones
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi,

On Fri, 28 Sep 2012 18:48:22 +0200
Arno Töll <arno@debian.org> wrote:

> Salvaging a package
> =================
>
> Salvaging is the process by which, one attempts to save a package from a
> state where it is poorly maintained or appears not maintained at all,
> without being officially orphaned. This is a weaker and faster procedure
> than orphaning a package officially through powers of the MIA team [4].
> Salvaging a package is not meant to replace MIA handling, and in
> contrast to it, it does not comment about the overall activity of a
> maintainer. Instead, it handles a package maintainer transition for a
> single package only, leaving any other package or Debian membership or
> upload rights (when applicable) untouched. However, during the salvage
> process, the MIA team will be informed (see below). This might be
> considered by them as a kick-off to start the MIA procedure as well.
> That's a desired side effect when found beneficial by MIA team members.
>
>
> Reasons to salvage a package
> ----------------------------------------
> The package is in clear need of some love and care, i.e. there are open
> bugs, missing upstream releases, or there is work needed from a
> quality-assurance perspective; AND there is the need to upload the
> package to deal with these issues; AND at least one of these criterias
> applies:
>
> * There is no visible activity regarding the package [5] for /six months/.
>
> * There is no visible activity regarding the package [5], and the
> maintainer of the package in question is tracked in the MIA database
> already, and there was no recorded activity in the MIA tracker for
> /three months/.
>
> * A previous NMU was not acknowledged, and at least another issue
> justifying another NMU is pending for /one month/ [5].
>
> * The last upload was an NMU and there was no maintainer upload within
> /one year/.
>
> * The package blocks a sourceful transition or the implementation of a
> release goal for /six months/ after a transition or release goal bug was
> filed against the package in question.
>
>
> Procedure to salvage a package
> -----------------------------------------
> If any of the criteria denoted above are fulfilled, anyone interested
> can start the salvage procedure. For Debian Developers, it should be
> checked whether they are on vacation.
>
> 1) A bug with severity "serious" against the package in question must be
> filed, expressing the intent to take over maintainership of the package.
> The reporter may also offer co-maintenance of the package.
>
> 2) The maintainer, or any current uploader of the package in question
> may object publicly in response to the bug filed within 14 days. Of
> course, current maintainers may also agree to the intent to salvage a
> package by filing a (signed) public response to the bug. In such a case,
> a new package can be uploaded immediately thereafter by the new
> maintainer(s).
>
> 3) After waiting at least the required 14 days, another warning must be
> sent to the bug report, this time also the MIA team shall be informed
> and all maintainers or uploaders of the package shall be contacted
> explicitly as well.

If the above criteria only apply to one package but the rest of
maintainer's packages is being maintained, informing the MIA team should
be bypassed: maintainer is just neglecting a single package but not MIA.
And in fact there's little the MIA team can do with those maintainers, so
this procedure could be a nicer alternative.

Otherwise the MIA team should be Cc-ed first, when reporting the bug: the
maintainer may be very likely MIA, I don't see a reason to wait more. And
if MIA team achieves a response quicker, the salvage procedure bug can be
fixed faster.

regards,

P.S.: please keep Cc to debian-qa, I'm not subscribed to debian-devel.
--
Ricardo Mones, on behalf of Debian QA/MIA team
http://people.debian.org/~mones
«Tomorrow will be cancelled due to lack of interest.»
 
Old 09-30-2012, 04:33 PM
Stefano Zacchiroli
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Fri, Sep 28, 2012 at 05:52:23PM +0000, Bart Martens wrote:
> On Fri, Sep 28, 2012 at 06:48:22PM +0200, Arno Töll wrote:
> > Actual proposal follows:
>
> The proposal adds a new procedure that overlaps/bypasses existing procedures.
>
> We have discussed that before in this thread :
> http://lists.debian.org/debian-devel/2012/07/msg00540.html
>
> What we essentially need, is a lightweight procedure to orphan individual
> packages. I propose this :
[…]
> After the package is orphaned, the rest of the "salvaging" fits in the existing
> procedures.

As a general principle, I'm with Bart here. I don't think we will
benefit from a new, relatively complex, procedure that overlaps with
other existing mechanisms.

Socially, we need to acknowledge the fact that the current procedure to
orphan packages might be too heavyweight, and too coarse-grained, to
efficiently deal with the frequent situation where maintainers lose
interest in specific packages. Procedurally, we need rule of thumbs
that empower more active and interested maintainers to understand when
they can go on. And we need to favor the current maintainers if they
show up again *doing* something on the packages in question.

Also, I've grown weary of procedures with several steps, each of which
with delays. In my (now fairly extensive) experience in promoting what
have been called "liberal NMUs", I think I've learned that the key is
empowering motivated people right there, when they are active and
interested. Ask them to wait in several steps, for several weeks, and
most of them will probably lose interest and move on.

Of course we need *some* waiting time for orphaning by 3rd-parties, but
IMHO we should not require more than a reasonable time frame before
acting + a long DELAYED/XX value. After that, waiting (for the
DELAYED/XX value to expire) should result in the desired behavior,
i.e. salvaged package.

I don't know what to make of the "seconds" suggestion by Bart, though. I
understand the rationale, but is not clear to me how to raise the
interest by other DDs in reviewing the "intent to orphan" bugs filed by
3rd parties. Maybe we should document to post them on -qa? That *might*
have the side-effect of fostering the creation of a review community for
these kind of actions on -qa. Mumble mumble...

Cheers.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
 
Old 09-30-2012, 04:57 PM
Arno Töll
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi,

On 30.09.2012 18:33, Stefano Zacchiroli wrote:
> As a general principle, I'm with Bart here. I don't think we will
> benefit from a new, relatively complex, procedure that overlaps with
> other existing mechanisms.

As for me, I am fine with *any* proposal which works out in practice.
Bei it mine, Bart's or any other. I just hope to find consensus in a
practice eventually.

> I don't know what to make of the "seconds" suggestion by Bart, though. I
> understand the rationale, but is not clear to me how to raise the
> interest by other DDs in reviewing the "intent to orphan" bugs filed by
> 3rd parties. Maybe we should document to post them on -qa? That *might*
> have the side-effect of fostering the creation of a review community for
> these kind of actions on -qa. Mumble mumble...

I do not think the seconding is a good idea as a rationale to justify a
salvage/hijack. In my proposal I tried to avoid social side-effects by
providing a measurable quantity to determine when a package is orphaned.
If we rely on Debian Members to second a proposal I see these problems
mainly:

* We are effectively ruling out opinions of non-members. That's bizarre,
since we allow them to maintain (and even "hijack") packages. Why
wouldn't we allow them to second an attempt to hand someone else the
maintainership of a package? On the other hand, we cannot allow any
random someone to make binding votes, given impersonating identities on
the Internet is no challenge at all

* Seconding a proposal does not say anything about their rightfulness.
I'm pretty sure to find three seconds for almost any (not so) stupid
idea in Debian, even if 25 people may oppose it.

* On the other hand, it won't be a problem either to find (almost) any
number of people opposing a plan. Especially if we talk about a
controversial idea like that.

* If we rely on social metrics ("I think this your attempt is legit")
instead of quantifiable numbers ("Your attempt is legit because it
fulfills criterion X") it is pretty clear, we will end up in a dispute
over an individual case soon(er or later).


However, if we do not add a constraint which needs to be passed (be it a
time based constraint or seconding an intent by someone else) we haven't
won anything over the status quo: File an intent to salvage/hijack a
package, wait if people complain loud enough. We would still be in a
legal gray area, where it is not clear whether one is allowed to salvage
a package from a bad maintainership.

I think the most important rationale is to get people not to be afraid
to take over packages anymore, if their intentions are meant well.

--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 
Old 09-30-2012, 06:10 PM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Sun, Sep 30, 2012 at 06:33:58PM +0200, Stefano Zacchiroli wrote:
> As a general principle, I'm with Bart here. I don't think we will
> benefit from a new, relatively complex, procedure that overlaps with
> other existing mechanisms.
>
> Socially, we need to acknowledge the fact that the current procedure to
> orphan packages might be too heavyweight, and too coarse-grained, to
> efficiently deal with the frequent situation where maintainers lose
> interest in specific packages.
...
> I don't know what to make of the "seconds" suggestion by Bart, though. I
> understand the rationale, but is not clear to me how to raise the
> interest by other DDs in reviewing the "intent to orphan" bugs filed by
> 3rd parties. Maybe we should document to post them on -qa? That *might*
> have the side-effect of fostering the creation of a review community for
> these kind of actions on -qa. Mumble mumble...

Posting them on -qa sounds like a good idea to me. Can you elaborate on that
"side-effect" ? I don't understand that part.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120930181016.GE2465@master.debian.org">http://lists.debian.org/20120930181016.GE2465@master.debian.org
 
Old 09-30-2012, 09:26 PM
Stefano Zacchiroli
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Sun, Sep 30, 2012 at 06:10:16PM +0000, Bart Martens wrote:
> > I don't know what to make of the "seconds" suggestion by Bart, though. I
> > understand the rationale, but is not clear to me how to raise the
> > interest by other DDs in reviewing the "intent to orphan" bugs filed by
> > 3rd parties. Maybe we should document to post them on -qa? That *might*
> > have the side-effect of fostering the creation of a review community for
> > these kind of actions on -qa. Mumble mumble...
>
> Posting them on -qa sounds like a good idea to me. Can you elaborate on that
> "side-effect" ? I don't understand that part.

I just meant that if we encourage to post seconds (which are in fact
just a form of review of the intention to orphan) on a list such as -qa
(which is more specific-purpose than, say, -devel), we might end up
attracting there people who have an interest in doing this sort of
package quality review. That sounds like a useful side-effect to me. But
I'm still unsure about the benefits of the seconds principle, though.

Cheers.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
 
Old 10-01-2012, 08:51 AM
"Thijs Kinkhorst"
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi Arno,

Thanks for this initiative. It seems like a useful guideline.

> * A previous NMU was not acknowledged, and at least another issue
> justifying another NMU is pending for /one month/ [5].

I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
all used this term from the time that NMU's did not close bugs in the BTS
and therefore needed to be explicitly acknowledged by an MU. However,
since we have version tracking there's no need and I guess also no real
way to acknowledge a NMU anymore. Or would this just mean "a maintainer
upload happened after the NMU that didn't revert the changes"?

I've had an NMU in the past for a package when I had a little less time,
but the change was sound and correct. So I didn't bother to make an
(empty) MU just to acknowledge it - I think that should be OK and not
'punished' by taking it as a sign of an unmaintained package.

> Procedure to salvage a package
> -----------------------------------------

> 1) A bug with severity "serious" against the package in question must be
> filed, expressing the intent to take over maintainership of the package.
> The reporter may also offer co-maintenance of the package.

In my experience, a takeover of a package which is in dire need of some
love went most smoothly when it was done by just adding oneself as a
co-maintainer, not replacing the maintainer right away. This sends the
message that you want to help with the package, but doesn't send the
message that the current maintainer needs to go away.

Of course, if after a longer time the old maintainer still hasn't worked
on the package, he can be removed from the maintainer list (and may agree
to that if he sees that the new maintainer has done useful work).

I'd recommend to have the procedure advise principally that one just adds
oneself as a comaintainer, so to reword (1): "expressing the intent to add
oneself to the maintainer team for the package".


Cheers,
Thijs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 320712f750ed9d7450e4d804e1252d47.squirrel@aphrodit e.kinkhorst.nl">http://lists.debian.org/320712f750ed9d7450e4d804e1252d47.squirrel@aphrodit e.kinkhorst.nl
 
Old 10-01-2012, 09:11 AM
Charles Plessy
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Le Mon, Oct 01, 2012 at 10:51:22AM +0200, Thijs Kinkhorst a écrit :
>
> I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
> all used this term from the time that NMU's did not close bugs in the BTS
> and therefore needed to be explicitly acknowledged by an MU. However,
> since we have version tracking there's no need and I guess also no real
> way to acknowledge a NMU anymore. Or would this just mean "a maintainer
> upload happened after the NMU that didn't revert the changes"?

Hi Thijis,

Quoting Don Armstrong in the "Proposal to update NMU section 5.11.1" discussion
this year on debian-policy (as the list where changes to the Developers Reference
are also discussed):

Versioning is a directed acyclic graph. Each version has at most one
ancestor, though it may have many descendants. When you upload a
maintainer upload (MU) without including the NMU changelog entry, you
are indicating that your version is a descendant of the previous MU,
not the NMU. That's perfectly ok, but if you've actually fixed bugs
that were fixed in the NMU in your MU, you need to include lines in
the changelog to that effect, or later on manually fix-up the
versions.

http://lists.debian.org/debian-policy/2012/04/msg00060.html

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121001091108.GC26513@falafel.plessy.net">http://lists.debian.org/20121001091108.GC26513@falafel.plessy.net
 
Old 10-01-2012, 09:15 AM
Neil Williams
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Mon, 1 Oct 2012 10:51:22 +0200
"Thijs Kinkhorst" <thijs@debian.org> wrote:

> Hi Arno,
>
> Thanks for this initiative. It seems like a useful guideline.
>
> > * A previous NMU was not acknowledged, and at least another issue
> > justifying another NMU is pending for /one month/ [5].
>
> I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
> all used this term from the time that NMU's did not close bugs in the BTS
> and therefore needed to be explicitly acknowledged by an MU. However,
> since we have version tracking there's no need and I guess also no real
> way to acknowledge a NMU anymore. Or would this just mean "a maintainer
> upload happened after the NMU that didn't revert the changes"?

... or that the changes in the NMU have been applied to the packaging
VCS and will therefore survive into next versions. To me, this is the
biggest part of acknowledgement - even having the packaging in
collab-maint doesn't ensure that the patch gets into the packaging VCS,
risking losing the changes at the next upload.

So it's useful to have a statement acknowledging the NMU in the next
changelog because it gives that assurance when checking the history of
the changelog via the PTS.

> I've had an NMU in the past for a package when I had a little less time,
> but the change was sound and correct. So I didn't bother to make an
> (empty) MU just to acknowledge it - I think that should be OK and not
> 'punished' by taking it as a sign of an unmaintained package.

An empty upload with no purpose other than to acknowledge the NMU
really does seem useless though, true.

If a package is to be salvaged, the VCS may well change as well, so
whether an NMU has been acknowledged or not isn't that useful for the
salvage process.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 03:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org