Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 29 Dec 2001, Thomas Bushnell, BSG wrote:

> Colin Watson <[EMAIL PROTECTED]> writes:
>
> > > But I suspect that eight people is nowhere near enough people.  Maybe
> > > I could join...
> >
> > Please do! Adrian Bunk posted a proposal a month or so ago for QA
> > organization in the future, containing a good summary of the kinds of
> > things people can work on.
>
> So one problem is that I looked at the To Do List on the QA pages, and
> it has one item.  I looked at the release critical bugs on important
> packages, and they are all small things that can only be effectively
> solved by the maintainer (fixing minor typo problems, etc).

look at http://base.debian.net/ and http://standard.debian.net/

There are rc bugs listed that are more than just trivial.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Colin Watson <[EMAIL PROTECTED]> writes:

> > But I suspect that eight people is nowhere near enough people.  Maybe
> > I could join...
> 
> Please do! Adrian Bunk posted a proposal a month or so ago for QA
> organization in the future, containing a good summary of the kinds of
> things people can work on.

So one problem is that I looked at the To Do List on the QA pages, and
it has one item.  I looked at the release critical bugs on important
packages, and they are all small things that can only be effectively
solved by the maintainer (fixing minor typo problems, etc).  

I'm sure there's lots of work to be done, but it's not clear what
exactly it is.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

This is why I labeled it as "if it were me". Of course I tend to 
take a harder view of whats the programmers responsibilities when releasing 
a package than most people. Maybe it has to do with my overbuilt sense of 
getting things done right and not being blamed for breaks too frequesntly. :)


On Fri, Dec 28, 2001 at 08:09:54AM -0700, Bdale Garbee wrote:
> [EMAIL PROTECTED] (Brian Wolfe) writes:
> 
> > Actualy, I believe that the mkisofs maintainer should have seen that a 
> > new option was created and notified the maintainers of anything that 
> > depended on mkisofs ...
> 
> That's pushing it, I think.  I've had several experiences as a maintainer
> where something in an upstream package changed that seemed insignificant to
> me, but which broke some other package that depended on mine.  These events
> aren't a big deal if everyone is "engaged" and bugs are getting addressed as
> they are reported.
> 
> Let's stick to the main problem.
> 
> Bdale
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Bdale Garbee]

[EMAIL PROTECTED] (Brian Wolfe) writes:

> Actualy, I believe that the mkisofs maintainer should have seen that a 
> new option was created and notified the maintainers of anything that 
> depended on mkisofs ...

That's pushing it, I think.  I've had several experiences as a maintainer
where something in an upstream package changed that seemed insignificant to
me, but which broke some other package that depended on mine.  These events
aren't a big deal if everyone is "engaged" and bugs are getting addressed as
they are reported.

Let's stick to the main problem.

Bdale

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> Maybe we need a way to make being on the QA team a sexy job, just like
> maintaining glibc or the kernel or X is.

What about dpkg or apt?

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

On Thu, Dec 27, 2001 at 04:24:06PM +, Mark Brown wrote:
> On Thu, Dec 27, 2001 at 04:14:46PM +0200, Juha J?ykk? wrote:
> 
> >   I wonder how this could happen in the first place: if CDRToaster
> > depended properly on mkisofs version <= whatever, then upgrading
> > mkisofs should remove CDRToaster.
> 
> Why should CDRToaster expect mkisofs to randomly change its interface?
> 

Actualy, I believe that the mkisofs maintainer should have seen that a 
new option was created and notified the maintainers of anything that depended 
on mkisofs, IF the change was something that broken compatibility with 
backwards versions of mkisofs.

At least this is what *I* would have done if I were the maintainer of 
mkisofs



-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpQwgNifvFW7.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Mark Brown]

On Thu, Dec 27, 2001 at 04:14:46PM +0200, Juha Jäykkä wrote:

>   I wonder how this could happen in the first place: if CDRToaster
> depended properly on mkisofs version <= whatever, then upgrading
> mkisofs should remove CDRToaster.

Why should CDRToaster expect mkisofs to randomly change its interface?

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp613IKcbrWP.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Mark Brown]

On Thu, Dec 27, 2001 at 05:44:38AM -0600, Colin Watson wrote:

[Discussing removal of bitrotted packages]
> Usually we only get involved in discussions like this for orphaned
> packages, at least so far.

Back when the committee was alive it (or at least some members of it)
did do some stuff along those lines.  A couple of the packages I've
taken over I took over after that sort of discussion.  It was a bit
rubber stampish but then I was offering to take the packages concerned
over which is a much smaller change than removing them from the
distribution.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp7ArDOjiYX2.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Branden Robinson]

On Wed, Dec 26, 2001 at 03:02:48PM -0800, Thomas Bushnell, BSG wrote:
> Maybe we need a way to make being on the QA team a sexy job, just like
> maintaining glibc or the kernel or X is.

Eh?  In my experience the maintainers of these packages get nothing but
grief, sometimes from each other.  :)

