Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
lpr/lpd
9 views
Skip to first unread message
Thorsten Alteholz
Sep 17, 2023, 1:20:04 PM9/17/23
to
Hi everybody,
as you might have heard during the Debconf talk of Till, cups3 and CPDB
(Common Printing Dialog Backends) are waiting at the gates.
Maybe this is a good opportunity to get rid of some old legacy stuff. Is
there anybody or do you know anybody who is using the old BSD lpr/lpd
stuff? I don't mean the lp/lpr commands that are provided by cups but
the old lpd spooler from package lpr.
Thorsten
as you might have heard during the Debconf talk of Till, cups3 and CPDB
(Common Printing Dialog Backends) are waiting at the gates.
Maybe this is a good opportunity to get rid of some old legacy stuff. Is
there anybody or do you know anybody who is using the old BSD lpr/lpd
stuff? I don't mean the lp/lpr commands that are provided by cups but
the old lpd spooler from package lpr.
Thorsten
Christoph Biedl
Sep 17, 2023, 2:30:04 PM9/17/23
to
Thorsten Alteholz wrote...
> Maybe this is a good opportunity to get rid of some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff?
Well, not me. But the thing that puzzles me is the popcon numbers:
lpr has 755, lprng 233.
Assuming most of these installation were not done deliberately but are
rather by-catch, or: Caused by some package that eventually draws them
in, via a dependency that has "lpr" (or "lprng") in the first place
instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
have no idea. And there's little chance to know.
Christoph
> Maybe this is a good opportunity to get rid of some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff?
lpr has 755, lprng 233.
Assuming most of these installation were not done deliberately but are
rather by-catch, or: Caused by some package that eventually draws them
in, via a dependency that has "lpr" (or "lprng") in the first place
instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
have no idea. And there's little chance to know.
Christoph
Russ Allbery
Sep 17, 2023, 3:40:04 PM9/17/23
to
Christoph Biedl <debia...@manchmal.in-ulm.de> writes:
> Well, not me. But the thing that puzzles me is the popcon numbers: lpr
> has 755, lprng 233.
> Assuming most of these installation were not done deliberately but are
> rather by-catch, or: Caused by some package that eventually draws them
> in, via a dependency that has "lpr" (or "lprng") in the first place
> instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
> have no idea. And there's little chance to know.
It at least used to be that you could print directly to a remote printer
> Well, not me. But the thing that puzzles me is the popcon numbers: lpr
> has 755, lprng 233.
> Assuming most of these installation were not done deliberately but are
> rather by-catch, or: Caused by some package that eventually draws them
> in, via a dependency that has "lpr" (or "lprng") in the first place
> instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
> have no idea. And there's little chance to know.
with lpr and a pretty simple /etc/printcap entry that you could write
manually. I used to use that mechanism to print to an office printer
until I discovered rlpr, which is even better for that use case. It's
possible some of those installations are people doing that, rather than
via dependencies or other things (in which case they probably should move
to rlpr).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon Richter
Sep 18, 2023, 12:00:04 AM9/18/23
to
Hi,
On 18.09.23 04:29, Russ Allbery wrote:
> It at least used to be that you could print directly to a remote printer
> with lpr and a pretty simple /etc/printcap entry that you could write
> manually. I used to use that mechanism to print to an office printer
> until I discovered rlpr, which is even better for that use case. It's
> possible some of those installations are people doing that, rather than
> via dependencies or other things (in which case they probably should move
> to rlpr).
Yes, that's basically how I use it. Pretty much all existing printers
with network interfaces support the BSD lpr protocol still, and accept
PostScript or PDF. People in Germany are likely to have a FritzBox DSL
router, which conveniently allows you to export USB printers that way too.
And yes, it is quicker for me to copy another printcap entry and swap
out the host name than it is to find out how to authenticate to CUPS,
set up the printer, print a test page then remove and recreate it
because the generated "short" name I need to pipe data into lpr isn't
short. I will definitely be looking into rlpr.
I think those packages are probably still useful to someone, I guess
several universities will be running these because they are small and
robust, and can just leave a job in the queue if there is a temporary
problem rather than mark the printer as offline and any jobs queued to
it as paused.
Oddly specific rant, I know, but it's "small" things like that that can
break a use case completely, and that's why we usually ship alternative
implementations for everything, and why a lot of seemingly small changes
are controversial: they break non-standard use cases.
Simon
On 18.09.23 04:29, Russ Allbery wrote:
> It at least used to be that you could print directly to a remote printer
> with lpr and a pretty simple /etc/printcap entry that you could write
> manually. I used to use that mechanism to print to an office printer
> until I discovered rlpr, which is even better for that use case. It's
> possible some of those installations are people doing that, rather than
> via dependencies or other things (in which case they probably should move
> to rlpr).
with network interfaces support the BSD lpr protocol still, and accept
PostScript or PDF. People in Germany are likely to have a FritzBox DSL
router, which conveniently allows you to export USB printers that way too.
And yes, it is quicker for me to copy another printcap entry and swap
out the host name than it is to find out how to authenticate to CUPS,
set up the printer, print a test page then remove and recreate it
because the generated "short" name I need to pipe data into lpr isn't
short. I will definitely be looking into rlpr.
I think those packages are probably still useful to someone, I guess
several universities will be running these because they are small and
robust, and can just leave a job in the queue if there is a temporary
problem rather than mark the printer as offline and any jobs queued to
it as paused.
Oddly specific rant, I know, but it's "small" things like that that can
break a use case completely, and that's why we usually ship alternative
implementations for everything, and why a lot of seemingly small changes
are controversial: they break non-standard use cases.
Simon
Sam Hartman
Sep 18, 2023, 3:20:03 PM9/18/23
to
>>>>> "Christoph" == Christoph Biedl <debia...@manchmal.in-ulm.de> writes:
Christoph> "cups-bsd | lpr". For lpr, that might be xpaint. For
Christoph> lprng, I have no idea. And there's little chance to know.
For a long time (possibly still) MIT's printing infrastructure required
lprng and I don't think made it easy to print with cups.
And there were some efforts there to encourage use of
popularity-contest.
So, those might be legitimate dependencies on the lprng side.
Christoph> "cups-bsd | lpr". For lpr, that might be xpaint. For
Christoph> lprng, I have no idea. And there's little chance to know.
For a long time (possibly still) MIT's printing infrastructure required
lprng and I don't think made it easy to print with cups.
And there were some efforts there to encourage use of
popularity-contest.
So, those might be legitimate dependencies on the lprng side.
Russ Allbery
Sep 18, 2023, 4:00:03 PM9/18/23
to
Simon Richter <s...@debian.org> writes:
> And yes, it is quicker for me to copy another printcap entry and swap
> out the host name than it is to find out how to authenticate to CUPS,
> set up the printer, print a test page then remove and recreate it
> because the generated "short" name I need to pipe data into lpr isn't
> short. I will definitely be looking into rlpr.
Since I wrote my original message, I noticed that rlpr is orphaned. I no
> And yes, it is quicker for me to copy another printcap entry and swap
> out the host name than it is to find out how to authenticate to CUPS,
> set up the printer, print a test page then remove and recreate it
> because the generated "short" name I need to pipe data into lpr isn't
> short. I will definitely be looking into rlpr.
longer work in an office and print things about once a year, so I no
longer use the package, but it was a lifesaver when I was working in an
office regularly and I do recommend it. If anyone else who still prints
regularly prefers the simple command-line interface, you may want to
consider adopting it, although it looks like you're likely to have to
adopt upstream as well since it seems to have disappeared.
Lisandro Damián Nicanor Pérez Meyer
Sep 20, 2023, 9:40:04 AM9/20/23
to
[^0] Interestingly I keep a copy of the last package on the archive and keeps working like a charm for my use case...
Christoph Biedl
Sep 22, 2023, 4:00:04 AM9/22/23
to
Russ Allbery wrote...
> Since I wrote my original message, I noticed that rlpr is orphaned.
If only rlpr were the only one :-|
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To name a few:
* lprng
* apsfilter(D)
* e2ps(R)
* ifhp(R)
* magicfilter(R)
* tk-brief(R)
* trueprint(R)
* xhtml2ps(S)
Plus those NMU-only-maintained packages where the maintainer is probably
MIA.
That's not surprising: lpr is an old technology, it may be simple but it
has quirks. People moved on, and if they cared a little, they let go.
(...)
> If anyone else who still prints
> regularly prefers the simple command-line interface, you may want to
> consider adopting it, although it looks like you're likely to have to
> adopt upstream as well since it seems to have disappeared.
Dead upstream applies as well to most of the packages listed above. And
that brings me to another, bigger question:
Do we provide our users a good service if we keep such zombies alive
for such a long time?
What I'm trying to say: All the maintenance that happens to such
packages is on an emergency base. If some changes (policy, debhelper,
stricter gcc checks, etc.) trigger RC bugs, someone might do the
necessary adjustments, also because it's often a low-hanging fruit. But
regular care does not happen, and after a few years it shows.
Plus, most of that code is in C, and I take the liberty to state they
all have security issues. They are just unknown, because no one bothered
to take a closer look. But these bugs exist simply because twenty and
more years ago, secure programming wasn't that common.
When kicking isdnutils out of Debian (since Linux kernel hat dropped the
support) I coined the phrase that Debian is not a museum. The lpr/lprng
area feels like it.
On the other hand, becoming museal is a natural result of how we do
things in Debian: Packages are kept alive as long as one single person
cares, while their interest might rather be eliminating RC bugs than the
actual functionality. And proposing a cleanup like in this thread
reliably triggers negative reactions of a few people who want to keep
it.
Without an external limitation (mostly specific hardware) it's hard to
draw a line when it's obviously the time to remove near-dead packages,
at least from the stable releases. I don't have a good idea either what
to do here. I doubt simple rules will really work out, rules like that
one I had in mind "Packages are removed from testing once they have been
orphaned/last maintainer-uploaded more than five years ago". And please
don't promote that, it's obviously flawed. But I'm left with a bad
feeling how things currently are.
Chri- "Might do an abandonware BoF at next DebConf" stoph
> Since I wrote my original message, I noticed that rlpr is orphaned.
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To name a few:
* lprng
* apsfilter(D)
* e2ps(R)
* ifhp(R)
* magicfilter(R)
* tk-brief(R)
* trueprint(R)
* xhtml2ps(S)
Plus those NMU-only-maintained packages where the maintainer is probably
MIA.
That's not surprising: lpr is an old technology, it may be simple but it
has quirks. People moved on, and if they cared a little, they let go.
(...)
> If anyone else who still prints
> regularly prefers the simple command-line interface, you may want to
> consider adopting it, although it looks like you're likely to have to
> adopt upstream as well since it seems to have disappeared.
that brings me to another, bigger question:
Do we provide our users a good service if we keep such zombies alive
for such a long time?
What I'm trying to say: All the maintenance that happens to such
packages is on an emergency base. If some changes (policy, debhelper,
stricter gcc checks, etc.) trigger RC bugs, someone might do the
necessary adjustments, also because it's often a low-hanging fruit. But
regular care does not happen, and after a few years it shows.
Plus, most of that code is in C, and I take the liberty to state they
all have security issues. They are just unknown, because no one bothered
to take a closer look. But these bugs exist simply because twenty and
more years ago, secure programming wasn't that common.
When kicking isdnutils out of Debian (since Linux kernel hat dropped the
support) I coined the phrase that Debian is not a museum. The lpr/lprng
area feels like it.
On the other hand, becoming museal is a natural result of how we do
things in Debian: Packages are kept alive as long as one single person
cares, while their interest might rather be eliminating RC bugs than the
actual functionality. And proposing a cleanup like in this thread
reliably triggers negative reactions of a few people who want to keep
it.
Without an external limitation (mostly specific hardware) it's hard to
draw a line when it's obviously the time to remove near-dead packages,
at least from the stable releases. I don't have a good idea either what
to do here. I doubt simple rules will really work out, rules like that
one I had in mind "Packages are removed from testing once they have been
orphaned/last maintainer-uploaded more than five years ago". And please
don't promote that, it's obviously flawed. But I'm left with a bad
feeling how things currently are.
Chri- "Might do an abandonware BoF at next DebConf" stoph
Simon Richter
Sep 22, 2023, 10:10:04 AM9/22/23
to
Hi,
On 9/22/23 16:41, Christoph Biedl wrote:
> That's not surprising: lpr is an old technology, it may be simple but it
> has quirks. People moved on, and if they cared a little, they let go.
Erm. We're talking about printers here. lpr is the protocol with the
fewest quirks.
I agree that the desktop users have moved on, and they will move on to
whatever we present them as default next.
But I also think there are quite a few installations that still use
these packages, and where people don't have much of an issue with the
packages being effectively NMU-maintained, because their system works,
and change only brings uncertainty -- especially if it is change towards
something that is "actively" maintained and constantly updated.
My suspicion is that a lot of these installations will have a heavy
amount of homebrew scripting added to them, so supporting them from a
newer printing system would mean creating a bug-compatible emulation,
which we can all agree is a forever maintenance burden unless you also
have a plan to migrate these users to a legacy-free environment.
> Do we provide our users a good service if we keep such zombies alive
> for such a long time?
Yes and no. We're providing a better service than pulling the rug under
the users, but we could do better by communicating that these packages
are in need of new maintainers instead of waiting for them to bit-rot to
a point where we have an excuse to remove them -- because all we're
doing that way is justify the rug pull, but the impact for the users
isn't minimized.
> Plus, most of that code is in C, and I take the liberty to state they
> all have security issues. They are just unknown, because no one bothered
> to take a closer look. But these bugs exist simply because twenty and
> more years ago, secure programming wasn't that common.
It is simple, straightforward code with a service record of over twenty
years, and I remember that we had security researchers back then and
there were several advisories on bugtraq for lprng.
> Without an external limitation (mostly specific hardware) it's hard to
> draw a line when it's obviously the time to remove near-dead packages,
> at least from the stable releases. I don't have a good idea either what
> to do here.
Same. I think that it cannot be solved on a per-package basis, instead
we might need infrastructure.
One thing I'd think might help would be a tag in the package database
that is derived from WNPP status, which would allow the summary output
at the end of installs also list packages that are installed that are
currently in RFA or O state.
I believe we used to have a tool for that in Debian, but almost no one
had it installed because it had additional overhead, making it pointless.
Simon
On 9/22/23 16:41, Christoph Biedl wrote:
> That's not surprising: lpr is an old technology, it may be simple but it
> has quirks. People moved on, and if they cared a little, they let go.
fewest quirks.
I agree that the desktop users have moved on, and they will move on to
whatever we present them as default next.
But I also think there are quite a few installations that still use
these packages, and where people don't have much of an issue with the
packages being effectively NMU-maintained, because their system works,
and change only brings uncertainty -- especially if it is change towards
something that is "actively" maintained and constantly updated.
My suspicion is that a lot of these installations will have a heavy
amount of homebrew scripting added to them, so supporting them from a
newer printing system would mean creating a bug-compatible emulation,
which we can all agree is a forever maintenance burden unless you also
have a plan to migrate these users to a legacy-free environment.
> Do we provide our users a good service if we keep such zombies alive
> for such a long time?
the users, but we could do better by communicating that these packages
are in need of new maintainers instead of waiting for them to bit-rot to
a point where we have an excuse to remove them -- because all we're
doing that way is justify the rug pull, but the impact for the users
isn't minimized.
> Plus, most of that code is in C, and I take the liberty to state they
> all have security issues. They are just unknown, because no one bothered
> to take a closer look. But these bugs exist simply because twenty and
> more years ago, secure programming wasn't that common.
years, and I remember that we had security researchers back then and
there were several advisories on bugtraq for lprng.
> Without an external limitation (mostly specific hardware) it's hard to
> draw a line when it's obviously the time to remove near-dead packages,
> at least from the stable releases. I don't have a good idea either what
> to do here.
we might need infrastructure.
One thing I'd think might help would be a tag in the package database
that is derived from WNPP status, which would allow the summary output
at the end of installs also list packages that are installed that are
currently in RFA or O state.
I believe we used to have a tool for that in Debian, but almost no one
had it installed because it had additional overhead, making it pointless.
Simon
Theodore Ts'o
Sep 22, 2023, 12:10:04 PM9/22/23
to
On Fri, Sep 22, 2023 at 11:07:39PM +0900, Simon Richter wrote:
> Yes and no. We're providing a better service than pulling the rug under the
> users, but we could do better by communicating that these packages are in
> need of new maintainers instead of waiting for them to bit-rot to a point
> where we have an excuse to remove them -- because all we're doing that way
> is justify the rug pull, but the impact for the users isn't minimized.
There are two things that we can call for, and we probably should try
> Yes and no. We're providing a better service than pulling the rug under the
> users, but we could do better by communicating that these packages are in
> need of new maintainers instead of waiting for them to bit-rot to a point
> where we have an excuse to remove them -- because all we're doing that way
> is justify the rug pull, but the impact for the users isn't minimized.
to do both. The first is making sure that we have an active *Debian*
maintainer. The other is to see if we can find an *Upstream*
maintainer. And for that, we can take a look at a wider set of
potential maintainers. For example, in the case of rlpr, it also is
packaged by FreeBSD and NetBSD. So perhaps there are some joint
upstream collaboration that could be done with folks from different
distibutions, or even different OS's.
Just a thought,
- Ted
Gioele Barabucci
Sep 23, 2023, 2:40:04 AM9/23/23
to
On 22/09/23 09:41, Christoph Biedl wrote:
> I doubt simple rules will really work out, rules like that
> one I had in mind "Packages are removed from testing once they have been
> orphaned/last maintainer-uploaded more than five years ago".
Maybe something more nuanced may work.
> I doubt simple rules will really work out, rules like that
> one I had in mind "Packages are removed from testing once they have been
> orphaned/last maintainer-uploaded more than five years ago".
For example: packages are removed from testing if:
- have been orphaned/last maintainer-uploaded more than 2 releases ago,
- have no autopkgtests OR autopkgtests fail OR are not
lintian/piuparts-clean.
Regards,
--
Gioele Barabucci
Thorsten Alteholz
Sep 24, 2023, 1:40:04 PM9/24/23
to
Thanks to all of you for your insights and experiences.
So I guess those lpr/lpd packages should stay within Debian and should be
maintained by the debian-printing team.
Thorsten
So I guess those lpr/lpd packages should stay within Debian and should be
maintained by the debian-printing team.
Thorsten
Simon Richter
Sep 24, 2023, 11:10:04 PM9/24/23
to
Hi,
On 9/23/23 12:10, Paul Wise wrote:
> You may be thinking of how-can-i-help, which is recommended to every
> new person who asks about how to contribute to Debian.
> There is also the older wnpp-alert in devscripts.
What I'd like to see is something like
Scanning processes...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on
this host.
No installed packages are looking for a new maintainer.
And ideally, that check would be quick and use information already on
the system at this point, maybe a supplemental file under indices/ that
can be downloaded during an update.
Simon
On 9/23/23 12:10, Paul Wise wrote:
> You may be thinking of how-can-i-help, which is recommended to every
> new person who asks about how to contribute to Debian.
> There is also the older wnpp-alert in devscripts.
What I'd like to see is something like
Scanning processes...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on
this host.
No installed packages are looking for a new maintainer.
And ideally, that check would be quick and use information already on
the system at this point, maybe a supplemental file under indices/ that
can be downloaded during an update.
Simon
Simon Richter
Sep 25, 2023, 6:20:05 AM9/25/23
to
Hi,
On 9/25/23 14:08, Paul Wise wrote:
> The problem with that approach is that the help needed information
> changes independently to packages, so the information will get very out
> of date in between point releases, which is why how-can-i-help does
> online checks. If desired, it would be easy to have an apt update hook
> that would download the data from UDD so that how-can-i-help can work
> offline when the network is available.
Yes, that's why I thought of using indices/ -- there are already
Maintainers and Uploaders files in there that I'd expect are also meant
to change independently from Packages. The indices/ directory seems to
be available on most if not all mirrors as well, so putting it there
would not put unnecessary strain on UDD.
My proposal is to display the list of RFA/O packages installed on the
system by default as part of the after-installation summary, because we
currently have no way of reaching users of at-risk packages before the
package is removed, and I would like to change that.
Simon
On 9/25/23 14:08, Paul Wise wrote:
> The problem with that approach is that the help needed information
> changes independently to packages, so the information will get very out
> of date in between point releases, which is why how-can-i-help does
> online checks. If desired, it would be easy to have an apt update hook
> that would download the data from UDD so that how-can-i-help can work
> offline when the network is available.
Yes, that's why I thought of using indices/ -- there are already
Maintainers and Uploaders files in there that I'd expect are also meant
to change independently from Packages. The indices/ directory seems to
be available on most if not all mirrors as well, so putting it there
would not put unnecessary strain on UDD.
My proposal is to display the list of RFA/O packages installed on the
system by default as part of the after-installation summary, because we
currently have no way of reaching users of at-risk packages before the
package is removed, and I would like to change that.
Simon
Wookey
Sep 25, 2023, 8:40:04 AM9/25/23
to
For example, the very useful package ncdu (which I just sponsored an
NMU upload of - 1.19 is currently in DELAYED) would fail this test.
https://tracker.debian.org/pkg/ncdu
It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors. Upstream even took debian patches in the last release
so there are now no patches, which is about as good as things get for
mature software.
Only-NMU uploads for some years is quite a common pattern and whilst
sometimes it indicates the package is only getting emergency
drive-by maintainance, sometimes (like here) the thing is actually being
maintained just as it should be (just by someone who is not officially
the maintainer).
In this case looking for NMUs of new upstream versions would give the
clue that this is not just life-support. I don't know if that is a
sufficient rule? Repeated NMUs by one person is also a clue. As you
say something 'more nuanced' still is needed and a useful test may
actually be quite complicated.
To get back to the wider issue: In general I like the fact that Debian
doesn't remove packages so long as they still work (so fas as we
know). It's one thing that gives users stability. (I'm still grumpy
about ipmasq being removed circa 2011, and I still use a local build
of 'bins' which was removed in 2015).
But we do end up carrying a lot of old stuff, possibly some of
which is genuinely superceded/no longer used.
And as a user I _would_ like better mechanisms to explain when
$something has been replaced by $something-else and users are expected
to move over at some point. Sometimes on upqrade a package has just
gone and it's not something you know anything about so you have no
idea if there is a replacement of some sort or what it might be
called. apt-listchanges can fill this gap, but only if you install it
(and it's kind of annoying because it interrupts the install/upgrade
process). And this only works for well-maintained packages that
actually update Debian.NEWS, not barely-maintained/unmaintained
packages. I guess you might get the info from the replacing, as
opposed to replaced package, but as with printing it's often a whole
set of stuff and it's not clear where any 'moving on' info should live.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
Gioele Barabucci
Sep 25, 2023, 9:30:04 AM9/25/23
to
On 25/09/23 14:29, Wookey wrote:
> It's actually quite well-maintained, just not by the maintainer:
> someone else has uploaded the last 3 upstream versions via
> debian-mentors.
I think this example shows the need for a level of maintainership that
> It's actually quite well-maintained, just not by the maintainer:
> someone else has uploaded the last 3 upstream versions via
> debian-mentors.
sits between "fully maintained" and "orphaned". (Or a rethinking of the
concept of "orphan packages".)
Right now in Debian there is a distinction between:
1) maintained packages (Maintainer: "foo")
and
2) orphaned packages (Maintainer: "Debian QA Group").
State 1 is the desired state of a package: somebody (a single person or
a team) looks after this package, packages and tests new releases, and
is expected to respond to inquiries (bug reports, MRs, NMUs) within a
reasonable time.
State 2 is an undesired state that should be addressed. Somebody from
the QA team (= theoretically the whole of Debian) may have a look at it
in case of transitions or RC bugs. But what Debian really desires is
that somebody will adopt this package and put their name in the
Maintainer: field.
What I think is needed is a state 3 (or 1.5) that formalizes what Wookey
described: there is an informal group of people that may take care of a
package, but they don't feel like having their names attached to it nor
want the responsibility of being the ones in charge for timely fixes or
quick replies.
The way I picture it, "state 3" packages would have something like
"Debian Caretaking Team" in the Maintainer: field (not the usual "QA
Group", and have autotests in lieu of a specific person/team that takes
care of manually testing the package.
Has such a third category already been discussed or explored?
--
Gioele Barabucci
0 new messages