* Thomas Viehmann:
I think that not shipping unmaintained and unsupported packages is a
benefit. Packages need a maintainer to enter, I think they should need
one to stay.
A real problem is that willingness to maintain a package in unstable
is not as good a predictor as you might think for
On Sun, Jan 15, 2006 at 01:07:58PM +1000, Anthony Towns wrote:
On Sat, Jan 14, 2006 at 06:00:41PM +0100, Jesus Climent wrote:
On Fri, Jan 13, 2006 at 07:31:17PM +0100, Luk Claes wrote:
and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download
Russ Allbery wrote:
Thomas Viehmann [EMAIL PROTECTED] writes:
Russ Allbery wrote:
The thing is... most of the orphaned packages are in fairly good shape.
How do you know?
Well, because at one point I went through the PTS for each one of them,
checked for filed bugs, checked lintian reports,
On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy [EMAIL PROTECTED]
was heard to say:
As stated by the Debian Policy Manual :
The Depends field should be used if the depended-on package is required
for the depending package to provide a significant amount of
functionality.
and
Russ Allbery wrote:
Thomas Viehmann [EMAIL PROTECTED] writes:
Can you elaborate on this? I'm not sure how the existence of more
packages that should be orphaned invalidates dealing with those that
presently are.
There's 169 orphaned packages today, why not do something about them?
On Sat, 14 Jan 2006, Thomas Viehmann wrote:
How do you know?
The BTS.
Most of the orphaned packages are orphaned because they're obscure and the
person who cared about the package has left the project or run out of
time. However, they are probably still working fine for people with those
On Fri, Jan 13, 2006 at 07:31:17PM +0100, Luk Claes wrote:
and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download managers.
Which is something it is not going to work.
The current intent to NMU is proposing curl | wget which doesn't need
any
Raphael Hertzog wrote:
I think that not shipping unmaintained and unsupported packages is a
benefit. Packages need a maintainer to enter, I think they should need
one to stay.
You wouldn't say that if you were a user using an orphaned package ...
Well, I've been in the situation to dig out an
Thomas Viehmann [EMAIL PROTECTED] writes:
Russ Allbery wrote:
The thing is... most of the orphaned packages are in fairly good shape.
How do you know?
Well, because at one point I went through the PTS for each one of them,
checked for filed bugs, checked lintian reports, etc. I haven't
On Sat, Jan 14, 2006 at 06:00:41PM +0100, Jesus Climent wrote:
On Fri, Jan 13, 2006 at 07:31:17PM +0100, Luk Claes wrote:
and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download managers.
Which is something it is not going to work.
Huh? What's
On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy wrote:
On Fri, Jan 13, 2006 at 04:47:33AM +1000, Anthony Towns wrote :
On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
But if you read this bug (#307833), you'd see that the maintainer
doesn't
consider it a bug,
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
That said, I do believe that if a package is unpopular enough that
nobody picks up maintaining it, even while it's orphaned, what the
prospects of the package are, and how much use it has to prolong its
life extraordinary. If you're sufficiently
Frank Küster wrote:
Hm, well, no. I do particularly care for one orphaned package,
lmodern. But since it currently doesn't have any (real) RC bugs, I have
more important things to do than adopt it on behalf of the
debian-tetex-maint list (or talking Norbert Preining into creating it
from
Thomas Viehmann [EMAIL PROTECTED] wrote:
Well, maybe the actual situation would be better reflected if one of the
interested parties adopted the package and retitled the O bug to RFA?
Sounds right...
Therefore I don't think that merely being orphaned is a good criterion
for removal;
On Fri, 13 Jan 2006, Charles Plessy wrote:
dependancy on curl. However, declaring proper dependancies for the
package is a should, not a must, so if a debian developper is free
to creating uninstallable packages if he fancies this.
Disclaimer: I am not talking about apt-file.
QA hat on
I sure
On Fri, Jan 13, 2006 at 10:39:01AM -0200, Henrique de Moraes Holschuh wrote:
On Fri, 13 Jan 2006, Charles Plessy wrote:
dependancy on curl. However, declaring proper dependancies for the
package is a should, not a must, so if a debian developper is free
to creating uninstallable packages if
Anthony Towns wrote:
On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
But if you read this bug (#307833), you'd see that the maintainer doesn't
consider it a bug, and has documented why in the README file.
It is a bug as the package is not usable without curl or wget installed.
On Thu, 12 Jan 2006, Andreas Barth wrote:
One can try to come up with some metric, yes.
However, on the other hand feel free to create a common maintained
packages team that adopts such packages :)
This may happen sooner that one may think.
The project collab-maint on alioth is actually
On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
There are technical ways to solve the problem (e.g. to depend on
wget|curl and to detect which one is available at start up).
If the mainatiner is willing to give more input than 'it is not a bug'
on what behaviour he would
Jesus Climent wrote:
On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
There are technical ways to solve the problem (e.g. to depend on
wget|curl and to detect which one is available at start up).
If the mainatiner is willing to give more input than 'it is not a bug'
on what
Thomas Viehmann [EMAIL PROTECTED] writes:
Can you elaborate on this? I'm not sure how the existence of more
packages that should be orphaned invalidates dealing with those that
presently are.
There's 169 orphaned packages today, why not do something about them?
The thing is... most of the
* Anthony Towns:
If you'd like to make suggestions about ideas that would be useful,
What about: stop threatening your fellow developers?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Florian Weimer]
What about: stop threatening your fellow developers?
Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?
Personally I believe it is time we made clear and written down
explanations on what will happen to badly maintained
also sprach Florian Weimer [EMAIL PROTECTED] [2006.01.12.1209 +0100]:
If you'd like to make suggestions about ideas that would be useful,
What about: stop threatening your fellow developers?
Thanks, Anthony, for the heads-up.
--
Please do not send copies of list mail to me; I read the
On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:
[Florian Weimer]
What about: stop threatening your fellow developers?
Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?
IMHO it isn't at all.
Personally I believe it is time we made
On Thu, Jan 12, 2006 at 12:09:04PM +0100, Florian Weimer wrote:
* Anthony Towns:
If you'd like to make suggestions about ideas that would be useful,
What about: stop threatening your fellow developers?
For instance, bug #303131 has been open since April last year, and
has had no further
On Thu, Jan 12, 2006 at 01:00:50PM +0100, Andreas Tille wrote:
On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:
[Florian Weimer]
What about: stop threatening your fellow developers?
Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?
On 1/12/06, Andreas Tille [EMAIL PROTECTED] wrote:
On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:
[Florian Weimer]
What about: stop threatening your fellow developers?
Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?
IMHO it
On Thu, 12 Jan 2006, Steve Langasek wrote:
If RC bugs go unanswered for 3 months, I agree that something should be
done; I just don't think that saying someone else should take it over is
necessarily enough. I believe we need clearer methods for handling packages
in the case that *no one* is
Hi,
first of all, thanks for taking the initiative I think the matter is too
important to be left alone just for avoiding to step on anyones toes.
Anthony Towns wrote:
Random ideas for negative consequences might include forced
orphaning by overriding maintainer fields to debian-qa, removal of
On Thu, January 12, 2006 14:23, Thomas Viehmann wrote:
Random ideas for negative consequences might include forced
orphaning by overriding maintainer fields to debian-qa, removal of
Maybe this should not only be limited to packages with RC bugs... For a
lot of packages with inactive
Thijs Kinkhorst wrote:
I very much agree that we should strive to make packages as good as
possible, but if users depend on a package and there are no real
showstoppers in it, we might do our users a better service with shipping
than with not shipping the package.
No. Shipping unsupported
On Thu, 12 Jan 2006, Thijs Kinkhorst wrote:
While the package might not be of the quality we strive to achieve within
Debian; if a bug is not release critical we consider the bug not to be
serious enough to impact the packages' releaseworthyness. This is by
definition. Even if there are many of
Thijs Kinkhorst [EMAIL PROTECTED] wrote:
On Thu, January 12, 2006 14:23, Thomas Viehmann wrote:
Random ideas for negative consequences might include forced
orphaning by overriding maintainer fields to debian-qa, removal of
Maybe this should not only be limited to packages with RC bugs... For
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?
Seconded.
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
On Thu, Jan 12, 2006 at 02:21:03PM +0100, Olaf van der Spek wrote :
...
If a maintainer would not manage to respond to an RC bug for three months
the package is obviousely not maintained and should be taken over by
somebody else, IMHO.
I wish something like that applied to all bugs.
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?
Seconded.
well, just make a list that I can just copy into my hint file.
Cheers,
On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
Of course, this is trivial, but fixing this bug (251 days old) is
also trivial. Then why complain ? I feel that it gives a bad image of
debian, when it suggests to use a broken tool while another one is being
repaired.
But if you
* Christoph Berg [EMAIL PROTECTED] [2006-01-12 16:05]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?
Seconded.
I don't think it's such a great idea (at least not done by itself).
While
* Christoph Berg [Thu, 12 Jan 2006 16:05:52 +0100]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?
Seconded.
Me too.
(jftr, http://lists.debian.org/debian-qa/2004/06/msg00176.html)
On Thu, January 12, 2006 16:02, Frank Küster wrote:
But if a rather new package in active development has many non-RC bugs,
some of them crippling upstream features, and one of them New version
N.m.o available (retitled three times meanwhile), then our users are
probably better served by
* Thomas Viehmann ([EMAIL PROTECTED]) [060112 15:56]:
Thijs Kinkhorst wrote:
I very much agree that we should strive to make packages as good as
possible, but if users depend on a package and there are no real
showstoppers in it, we might do our users a better service with shipping
than
Andreas Barth [EMAIL PROTECTED] wrote:
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?
Seconded.
well, just make a list that I can
* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from
Steinar H. Gunderson wrote:
On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
Of course, this is trivial, but fixing this bug (251 days old) is
also trivial. Then why complain ? I feel that it gives a bad image of
debian, when it suggests to use a broken tool while another one is
On Thu, 12 Jan 2006 14:23:31 +0100, Thomas Viehmann [EMAIL PROTECTED]
said:
Hi,
first of all, thanks for taking the initiative I think the matter is too
important to be left alone just for avoiding to step on anyones toes.
Anthony Towns wrote:
Random ideas for negative consequences
On Thu, Jan 12, 2006 at 04:57:46PM +0100, Steinar H. Gunderson wrote:
On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
Of course, this is trivial, but fixing this bug (251 days old) is
also trivial. Then why complain ? I feel that it gives a bad image of
debian, when it
Andreas Barth [EMAIL PROTECTED] wrote:
* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really, how about just automatically[1] removing orphaned
On Thu, Jan 12, 2006 at 03:49:08PM +0100, Andreas Tille wrote:
On Thu, 12 Jan 2006, Thijs Kinkhorst wrote:
While the package might not be of the quality we strive to achieve within
Debian; if a bug is not release critical we consider the bug not to be
serious enough to impact the packages'
Thijs Kinkhorst wrote:
While the package might not be of the quality we strive to achieve within
Debian; if a bug is not release critical we consider the bug not to be
serious enough to impact the packages' releaseworthyness. This is by
definition. Even if there are many of those bugs, they
Andrew Suffield wrote:
Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
(I've tried two or three times to invent one).
I think the
On Thu, 12 Jan 2006, Andrew Suffield wrote:
Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
(I've tried two or three times to invent
* Frank Küster ([EMAIL PROTECTED]) [060112 19:36]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
Re: Thomas Viehmann in [EMAIL PROTECTED]
Really,
also sprach Andreas Barth [EMAIL PROTECTED] [2006.01.12.2135 +0100]:
* Frank Küster ([EMAIL PROTECTED]) [060112 19:36]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
Andreas Barth [EMAIL PROTECTED] wrote:
* Christoph Berg ([EMAIL PROTECTED])
On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
However, on the other hand feel free to create a common maintained
packages team that adopts such packages :)
Isn't that pretty much what the qa team does?
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
* David Nusinow ([EMAIL PROTECTED]) [060112 21:47]:
On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
However, on the other hand feel free to create a common maintained
packages team that adopts such packages :)
Isn't that pretty much what the qa team does?
Not really. All
On Thu, Jan 12, 2006 at 09:52:13PM +0100, Andreas Barth wrote:
* David Nusinow ([EMAIL PROTECTED]) [060112 21:47]:
On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
However, on the other hand feel free to create a common maintained
packages team that adopts such packages :)
Jeroen van Wolffelaar [EMAIL PROTECTED] writes:
Well, that's current practice, but nobody is stopping anyone to give a
little bit more care into QA packages...
The hardest problem, speaking as someone who wanted to do that and who
still wants to do that as soon as I can find time, is that many
On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
But if you read this bug (#307833), you'd see that the maintainer doesn't
consider it a bug, and has documented why in the README file.
It is a bug as the package is not usable without curl or wget installed.
Though, I give him a
On Thu, Jan 12, 2006 at 03:05:31PM -0500, Joey Hess wrote:
I think that the RC bug metric is overated and doesn't consider these
kinds of effects that end up pulling down the overall usability of
Debian.
Yeah, the RC bug metric is meant to just be for the trivial bugs that
we get rid of
On Thu, Jan 12, 2006 at 09:15:25PM +0100, Andreas Tille wrote:
On the other hand I can not really
believe that it is impossible to touch glibc and dpkg bugs with some
kind of status (I'm working on it, Help would be welcome in this
particular task, ...).
I don't think it's impossible, and it
On Thu, Jan 12, 2006 at 03:11:58PM -0500, Joey Hess wrote:
Andrew Suffield wrote:
Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
On Fri, Jan 13, 2006 at 04:47:33AM +1000, Anthony Towns wrote :
On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
But if you read this bug (#307833), you'd see that the maintainer doesn't
consider it a bug, and has documented why in the README file.
It is a bug as the package is
63 matches
Mail list logo