-- 
G. Branden Robinson| If God had intended for man to go
Debian GNU/Linux   | about naked, we would have been
[EMAIL PROTECTED] | born that way.
http://people.debian.org/~branden/ |


pgpFcN49o4dT5.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Juha Jäykkä]

> cause the package to fail more and more in more common usage. Debian updated
> it's version of mkisofs, and thus IT broke CDRToaster. As such this is now in

  I wonder how this could happen in the first place: if CDRToaster
depended properly on mkisofs version <= whatever, then upgrading
mkisofs should remove CDRToaster.
  Another thing I must ask: did those people you (Brian) claimed chose
RedHat because "debian packages are so old" choose RH because _potato_
is so old or because packages in woody/sid are too old?
  Packages in potato are really old, but that is by policy. And
_please_ do not change that policy! Not changing stable release vesion
numbers is perhaps the greatest asset Debian has. Look at RedHat or
SuSE, for example, they release a new "version" every few months (and
at least SuSE 7.2 does not provide a clean way to upgrade). That
assures they can release new versions more frequently than Debian,
_but_ it also means a lot more maintenance both on the distributor's
side (fixing bugs in several versions of a software - possibly with
different libraries even) and on user's side.
  A nice way to get those people, who claim Debian is so old (which is
true), to use Debian could be this: Add one distribution to the
current stable-testing-unstable. For example
stable-bleeding_edge-testing-unstable. The new distro would basically
be a snapshot of testing or unstable with official boot disks and CD
images. It could get minor version numbers and be released, for
example, twice a year.
  This might be bad for Debian's reputation in some people's minds but
in my opinion that would simply be answering the users' call. No sane
person (I think) would want such a snapshot on a server - especially
since there would be no security updates - but many people seem to want
new and fancy, bleeding edge programs on their workstations.
Especially since stable's XFree has problems with the newer video cards
and probably USB, too.
  Just a few thoughts...

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| home: http://www.utu.fi/~juolja/  |
 ---

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Colin Watson]

On Wed, Dec 26, 2001 at 03:02:48PM -0800, Thomas Bushnell, BSG wrote:
> Seems to me that we came up with a solution for this problem a while
> ago: the Debian QA team.  Right now it has eight people, and an
> overwhelming workload.

You both exaggerate and understate things here.
http://www.debian.org/intro/organization lists eight people, but they
were actually the QA committee (which IIRC decided to disband itself a
couple of months ago because it was redundant). The QA group itself has
several more people involved.

On the other hand, as usual, not everybody's active at any one time. At
the moment it looks like most of the recent work on orphaned packages
has been done by Matej Vela and to a lesser extent me, but this varies
from month to month. Other people have been working on other issues. And
you're right that the workload is to all intents and purposes infinite.

> I think a QA team is the right thing here; presumably it can have the
> discussions about whether particular packages are so stale they should
> be removed.

Indeed, we sometimes do. Martin Michlmayr is often involved with this,
as it links up well with looking for missing-in-action developers, and
Bas Zoetekouw has done some work recently which may lead into this.

Usually we only get involved in discussions like this for orphaned
packages, at least so far.

> But I suspect that eight people is nowhere near enough people.  Maybe
> I could join...

Please do! Adrian Bunk posted a proposal a month or so ago for QA
organization in the future, containing a good summary of the kinds of
things people can work on.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

On Wed, Dec 26, 2001 at 11:07:20PM -0600, Adam Heath wrote:
> On 26 Dec 2001, Thomas Bushnell, BSG wrote:
> 
> > Um, if it doesn't work for the version of mkisofs in woody, then it is
> > a critical bug as far as woody is concerned.
> 
> That may be true.  But someone who has potato installed, and does a partial
> upgrade, might not have the new version of mkisofs.
> 
> Seriously, if a mkisofs upgrade broke software that used it, the only way to
> *guarantee* that partial upgrades don't cause software to break, is for
> mkisofs to conflict with the older versions of packages that used it.

Well now, that certainly sounds like it's a conflict to me. :)

> 
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> Adam Heath <[EMAIL PROTECTED]> writes:
>
> > Of course, there are hints that there is another segfault bug out there, 
> > with
> > the latest version in woody.  It's not repeatable, however.  Also, on this
> > note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
> > with regard to buffer overruns, and the like.
>
> That also points out that dpkg is not a good example; some packages
> are sufficiently critical that conservatism in bug fixing is
> important.

Yes, it does.  See my uploads of 1.9.11 thru 1.9.14.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> On 26 Dec 2001, Thomas Bushnell, BSG wrote:
> 
> > So, picking one at random, why is bug 9085 still open?
> 
> Because that's a cosmetic issue.  There are more important things to work on,
> like fixing bugs, and implementing features that we will need down the road.

The reason I didn't think it necessary to say more in the question
above was because it seemed obvious to me that either:

1) A cosmetic issue takes only a few seconds to fix, or
2) It should be a wishlist item.

Now, my point isn't "beat on dpkg" (and indeed, 'twasn't I that
brought it up IIRC).  But my point is that if something has sat there
for over four years, *something* somewhere is not working.  It seems
obvious to me that the dpkg maintainers are doing a fabulous job.  So
the problem isn't in them.

But there still is *some* kind of problem.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> Um, if it doesn't work for the version of mkisofs in woody, then it is
> a critical bug as far as woody is concerned.

That may be true.  But someone who has potato installed, and does a partial
upgrade, might not have the new version of mkisofs.

Seriously, if a mkisofs upgrade broke software that used it, the only way to
*guarantee* that partial upgrades don't cause software to break, is for
mkisofs to conflict with the older versions of packages that used it.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> So, picking one at random, why is bug 9085 still open?

Because that's a cosmetic issue.  There are more important things to work on,
like fixing bugs, and implementing features that we will need down the road.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> Of course, there are hints that there is another segfault bug out there, with
> the latest version in woody.  It's not repeatable, however.  Also, on this
> note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
> with regard to buffer overruns, and the like.

That also points out that dpkg is not a good example; some packages
are sufficiently critical that conservatism in bug fixing is
important.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On Thu, 27 Dec 2001, Anthony Towns wrote:

> On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote:
> > Anthony Towns  writes:
> > > Oh god no. Please no. Inflating bug severeties just makes it harder to
> > > do releases; if there's a problem with normal bugs being ignored (and,
> > > IMO, there is), it needs to be addressed directly, not worked around by
> > > filing everything as important or higher.
> > But I think the point here is that the presence of a jillion normal
> > bugs, unaddressed for years, constitutes a release-critical bug, and
> > we want some way to filter such packages out of the release.  At
> > least, that's what I thought the idea was about.

> No, it's not that simple. dpkg is perfectly releasable right now, in spite
> of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
> it's even an example of a well maintained package.

Both Wichert and I go in spurts.  Once about every 4 months or so, it seems.
We usually don't do it at the same time either.

I do tend to read all the dpkg bugs once every 4 months.  I tend to fix bugs
that are similiar each time I do so.  My last go at dpkg I fixed most
outstanding install-info bugs(they should all be marked pending(I love that
tag)).

Of course, there are hints that there is another segfault bug out there, with
the latest version in woody.  It's not repeatable, however.  Also, on this
note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
with regard to buffer overruns, and the like.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> On Wed, 26 Dec 2001, Brian Wolfe wrote:
> 
> > It's a normal bug at the minimal. I couldn't get CDRToaster to even do
> > a simple burn of a single directory! So I think the bug description would be
> > more like "CDRToaster has failed to follow the evolution of mkisofs's 
> > command
> > line parameters. As a result many fetures that CDRToaster purports to have 
> > now
> > fail to work at all." As such this is now a critical or at minimal important
> > bug.
> 
> The package works for some people(those who have the old version of mkisofs
> installed).  This makes the priority of the bug important.

Um, if it doesn't work for the version of mkisofs in woody, then it is
a critical bug as far as woody is concerned.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On Wed, 26 Dec 2001, Brian Wolfe wrote:

>   It's a normal bug at the minimal. I couldn't get CDRToaster to even do
> a simple burn of a single directory! So I think the bug description would be
> more like "CDRToaster has failed to follow the evolution of mkisofs's command
> line parameters. As a result many fetures that CDRToaster purports to have now
> fail to work at all." As such this is now a critical or at minimal important
> bug.

The package works for some people(those who have the old version of mkisofs
installed).  This makes the priority of the bug important.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 06:39:34PM -0800, Thomas Bushnell, BSG wrote:
> Wichert Akkerman <[EMAIL PROTECTED]> writes:
> > > So, picking one at random, why is bug 9085 still open?  
> > Because since we started working on it again we've had lots
> > more pressing things to look into that a bug like #9085?
> Perhaps the metric is not "are there bugs that have gone unattended
> for four years", but "are there no bugs that have gotten any attention
> for years".  The latter test might well be better.

It's more a matter of triage, IMO: ie, "if the more important bugs
haven't gotten any attention for some time", then you can assume the
package isn't being maintained well.

If there are just lots of less important bugs that aren't getting attention,
then we're either short on manpower, or not using the manpower we have as
well as we might.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously Thomas Bushnell, BSG wrote:
> > So, picking one at random, why is bug 9085 still open?  
> 
> Because since we started working on it again we've had lots
> more pressing things to look into that a bug like #9085?

So I picked that bug totally at random; and my intention is not to
poke at the hard-working dpkg maintainers.

Perhaps the metric is not "are there bugs that have gone unattended
for four years", but "are there no bugs that have gotten any attention
for years".  The latter test might well be better.

Still, if there are bugs that have gone unattended for four years,
then *something* is broken, but not necessarily something that the
dpkg maintainers can fix.  Perhaps the hard-working (overworked) QA
team can also have a priority list of very-old bugs.  Or perhaps there
need to be more people working on such packages.  I don't know.

What I see is just a symptom; I have no certain diagnosis.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Wichert Akkerman]

Previously Thomas Bushnell, BSG wrote:
> So, picking one at random, why is bug 9085 still open?  

Because since we started working on it again we've had lots
more pressing things to look into that a bug like #9085?

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Anthony Towns  writes:

> No, it's not that simple. dpkg is perfectly releasable right now, in spite
> of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
> it's even an example of a well maintained package.

So, picking one at random, why is bug 9085 still open?  

> There's a place for bugs like "This unmaintained package is not release
> quality anymore", but I don't think it's really a good idea for users
> in general to be filing them: you need to check the package really
> is unmaintained and make sure that no one else is interested in doing
> anything about it before you worry about it, at least, which is a job
> for developers (ideally the -qa team).

I think I do agree about this part.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote:
> Anthony Towns  writes:
> > Oh god no. Please no. Inflating bug severeties just makes it harder to
> > do releases; if there's a problem with normal bugs being ignored (and,
> > IMO, there is), it needs to be addressed directly, not worked around by
> > filing everything as important or higher.
> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug, and
> we want some way to filter such packages out of the release.  At
> least, that's what I thought the idea was about.

No, it's not that simple. dpkg is perfectly releasable right now, in spite
of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
it's even an example of a well maintained package.

There's a place for bugs like "This unmaintained package is not release
quality anymore", but I don't think it's really a good idea for users
in general to be filing them: you need to check the package really
is unmaintained and make sure that no one else is interested in doing
anything about it before you worry about it, at least, which is a job
for developers (ideally the -qa team).

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf


pgp83o7K7P354.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Olsen]

On Wed, Dec 26, 2001 at 03:37:15PM -0800, Thomas Bushnell, BSG wrote:
> Adam Olsen <[EMAIL PROTECTED]> writes:
> 
> > > But I suspect that eight people is nowhere near enough people.  Maybe
> > > I could join...  Indeed, maybe the problem would go away if everyone who
> > > has posted a suggestion in this thread joined the QA team and started 
> > > work.
> > 
> > I'd be more than willing to help, but I'm not a debian developer.
> > (heh, anybody live in edmonton alberta?)
> 
> You don't have to be a developer to be a QA person; see qa.debian.org
> for details.
> 
> And there are currently two developers who live in Edmonton.

Oh, err umm... I need more excuses.  Anybody got any suggestions? ;)

-- 
Adam Olsen, aka Rhamphoryncus

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Olsen <[EMAIL PROTECTED]> writes:

> > But I suspect that eight people is nowhere near enough people.  Maybe
> > I could join...  Indeed, maybe the problem would go away if everyone who
> > has posted a suggestion in this thread joined the QA team and started work.
> 
> I'd be more than willing to help, but I'm not a debian developer.
> (heh, anybody live in edmonton alberta?)

You don't have to be a developer to be a QA person; see qa.debian.org
for details.

And there are currently two developers who live in Edmonton.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Olsen <[EMAIL PROTECTED]> writes:

> I HOPE that's a joke.  Mentioning the X maintainer (*cough* no names
> *cough) in the same sentance as "sexy" is just wrong imnsho.

I dunno, he looks pretty nice in the pic on his web page. :)

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Nathan E Norman]

On Wed, Dec 26, 2001 at 04:52:39PM -0600, Brian Wolfe wrote:

[ a bunch of stuff I didn't read, because ... ]

If you're going to participate on the debian mailing lists, consider
doing so with a mailer that understands and honors the
Mail-Followup-To: header (yes, I know it's not an "official" standard,
but it's considered a standard on debian lists).

I don't need copies of list mail unless I ask for them.  I read the
lists.  Please don't Cc: me on list mail.  Etc.

[ rest of rant deleted ]

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpqwCUcCF1xZ.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Olsen]

On Wed, Dec 26, 2001 at 03:02:48PM -0800, Thomas Bushnell, BSG wrote:
> 
> Seems to me that we came up with a solution for this problem a while
> ago: the Debian QA team.  Right now it has eight people, and an
> overwhelming workload.  I think a QA team is the right thing here;
> presumably it can have the discussions about whether particular
> packages are so stale they should be removed.

I agree, but I was trying to get more obvious mechanisms for them to
use.

> 
> But I suspect that eight people is nowhere near enough people.  Maybe
> I could join...  Indeed, maybe the problem would go away if everyone who
> has posted a suggestion in this thread joined the QA team and started work.

I'd be more than willing to help, but I'm not a debian developer.
(heh, anybody live in edmonton alberta?)

> 
> Maybe we need a way to make being on the QA team a sexy job, just like
> maintaining glibc or the kernel or X is.

I HOPE that's a joke.  Mentioning the X maintainer (*cough* no names
*cough) in the same sentance as "sexy" is just wrong imnsho.

-- 
Adam Olsen, aka Rhamphoryncus

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Seems to me that we came up with a solution for this problem a while
ago: the Debian QA team.  Right now it has eight people, and an
overwhelming workload.  I think a QA team is the right thing here;
presumably it can have the discussions about whether particular
packages are so stale they should be removed.

But I suspect that eight people is nowhere near enough people.  Maybe
I could join...  Indeed, maybe the problem would go away if everyone who
has posted a suggestion in this thread joined the QA team and started work.

Maybe we need a way to make being on the QA team a sexy job, just like
maintaining glibc or the kernel or X is.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

No, but you can do, like you said, and deny them a new package unless 
they take up an older one that matches thier area of expertiece.

For example, (still picking on CDRToaster as an example only at this 
time) if I were the maintainer of mkisofs, and I updated it, thus breaking 
CDRTOaster. then a month or two later I wanted to add a new package that 
debian allready has a functional equivilant of, the maintainer coordinator
(does such a person exist?) would look and see that CDRToaster is DOA upstream, 
and it's pakager hasn't marked it as such and either retired it, or replaced 
it with another package, then the mkisofs maintainer would be asked to adopt 
the CDRToaster if they had the capability to do so.

Now, this is just a theoretical situation, so take it with a grain of 
salt and look more at the idea behind the theory. :) Not saying it's THE 
solution, just an idea of how to keep people from leaving cruft all over, and
encouraging maintainers to check up on packages that require/strongly-reccomend
thier package that they updated. (note, this obviously can't be applied to
core packages very realisticly, just for optional/fringe stuff thats poping up)


On Wed, Dec 26, 2001 at 04:22:42PM -0600, Nathan E Norman wrote:
> On Wed, Dec 26, 2001 at 03:49:11PM -0600, Brian Wolfe wrote:
> > Instead of many new packages, why not make people pick up the orphaned 
> > stuff, and find replacements or adopt packages that have been DOA upstream?
> 
> In a volunteer organization, you can't _make_ people do anything.  You
> can encourage them to do things, or forbid them from doing things, but
> you can't say "Hey Hans, you need to do this project, and Bill needs
> to do that project".  Corporations work that way, Debian does not.
> 
> -- 
> Nathan Norman - Staff Engineer | A good plan today is better
> Micromuse Ltd. | than a perfect plan tomorrow.
> mailto:[EMAIL PROTECTED]   |   -- Patton



-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpjWBbRXK2gK.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Nathan E Norman]

On Wed, Dec 26, 2001 at 03:49:11PM -0600, Brian Wolfe wrote:
>   Instead of many new packages, why not make people pick up the orphaned 
> stuff, and find replacements or adopt packages that have been DOA upstream?

In a volunteer organization, you can't _make_ people do anything.  You
can encourage them to do things, or forbid them from doing things, but
you can't say "Hey Hans, you need to do this project, and Bill needs
to do that project".  Corporations work that way, Debian does not.

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpAcJqKV5Yhf.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Ok, here is something to look at. How many NEW packages are there in 
the last 2 months? How many of them could have been saved for later due to an 
alternate allready existing? How many don't add a whole lot of value to debian?

Instead of many new packages, why not make people pick up the orphaned 
stuff, and find replacements or adopt packages that have been DOA upstream?

NOTE: I haven't looked at this kind of stats before, nor do I know how 
to find this kind of information. dwn used to list at least 10 to 30 NEW 
things per week. and meanwhile the orphan count rose quickly...

-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

It's a normal bug at the minimal. I couldn't get CDRToaster to even do 
a simple burn of a single directory! So I think the bug description would be 
more like "CDRToaster has failed to follow the evolution of mkisofs's command 
line parameters. As a result many fetures that CDRToaster purports to have now 
fail to work at all." As such this is now a critical or at minimal important 
bug.

On Wed, Dec 26, 2001 at 09:56:10PM +1000, Anthony Towns wrote:
> On Wed, Dec 26, 2001 at 12:26:50PM +0100, David N. Welton wrote:
> > Anthony Towns  writes:
> > > On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> > > > As was stated elsewhere, the best way you can make a meaningful
> > > > contribution is to file bugs that are "higher level" than
> > > > "normal", in order to draw attention to broken packages.
> > > Oh god no. Please no. Inflating bug severeties just makes it harder
> > > to do releases; if there's a problem with normal bugs being ignored
> > > (and, IMO, there is), it needs to be addressed directly, not worked
> > > around by filing everything as important or higher.
> > If the software is broken enough that people find it really doesn't
> > work for its intended purpose, I agree with Henrique's idea that a bug
> > should be filed that will block the software from getting released.
> 
> That's not really what's at issue here though; the bug that started this
> thread was "support passing -graft-points to mkisofs". That's not a grave,
> critical or serious bug, and, TBH, I can't really see it being even a
> normal or important bug. It's just a completely legitimate wishlist request
> that'd probably be implemented in a couple of weeks if there was someone
> actively working on maintaining cdrtoaster.
> 
> The problem isn't that the package is buggy and unusable per se, it's
> just that it's not being kept up to date with other software in the
> distribution.
> 
> Cheers,
> aj
> 
> -- 

As I said before, thats a rather bad bug. One that will continue to 
cause the package to fail more and more in more common usage. Debian updated
it's version of mkisofs, and thus IT broke CDRToaster. As such this is now in
part a debian specific bug that hasn't been addressed in over a year IMHO.

When a distribution (or maintainer) upgrades a package that other
pack ages depend on, it is NOT up to the upstream to make the affected package 
compliant with the now-upgraded sub-package(mkisofs in this case) work togeather
properly. It's the responsibility of the two packagers to fix this "broken by 
upgrade" bug. This is the core of my beef that got me started.

> Anthony Towns <[EMAIL PROTECTED]> 
> I don't speak for anyone save myself. GPG signed mail preferred.
> 
> The daffodils are coming. Are you?
>   linux.conf.au, February 2002, Brisbane, Australia
> --- http://www.linux.org.au/conf



-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpfzxLyNUUAf.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Bdale Garbee]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug

While that's an interesting assertion, the real question is what it means to
"address" a bug.  There are packages with many bugs open against them which
are nevertheless very useful, even essential, packages.  Artificially cranking
up the severity isn't going to make them any better... 

Bdale

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Anthony Towns  writes:

> Oh god no. Please no. Inflating bug severeties just makes it harder to
> do releases; if there's a problem with normal bugs being ignored (and,
> IMO, there is), it needs to be addressed directly, not worked around by
> filing everything as important or higher.

But I think the point here is that the presence of a jillion normal
bugs, unaddressed for years, constitutes a release-critical bug, and
we want some way to filter such packages out of the release.  At
least, that's what I thought the idea was about.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 12:26:50PM +0100, David N. Welton wrote:
> Anthony Towns  writes:
> > On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> > > As was stated elsewhere, the best way you can make a meaningful
> > > contribution is to file bugs that are "higher level" than
> > > "normal", in order to draw attention to broken packages.
> > Oh god no. Please no. Inflating bug severeties just makes it harder
> > to do releases; if there's a problem with normal bugs being ignored
> > (and, IMO, there is), it needs to be addressed directly, not worked
> > around by filing everything as important or higher.
> If the software is broken enough that people find it really doesn't
> work for its intended purpose, I agree with Henrique's idea that a bug
> should be filed that will block the software from getting released.

That's not really what's at issue here though; the bug that started this
thread was "support passing -graft-points to mkisofs". That's not a grave,
critical or serious bug, and, TBH, I can't really see it being even a
normal or important bug. It's just a completely legitimate wishlist request
that'd probably be implemented in a couple of weeks if there was someone
actively working on maintaining cdrtoaster.

The problem isn't that the package is buggy and unusable per se, it's
just that it's not being kept up to date with other software in the
distribution.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf


pgppLljRVr5Al.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[David N. Welton]

Anthony Towns  writes:

> On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:

> > As was stated elsewhere, the best way you can make a meaningful
> > contribution is to file bugs that are "higher level" than
> > "normal", in order to draw attention to broken packages.

> Oh god no. Please no. Inflating bug severeties just makes it harder
> to do releases; if there's a problem with normal bugs being ignored
> (and, IMO, there is), it needs to be addressed directly, not worked
> around by filing everything as important or higher.

If the software is broken enough that people find it really doesn't
work for its intended purpose, I agree with Henrique's idea that a bug
should be filed that will block the software from getting released.

> Hrm. At least tell me that I'm misreading this, and what you meant
> to say was `` "higher quality" than "average" '' or something.

If it's going to be a bug that blocks the package from getting into
Debian releases, it better be well thought out, and high-quality, and
certainly not something used lightly.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Rune Broberg]

On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> 
> Brian, I understand your complaints.  It bugs me, too, to find
> software not maintained well.  We are volunteers, though, and as you
> realize, it takes a lot of time to do this, and so it happens, on
> occasion that someone just can't keep up.  I don't think it's really
> fair of people to tell you "hey, see if you can do it better", as you
> may not have the free time to work on something, let alone jump
> through the beaurocratic hoops that Debian places in the way of people
> who want to help.  If you don't have the time, you'll probably end up
> not maintaining it well either;-)

This, however, doesn't make it OK, that the work isn't done properly - I
for one know, that I do not have the time to be an active maintainer of
any "major" Debian-package - So I don't. I have, however, considered one
of the smaller packages, where I can overcome the burden of helping out.

Work done poorly is - IMHO - worse than work not done - If a package in
the Debian archives isn't maintained, it should be left open for someone
else to grab - as in "work not done". Otherwise Debian will look like a
bunch of developers, who have everything under control - but who are just
plain poor at coding. And I don't think that's the way we want Debian to
look?

First post on debian-devel from me, hope there were no major errors...

-- 
Rune B. Broberg aka. Mihtjel


pgpgZq5POOU0q.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> As was stated elsewhere, the best way you can make a meaningful
> contribution is to file bugs that are "higher level" than "normal", in
> order to draw attention to broken packages.  

Oh god no. Please no. Inflating bug severeties just makes it harder to
do releases; if there's a problem with normal bugs being ignored (and,
IMO, there is), it needs to be addressed directly, not worked around by
filing everything as important or higher.

Hrm. At least tell me that I'm misreading this, and what you meant to say
was `` "higher quality" than "average" '' or something.

Cheers,
a *twinge* j

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf

Re: An alarming trend (no it's not flaimbait.) (fwd)

[David N. Welton]

Brian, I understand your complaints.  It bugs me, too, to find
software not maintained well.  We are volunteers, though, and as you
realize, it takes a lot of time to do this, and so it happens, on
occasion that someone just can't keep up.  I don't think it's really
fair of people to tell you "hey, see if you can do it better", as you
may not have the free time to work on something, let alone jump
through the beaurocratic hoops that Debian places in the way of people
who want to help.  If you don't have the time, you'll probably end up
not maintaining it well either;-)

As was stated elsewhere, the best way you can make a meaningful
contribution is to file bugs that are "higher level" than "normal", in
order to draw attention to broken packages.  Even this will take you
some time to do properly, as you should read through the existing
reports in order to avoid duplicates.  However, it's a very valuable
service.  I know I appreciate finding that someone has already
reported a problem, and by doing so, possibly blocking buggy software
from going into 'testing' or being released.

Thanks for your time, and happy Debian'ing,
-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Christian Kurz]

Damn, I didn't want to post here anymore, but looks like I need to add
some points. :-(

On 26/12/01, Brian Wolfe wrote:
>   Heh, I was not aware that a non-developer could subscribe to d-d.

Looking at http://lists.debian.org and reading the list description
would have told you that before.

> On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote:
> 

> > Nice bait I'll bite, but if you want to read it you'll have to
> > subscribe... It's not fair to throw the rock and hide the hand 

> > 1) learn how to properly format a mail message (i.e. fold at 75th
> >column)

>   Oops. Darnit, how to do this automaticly with vi?

By reading the documentation or hasn't vi some documentation? Look
around for textwidth and wrapmargin.

> > 2) learn how to package a deb and adopt whichever package you think
> >you're better at maintaining than the original maintainer

>   Read up on packaging, attempted applying diffs from debian , 
> sucessfully I might add. But as for creating new packages... I haven't had a 
> lot of time to try it. ;-P Mind you this has been in the last 2 years...

Aehm, if you already successfully applied the diffs to a source package,
then it's not difficult to build a new debian package from that source.
And it's enough if new developers start by taking over old packages that
they daily use and which have been orphaned. 

> > 3) if the package is dead upstream, fork it and maintain it
> >yourself. Most free software licences allow it.

>   Anyone care to donate a time machine to me? I know this sounds routine
> and a lot like an escapeism but. I honestly do not have to time to 
> maintain
> my own GPLd software, run a company, advocate Linux smartly, make nice with 
> the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have
> a life. Adding package maintenance would be just a little more, but i'd like
> to regain at least ONE of the seven days of the week for myself before delving
> into somethign as complex as properly packaging a program for debian.

Well, taking over the upstream for a software is quite difficult since
you need to know the source well and be a good programmer. But
maintaining a debian package doesn't require that much time and
knowledge. So if you find enough time to send loud complaintments to
this list and then discuss them, it would be better to stop sending
those complaints but instead spend the time by sending in an ITA or ITO
for some debian package and help improving debian.

>   I can say this though, if Debian were to address the issues I have
> brought up in a realistic manner, I would be willing to toss my personal time
> into the project once I have some available, as well as possibly some idle
> company employee time once I can afford it.

Who is Debian? This is a _volunteer_ _based_ _organization_ so everyone
is spending the time on the tasks he's interested it. And even you won't
be able to force anyone to address the issues who posted, until either
he has enough interested and time to take care of some or you pay some
of our developers to take care of this issues. Or maybe you even find it
enough time to take care of them yourself and contribute that way to
Debian.

Christian

P.S.: I'm aware that some parts of this mail maybe seen as a bait for
flames, but that's not the intention. I'm just writing my own opinion
and statements about this and will now switch back to silence and
disappear in an unseens shadow. :-(
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgp8mdY3hNyKU.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

On Wed, Dec 26, 2001 at 08:40:52AM +, David Graham wrote:
> 
> On Wed, 26 Dec 2001, [EMAIL PROTECTED] wrote:
> > For some time now there has been an increasing trend in people that
> > I know who use debian. It is the view that debian is becoming
> > increasingly "old"/outdated, and that developers either a: dont'
> > have the time to properly maintain packages, or just don't care.
> 
> Does this comment apply to unstable, or just to stable?  Stable being
> out-of-date is a very different problem than unstable being out-of-date...

I'm speaking of testing,frozen mainly. Way Back Then(tm) I could depend
on unstable to function better than windows. :) Alas this is no more. And 
Stable looks/feels/smells like my gret grandpa. Open Source simply moves too
fast to keep a stable dist up to date. but good lord! I get visions of a mummy!
*GRIN*

> 
> > However, that leaves a problem. I've been told by several developers
> > that "it's an upstream problem. send them a patch and when they
> > include it we will update". Wel, that argument doesn't work in
> 
> This is only a valid excuse when upstream is active. I have often said
> something like that re. fetchmail (although it is more like: this is
> upstream's ground. If upstream agrees to do it, I will follow him. Bug
> forwarded).

*nod* In the case of upstreams, are there any metrics to approximate
how long it takes to get a bug fixed from upstream? Any kind of tools that
would allow you to manage patches so that a fix the user provides, can be 
used at the debian maintainer leve until it appears from upstream? This would
alleviate the issue of slow upstream maintainers I believe...

> 
> On the other hand, if a Debian developer is NOT willing to become upstream
> for a package that is being badly maintained upstream, he should orphan that
> package, and maybe even request its removal from the archive if the package
> state is really bad.

Agreed. Completely. :) Sadly, this is not the case. Debian has a case 
of Scales. ;-P packages dried up and flaking off, like CDRToaster (My current
target to pick on to keep things centered...)

> 
> > the debian packagers problem. If they are unwilling or unable to fix
> > it, then the package should be marked as "BAD" or "dead-upstream" as
> 
> Some would even say the package should have a bug filled, severity important
> (or higher): "WARNING: package not being maintained actively".  Which should
> be closed by the maintainer, when he comes back from lala-land, or when it
> is handled over to someone else.

This sounds like a good idea. I have heard murmurs of packages getting
tossed that have severe and critical bugs before a release. However, Is it 
logical to apply this same measure to packages in testing that sit with a CRIT
or SEVERE bug status of one or more bugs for an extended period of time?

It does no good to toss things out at the end. I believe that curing
the root of the problem before it interferes with the life of the distro is
the proper method of treating the problem. By kicking a package back into
unstable when it has CRIT bugs for more than a few days, debian can keep
testing clean enough to make a MUCH shorter bug-fix-fest and release cycle.
This is mostly due to nailing these critters as they pop up and don't get
resolved before they acumulate and cause a 6-month long frozen period.


> 
> Please file such a bug against that CD recoding package. If
> the maintainer complains that he is 'actively maintaining' it, tell him to
> stop lying to himself and admit he either needs to become upstream and fix
> all bugs, or drop the package (and keep the bug open)

Aye Aye Captain! ;) 9 times out of ten, i'm beaten to the bug report.
heh. So I loose interest in chasing every one due to believing someone else
has probably reported it allready.

This is a flaw in MY method that I shall strive to change.


> 
> > a warning to the user that they should pick a different utility like
> > this one to use.
> 
> This is actually a good idea. One can use the BTS to file bugs (I suggest
> bug severity to be either "important", or if the package is too sorry a
> state, "grave" -- but do be very sure of what you're doing if you file a
> "grave" bug).

See above about filing bugs. Guilty your honour. ;)
> 
> However, do expect to be yelled at if you misfile any such bugs, a lot of
> maintainers will not like that at all. You have been warned.

Heh. I got yelled at for suggesting someone add a 1 liner to the deb 
.diff once or twice. ;-P I fear not overfiend, why shall I fear a Lesser 
Evil? *duck*

> 
> > Ok, this has gotten long enough. I'm proposing as a user that you
> > (debian et al) find a way to somehow warn the user that this package
> > is dead upstream and that bugs aren't likely to get fixed if the
> > maintainer is unwilling/able to fix it. I am also proposing that it
> 
> Right 

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Heh, I was not aware that a non-developer could subscribe to d-d.

On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote:

> 
> 
> Nice bait I'll bite, but if you want to read it you'll have to
> subscribe... It's not fair to throw the rock and hide the hand 
> 
> 1) learn how to properly format a mail message (i.e. fold at 75th
>column)

Oops. Darnit, how to do this automaticly with vi?

> 
> 2) learn how to package a deb and adopt whichever package you think
>you're better at maintaining than the original maintainer

Read up on packaging, attempted applying diffs from debian , 
sucessfully I might add. But as for creating new packages... I haven't had a 
lot of time to try it. ;-P Mind you this has been in the last 2 years...

> 
> 3) if the package is dead upstream, fork it and maintain it
>yourself. Most free software licences allow it.

Anyone care to donate a time machine to me? I know this sounds routine
and a lot like an escapeism but. I honestly do not have to time to maintain
my own GPLd software, run a company, advocate Linux smartly, make nice with 
the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have
a life. Adding package maintenance would be just a little more, but i'd like
to regain at least ONE of the seven days of the week for myself before delving
into somethign as complex as properly packaging a program for debian.

I can say this though, if Debian were to address the issues I have
brought up in a realistic manner, I would be willing to toss my personal time
into the project once I have some available, as well as possibly some idle
company employee time once I can afford it.

After all, I am trying to make a company run on 100% GPLd software.
TerraBox's goal is to be a testimony to the power and usability of Open 
Source software in the business arena. To do less than to toss time back into
the company would be hypocritical at best, and downright dishonestly evil
at worst IMHO.
> 
> 
> Have a nice (redhat|mandrake|windowsXP) day
> 
> Pf

Ack! EVIL! It's still Debian Woody for me. :) I'm not giving up just 
yet.


-- 

Brian Wolfe  <[EMAIL PROTECTED]> "Down to earth computing!"
TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Duly chastined. :) I discovered a few minutes ago (thanks to a friend 
that is d-d) that I can in fact join the debian-devel list. So I am now lurking 
to read and reply. :)

I'll reply in a few minutes to the other email. :)

Brian