Re: An alarming trend (no it's not flaimbait.)
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Thu, 03 Jan 2002, Craig Dickson wrote: Karl M. Hegbloom wrote: If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? Is it? Is the average Debian user both able and willing to be a Obviously not. It is a pretty good indication that no developer is using it anymore, but just that. 1. Debian Developer are a good sample of the Debian users. Only a selected group, but it still gives some indication. 2. popularity-contest should also give you a hint. 3. If a package has a bug and is not maintained that can be noticed. If the bug is release critical, it drops out of stable. Watch out for those. Clean up those buggy, stale debs first. 4. Check for packages that are outdated compared to upstream source. Contact upstream if they know someone to maintain it. But what about stale, unused, bugfree debs that are just perfect (Yeah, show me one). No newer upsteam and no other indication of staleness? First of all its maintainer should know. Would you maintain a package you don't use? The package should be orphaned when its not maintained and then go the way of all orphans: get adopted or grow up and earn your own money. :) The only way to see if a probably unused package is realy unused is to remove it and wait for someone to scream. Do you want to listen to all those screams? Removing a package should be well though about. MfG Goswin PS: I'm all for cleaning up old cruft. Just remember that someones cruft might be someone elses dearest. PPS: NEVER REMVOE MOONBUGGY
Re: An alarming trend (no it's not flaimbait.)
If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? What about taking packages like that and removing the binary .deb, but leave the last source package in the archive... there should be a way through some interface such as aptitude or a web page to find it by searching, perhaps. But this only for software deemed worth a read of the source code or potentially useful in real life. We must admit: there is plenty of cruft in the archive. A lot of stuff nobody really uses. -- mailto: (Karl M. Hegbloom) [EMAIL PROTECTED] http://www.microsharp.com phone://USA/WA/360-260-2066 jabber: [EMAIL PROTECTED]
Re: An alarming trend (no it's not flaimbait.)
Karl M. Hegbloom wrote: If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? Is it? Is the average Debian user both able and willing to be a maintainer, and sufficiently aware of ongoing developments that he would both know that the package is out of date, and how to go about doing something about it (in terms of the process for taking over an abandoned package)? Craig
Re: An alarming trend (no it's not flaimbait.)
no it isnt flame bait but it is newbie bait! there is an good discussion on this very topic at the following url http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ take care. i am not a maintaner yet! someday hopefully dd [EMAIL PROTECTED] wrote: Karl M. Hegbloom wrote: If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? Is it? Is the average Debian user both able and willing to be a maintainer, and sufficiently aware of ongoing developments that he would both know that the package is out of date, and how to go about doing something about it (in terms of the process for taking over an abandoned package)? Craig
Re: An alarming trend (no it's not flaimbait.)
Darrell Rene Dupas wrote: no it isnt flame bait but it is newbie bait! Not if you read it correctly. Try again. there is an good discussion on this very topic at the following url http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ I was talking about Debian policy and procedures, not general open-source practice, with which I am sufficiently familiar. Craig
Re: An alarming trend (no it's not flaimbait.)
On Thu, 03 Jan 2002, Craig Dickson wrote: Karl M. Hegbloom wrote: If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? Is it? Is the average Debian user both able and willing to be a Obviously not. It is a pretty good indication that no developer is using it anymore, but just that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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: Build systems (was Re: An alarming trend (no it's not flaimbait.))
Adam Heath writes: On 27 Dec 2001, Tollef Fog Heen wrote: * Adam Heath | dbs(doogie build system, debian build system) | | See autofs, apache, x(contains a pre-alpha version of dbs). | | Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. Dbs | has a larger following(but well under 100 packages use it). What are the differences between DBS and dpatch, and why should I choose one or the other? dpatch offers no patch ordering. dbs does it does have patch ordering. the order is determined by the debian_patches macro. Also, an unreleased dbs supports patch dependencies. It was a quick simple modification to dbs to get it to support this. Dbs uses a single script to apply all patches, which makes adding features easy. dpatch turns each patch into a script, which means the scriptage needs to be updated by hand when a new feature is needed. yes, the rationale is to run commands after the patch was applied (mostly autoconf to regenerate configure) Neither dbs nor dpatch are documented. found this out while looking at dbs...
Re: An alarming trend (no it's not flaimbait.) (fwd)
[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)
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)
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)
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.)
On Thu, Dec 27, 2001 at 12:07:39AM +0100, Amaya wrote: Anthony Towns dijo: Bas Zoetekouw posted the results of a script in mid November that'd help clearing up packages that've been sitting in the archive unmaintained for ridiculously long periods, Could anyone ponit me to that script? Google can't help me this time :-) http://lists.debian.org/debian-devel/2001/debian-devel-200111 ? -- Eric VAN BUGGENHAUT Los niños son esponjas (Amaya Rodrigo Sastre) \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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)
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
Build systems (was Re: An alarming trend (no it's not flaimbait.))
* Adam Heath | dbs(doogie build system, debian build system) | | See autofs, apache, x(contains a pre-alpha version of dbs). | | Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. Dbs | has a larger following(but well under 100 packages use it). What are the differences between DBS and dpatch, and why should I choose one or the other? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On 27 Dec 2001, Tollef Fog Heen wrote: * Adam Heath | dbs(doogie build system, debian build system) | | See autofs, apache, x(contains a pre-alpha version of dbs). | | Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. Dbs | has a larger following(but well under 100 packages use it). What are the differences between DBS and dpatch, and why should I choose one or the other? dpatch offers no patch ordering. dbs does dpatch offers no command to generate a diff automatically. dbs does Also, an unreleased dbs supports patch dependencies. It was a quick simple modification to dbs to get it to support this. Dbs uses a single script to apply all patches, which makes adding features easy. dpatch turns each patch into a script, which means the scriptage needs to be updated by hand when a new feature is needed. Neither dbs nor dpatch are documented. You should use dbs or dpatch if you end up having lots of patches against upstream, and want to maintain them as short, small, separate patches, instead of one single huge debian diff.gz.
Re: An alarming trend (no it's not flaimbait.) (fwd)
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: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On Thu, Dec 27, 2001 at 05:42:52PM -0600, Adam Heath wrote: You should use dbs or dpatch if you end up having lots of patches against upstream, and want to maintain them as short, small, separate patches, instead of one single huge debian diff.gz. My main beefs with both DBS and dpatch are probably held by several others: the tarball-in-a-tarball business (aesthetic) and the fact that you have to perform extra steps after 'dpkg-source -x' which vary from package to package before you can see the source that's actually built. I realize you may not see either of these as problems. What do you think of the perl build system? It has the maintainer run the patch and unpatch targets manually as necessary. Providing the maintainer's happy with this extra step, the only obvious disadvantage is that the diff almost doubles in size. I'm considering something like this for groff, unless the new dpkg-source will be arriving soon. My rationale for preferring the perl system is that I'd rather have the maintainer perform an extra step he/she's familiar with than have all the users who download the source perform an extra step they're unfamiliar with. Of course, it gets less practical as the .diff.gz grows. -- Colin Watson [EMAIL PROTECTED]
Re: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On Thu, 27 Dec 2001, Colin Watson wrote: What do you think of the perl build system? It has the maintainer run the patch and unpatch targets manually as necessary. Providing the maintainer's happy with this extra step, the only obvious disadvantage is that the diff almost doubles in size. I'm considering something like this for groff, unless the new dpkg-source will be arriving soon. I've never heard of it, so I have no comments about it. I don't like the doubling of the diff that this will cause. On the state of that new dpkg-source: It currently can extract and create old format(version 1.0) source archives. It can extract new format(version 2.0, multi diff/tar, zip/bzip support as well). Building of the new format is a little more complex. It may not make it into dpkg 1.10(which, roughly, may be released sometime between March and May, after woody has been fully frozen for quite a bit(this is not an official release schedule for dpkg)). I may have it all working by next June to August. I've given plenty of time here, hopefully I can keep the schedule.
Re: An alarming trend (no it's not flaimbait.)
Eric Van Buggenhaut dijo: http://lists.debian.org/debian-devel/2001/debian-devel-200111 ? Thank you for the link, But I was really looking for: http://lists.debian.org/debian-qa/2001/debian-qa-200111/msg00188.html -- .''`. No tengo el coño pa ruidos -- David Amor, dear friend : :' : `. `' Proudly running Debian GNU/Linux Sid (Kernel 2.4.14) `-www.amayita.com www.malapecora.com www.chicasduras.com
Re: An alarming trend (no it's not flaimbait.)
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... 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). 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. 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. wears QA hatPlease 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)/wears QA hat 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). 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. 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 now, using the BTS properly you could do suck marking of packages without any extra tools. I expect such packages to be dropped at release time if they are really unmaintained. be required of a maintainer that they have at least a rudimentary ability to fix minor bugs like this. I believe most maintainers already take that view. Those who don't, really should know better. It is my opinion that if you are putting your name to somethign that you are providing for download, you are implying that you have accepted responsibility for the quality of the software. Indeed. I would like to point out, however, that this applies to the package level too. If someone maintains a package, and uploads it to Debian, he better be ready to stand behind the quality of his work. Otherwise, he should either improve that packaging fast, or get lost (and please orphan his packages properly while at it). 'Thank you for all the fishes, do come back when you have the proper skill level and/or amount of spare time to actually maintain your Debian packages' may be a harsh thing to say; it looks elitist, even. But it is the best thing to do from a QA (and therefore, an user's) point of view, IMHO. Heck, one does not even need to leave the project, just take an extended vacation (BUT FOLLOW THE PROPER PROCEDURE FOR DOING SO, thank you), and come back later, as many have done in the history of the project. system of packaging volunteers that have NO responsibility for I (along with many others) will fight using deadly weaponry to avoid such an fate. We need responsible maintainers in Debian, not packagers that go their merry way leaving the distro littered with outdated and often broken crap. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: An alarming trend (no it's not flaimbait.)
:- ahzz-debate == ahzz-debate [EMAIL PROTECTED] writes: [...] I see an increasing trend of two critical problems in the way debian operates. #1 package age. Let me talk about this one first. There has been a relatively (year or two) explosion in the package count. As this package count has gone up, packages that I have used for years and that used to work well have falen into a sad state or disrepair. I'll use CDRToaster as an example here. [...] 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 increasingly common cases like this. At this point, it is now (IMHO) 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 a warning to the user that they should pick a different utility like this one to use. [...] It is my opinion that if you are putting your name to somethign that you are providing for download, you are implying that you have accepted responsibility for the quality of the software. If this is not the case, then debian needs to stop labeling itself as a distro in the users eyes, and clearly label itself as a system of packaging volunteers that have NO responsibility for software bugs at all, and ONLY responsible and track bugs that come from being packaged. [...] Ok, enough of this for tonight. I will now let you all discuss this amongst yourselves since I am not a developer. Should the situation arise that a: I have more free time, and b: that debian either accepts responsibility for packages, or alternativly modifies it's public image to one of being a packager only and keeps up with upstream stuff, then at that point i'd be interested in joining the team to make debian better. [...] I would appreciate a CC: to [EMAIL PROTECTED] for any emails sent back tot he list directly. For I am not on the debian-devel mailing list.:) [...] 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) 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer 3) if the package is dead upstream, fork it and maintain it yourself. Most free software licences allow it. Have a nice (redhat|mandrake|windowsXP) day Pf -- --- Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED] - http://gusp.dyndns.org Firenze - Italia | Office for the Complication of Otherwise Simple Affairs Linux penny 2.4.16 #1 Fri Nov 30 22:12:51 CET 2001 i686 unknown
Re: An alarming trend (no it's not flaimbait.)
On Wed, Dec 26, 2001 at 09:38:24AM +0100, Pierfrancesco Caci 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) 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer 3) if the package is dead upstream, fork it and maintain it yourself. Most free software licences allow it. While it is a bit of a bait, I agree with his assessment. And I believe his point is that debian needs a better way to handle packages that aren't properly maintained, rather than just letting them clutter up the archives. -- Adam Olsen, aka Rhamphoryncus
Re: An alarming trend (no it's not flaimbait.) (fwd)
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
Re: An alarming trend (no it's not flaimbait.) (fwd)
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: SNIP 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. SNIP -- 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.)
* Pierfrancesco Caci ([EMAIL PROTECTED]) 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) Quit pickin at the measly stuff and pay attention to the content of his words. Laying the bear trap here only gets you laughs from the other hunters. 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer Pointing out a failure in a system doesn't mean one has the ability to do what you are asking. It simply means he found a failure. In this instance, his becoming a maintainer does nothing to solve the problem he's point at other than for that single package. Pushing someone off into this section only further proves the point that debian's starting to potentially fall apart since you completely prove that you either failed to hear or desired not to hear what his content. 3) if the package is dead upstream, fork it and maintain it yourself. Most free software licences allow it. Please explain how him maintaining it helps the other packages in trouble as well. Or are you trying to suggest that the package he spoke of is the only one of it's kind in trouble or that no other packages in debian suffer from the fate he describes? Have a nice (redhat|mandrake|windowsXP) day Not even worth more than this snicker. OK, I'm getting in on this one, regardless of opinions. Sorry, but I have to agree with Brian here. OK, my little history to show what grounds I make my stand on. I've used linux for quite a few years now. I started with SLS Linux kern ver 1.0.8), was there at slackware's inception, ran Peanut, Stampede, Red Hat, Mandrake, and of course Debian. I've worked in the linux industry for Red Hat, Ensim Corp, and a few others. I've developed LPIC-II certification tests as a core member of LPI. Why are you listing all that crap bub? Probably what a few of you are asking. Only to show my experience with different distros, linux, and where I feel I gain my credence for my vote for Brian's comments. Debian is a solid distro to me. It's got heart, strength of charactor both in it's member software, and it's member users and developers. It's withstood 99% of the Let's add every feature we can lay our hands on cause that'll show we know what we're doing! crowd. It's solidly built, loved, and protected over by a loyal group of users. This is more than I can say for the majority of the distributions out there. yeah I give other distribs a hard time just like everyone else. it's fun and part of the game. BUT, there are some real things that happen to real distros when it's members don't speak of what they see wrong and *developers* __listen__. Folks, our user base (non official developers and general users alike) deserve to be listened to when they say something. At least Brian took the time to list things out with well thought out and deliberately worded and experience backed points. Many of the complaints that a distrib gets are from those that aren't really for the distro, it's just something they use, they want some help, they find it's not easy without using the docs, and just start bad mouthing it to cover their own lack of capability. The real users have something substantial to their words. Brian does. I've got to admit up front that I've not been a user of debian as a primary distribution. And for whatever the comments made, yes, I've been using Red Hat or Slackware as my primary. I do run multiple distributions at any given time. There are many that do because it makes it easier to see where users in general are. I have been running Debian since Slink. I've left it, come back, left it, ran it solid for a bit, then left it again, now I'm back. Why? Simply because of issues with Debian, be it the installer of old, the lack of certain support, all different reasons. But one thing is for sure. I've been able to follow quite a bit of the lifeline of Debian. I too have watched as packages that Debian used to keep up to date are now getting moldy. I've watched as developers have gotten the attitude that the user is here to serve their programming careers or their kudos meter, rather than the developers realizing that's who they develop for besides themselves. (Face it you wouldn't be developing for Debian as an official developer if you didn't believe that it's a community thing and community is made up of more than just the developers.) Monitoring all the packages that belong in the Debian distribution is a mighty tough thing. I'm sure even Brian will grant that. The point of this excersise is the realization that the reason we have maintainers in the first place is to make sure that stuff like this *doesn't* happen to debian. If each maintainer is watching his or her upstream, updates with their source when it's released, and if the
Re: An alarming trend (no it's not flaimbait.) (fwd)
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. wears QA hatPlease 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)/wears QA hat 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 now, using the BTS properly you could do suck marking of
Re: An alarming trend (no it's not flaimbait.)
On Wed, Dec 26, 2001 at 01:38:53AM -0800, David D. W. Downey wrote: * Pierfrancesco Caci ([EMAIL PROTECTED]) 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) Quit pickin at the measly stuff and pay attention to the content of his words. Laying the bear trap here only gets you laughs from the other hunters. I deserved a little bit of this. I'm no saint. :) To be fair he did separate this out from the meat of his reply. But thanks for the defense. :) 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer Pointing out a failure in a system doesn't mean one has the ability to do what you are asking. It simply means he found a failure. In this instance, his becoming a maintainer does nothing to solve the problem he's point at other than for that single package. Pushing someone off into this section only further proves the point that debian's starting to potentially fall apart since you completely prove that you either failed to hear or desired not to hear what his content. He agrees with me on several things. Just a bit more cautious about it. 3) if the package is dead upstream, fork it and maintain it yourself. Most free software licences allow it. Please explain how him maintaining it helps the other packages in trouble as well. Or are you trying to suggest that the package he spoke of is the only one of it's kind in trouble or that no other packages in debian suffer from the fate he describes? If I had the time, then i'd be taking over the packages that I use that are rather flawed. It's a start. Have a nice (redhat|mandrake|windowsXP) day Not even worth more than this snicker. OK, I'm getting in on this one, regardless of opinions. Sorry, but I have to agree with Brian here. OK, my little history to show what grounds I make my stand on. I've used linux for quite a few years now. I started with SLS Linux kern ver 1.0.8), was there at slackware's inception, ran Peanut, snip snip snip *whew!* snip snip *GRIN* Cheerfully singing my name to this, -- That is a great suggestion! I believe I can toss in some of the one developer-type person I have doing work for me to trackign down the root of some of custier packages. Mind, his time is on a side-deal agreement, so he isn't an emplyee in the normal sense of the word. But I will see if I can get some of his time in trade to add to this. I'll pick out a few of the most-used packages that I have and see what the reality is on them. If they are maintained by a slacker (no pun on slackware intented or wanted) then I'll swat em with a Clue Bat(tm) as sugested here. :) FWIW, I love debian for several reasons despite it's flaws... here they are in no particular order... #1 (ok, so this IS the biggest. ;) ) It's not a for-proffit corp! Community CAN have a potential influence. It's maintainers *usualy* use the packages they maintain daily. #2 it's the only Ture Open Source distro out there that I know of. #3 It started with a noble goal in mind, and started with an attitude of quality. If not, then where the hell did the idea of apt-get and dpkg come from!?! #4 Pick-o-the-week application ability. More than one editor, browser, filemanager, graphics tool, library-, etc, etc, etc. Now this DOES need to be curtailed in the interest I described in my first post. But for the short haul, until the horse has all it's harness back on it. -- Brian Wolfe [EMAIL PROTECTED] Down to earth computing! TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648 A750 52F8 8504 67DB 205C pgpZR2zoUoYeU.pgp Description: PGP signature
Re: An alarming trend (no it's not flaimbait.) (fwd)
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: SNIP 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.)
So, that's hopefully my last post for quite a long time. On 26/12/01, David D. W. Downey wrote: * Pierfrancesco Caci ([EMAIL PROTECTED]) wrote: 1) learn how to properly format a mail message (i.e. fold at 75th column) Quit pickin at the measly stuff and pay attention to the content of his words. Laying the bear trap here only gets you laughs from the other hunters. Wrong. If you want people to read a mail and follow the content, then you have to proper format it, so that's it's easy to read it. Did you ever read some books or newspapers and noticed the format that they are using? With your argumentation we can remove all those formatting and prints books and newspapers on a large paper roll and read it. 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer Pointing out a failure in a system doesn't mean one has the ability to do what you are asking. It simply means he found a failure. In Not directly. He found a situation that he think it's flawed and which needs to be changed. But without either having enough people interested to take care of it, it won't change until he steps forward and starts working on changing it. this instance, his becoming a maintainer does nothing to solve the problem he's point at other than for that single package. Pushing Wrong, he can then help with other packages, make NMU's if the maintainer gave him permission or track MIA developers done and then orphan their package and let Debian QA take care of them. someone off into this section only further proves the point that debian's starting to potentially fall apart since you completely prove that you either failed to hear or desired not to hear what his content. And you seem to ignore that this is _volunteer_ _based_. Debian Developers will work on those issues that they are interested in and not the things you want to see them working on. If you want to see Developers working on some issue, either start paying them for doing the work, convince enough to work on the issue or start the work on your own. The BTS will happily accept your mails and debian-qa will be interested to hear about MIA developers which you tracked down and which agree to orphan their packages or aren't reachable in any way. Why are you listing all that crap bub? Probably what a few of you are asking. Only to show my experience with different distros, linux, and where I feel I gain my credence for my vote for Brian's comments. And then you are not able to use your experience to create solutions to help debian but to also start lenghty discussions here? Thanks for showing me that at least a part of our user base seems to have changed and see Debian as company which they pay for and which they can force into working on certain issues. Debian is a solid distro to me. It's got heart, strength of charactor both in it's member software, and it's member users and developers. It's withstood 99% of the Let's add every feature we can lay our hands on cause that'll show we know what we're doing! crowd. It's solidly built, loved, and protected over by a loyal group of users. This is more than I can say for the majority of the distributions out there. So why are you then not contributing something back to the Debian project if you quite like it that much? Folks, our user base (non official developers and general users alike) deserve to be listened to when they say something. Listening is one thing, but doing something is much better and at least people like you who according to their own description have enough experience and knowledge, should think about spending some time on helping and improving debian by working on it instead of starting lenghty discussions and complaining loud. Why? Simply because of issues with Debian, be it the installer of old, the lack of certain support, all different reasons. But one And you aren't able to work on the installer or even just clearly describe the people working on it which parts need to be improved in your opinion and why? Lack of certain support? Try to write exact descriptions what kind of support you are lacking and then talk with the maintainers who are responsible for it about adding it or helping them add it. *doesn't* happen to debian. If each maintainer is watching his or her upstream, updates with their source when it's released, and if the upstream is *not* providing the updates like they should, either Pardon? You want to give us a exact defintion for updates like they should? There's no way to define that and sometimes upstream authors also disappear simply because they have a lack of time. announce to the BTS that the source is cold, or attempt to Why should one do that? If the package is still working fine and contained no bugs, there's in my opinion no need to do this. And if the package is too buggy, it's easier to contact the ftpmaster via the BTS and ask for package
Re: An alarming trend (no it's not flaimbait.)
On Wed, Dec 26, 2001 at 06:34:16AM -0200, Henrique de Moraes Holschuh wrote: 'Thank you for all the fishes, do come back when you have the proper skill level and/or amount of spare time to actually maintain your Debian packages' That's all very well (personally I find it a bit insulting and counterproductive), but it doesn't actually do any good if we don't clean up after them. You can complain all you want about packages that silently lapse into unmaintained buginess, but the fact is we're not doing much better with packages that are orphaned. Bas Zoetekouw posted the results of a script in mid November that'd help clearing up packages that've been sitting in the archive unmaintained for ridiculously long periods, but it doesn't seem to be being used. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ 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 pgpNbsqnO5Jr9.pgp Description: PGP signature
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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] http://azure.humbug.org.au/~aj/ 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)
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 aj@azure.humbug.org.au 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)
On Wed, Dec 26, 2001 at 12:26:50PM +0100, David N. Welton wrote: Anthony Towns aj@azure.humbug.org.au 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] http://azure.humbug.org.au/~aj/ 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.)
On Wed, Dec 26, 2001 at 01:57:17AM -0600, [EMAIL PROTECTED] wrote: As debian caught up on versions, CDRToaster became increasingly buggy. The last modification that I saw to it over a year ago was to let it support 8x CDR drives. I personaly took the time to patch it and send out a patch. I never saw it in debian until the upstream included it approximatly 2 motnhs later. This is too long of a timeframe for a simple patch to take to fix something. Now this was a feature enhancement and was easy to accept that it took a bit to get back into debian. It seems perfectly reasonable to punt patches that aren't Debian specific to upstream. It helps both upstream and the Debian maintainer if everyone is working off the same version of the package, particularly when Debian users try to go upstream for support. Slow release cycles already create enough hassle with that without starting to modify the package under upstream. Where upstream is inactive or unresponsive things are a little different, of course. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: An alarming trend (no it's not flaimbait.)
On Wed, Dec 26, 2001 at 01:57:17AM -0600, [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. Which the case is here I don't know. I'm not intimate with a lot of developers. However, this has been the same view that has been slowly dawning over me for a while now. I don't necessarily agree that the situation is as bad as you're painting it elsewhere in your mail, but it's entirely true that many packages have serious quality problems. In the relatively short time I've been a Debian developer (less than a year), I've taken over several packages in the sort of state you describe and got them into a better state. I've worked on several others that have ended up in the hands of the QA group, where they may not receive the most loving care possible (God knows, http://bugs.debian.org/[EMAIL PROTECTED] has enough crap on it), but where they're certainly better off than with nobody watching them at all. (I say this mostly to try to establish that I've been trying to do things as well as just talking about them.) The problem is that this is a very labour-intensive process. Taking over a badly-maintained package means that I have yet another thing to take care of on a long-term basis, and my to-do list is pretty long as it is. More importantly, though, if the package wasn't already orphaned then taking it over or working on it in any other way can turn into a political nightmare. Offer to help some people by doing a non-maintainer upload of their package and you'll get your head bitten off. On the other hand, many maintainers are great about this, and would be happy to accept help on their less urgent bugs if only anyone dared to offer it! And of course some people will just not respond either way through lack of time or whatever. Thus trying to take action yourself to fix non-release-critical bugs is an unknown quantity in terms of how much political flamage you're going to have to wade through, and it can end up being more trouble than it's worth. The upshot is that release-critical bugs get attention, because there are lots of them and there's a general consensus that it's OK for other people to step in and fix them if the maintainer doesn't have the time. This encourages bug severity inflation because it sometimes seems like the only reliable way to get anything done (see elsewhere in this thread), and it unnecessarily sharpens the tone of people who are going around fixing things (why haven't you fixed this grave bug yet?! - I'm quite sure I'm guilty of this), which in turn gets maintainers' backs up and makes them understandably less amenable to letting anybody else work on their bugs, perpetuating the vicious circle. Then sometimes people make mistakes in NMUs, which has been the source of any number of flamewars on -devel in the past. I don't know what the solution to any of this is short of having everybody develop industrial-strength thick skins. Perhaps a standard place where everybody could say up-front what their attitude is would be useful (http://people.debian.org/~cjwatson/nmu.html is mine, FWIW). I think encouraging people not to be afraid to offer help in whatever form is a good idea, although I'm sure somebody will disagree with me. In general we need development and quality assurance not to be at war with one another. Ok, enough of this for tonight. I will now let you all discuss this amongst yourselves since I am not a developer. Should the situation arise that a: I have more free time, and b: that debian either accepts responsibility for packages, or alternativly modifies it's public image to one of being a packager only and keeps up with upstream stuff, then at that point i'd be interested in joining the team to make debian better. I'd say that Debian does accept responsibility for packages, even if we don't always discharge that responsibility. I hope you consider your second condition fulfilled, as the only way Debian can improve is by the efforts of its members. -- Colin Watson [EMAIL PROTECTED]
Re: An alarming trend (no it's not flaimbait.) (fwd)
Anthony Towns aj@azure.humbug.org.au 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)
[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.)
On Wed, Dec 26, 2001 at 01:43:53PM +, Mark Brown wrote: On Wed, Dec 26, 2001 at 01:57:17AM -0600, [EMAIL PROTECTED] wrote: As debian caught up on versions, CDRToaster became increasingly buggy. The last modification that I saw to it over a year ago was to let it support 8x CDR drives. I personaly took the time to patch it and send out a patch. I never saw it in debian until the upstream included it approximatly 2 motnhs later. This is too long of a timeframe for a simple patch to take to fix something. Now this was a feature enhancement and was easy to accept that it took a bit to get back into debian. It seems perfectly reasonable to punt patches that aren't Debian specific to upstream. It helps both upstream and the Debian maintainer if everyone is working off the same version of the package, particularly when Debian users try to go upstream for support. Slow release cycles already create enough hassle with that without starting to modify the package under upstream. Where upstream is inactive or unresponsive things are a little different, of course. Yup, this is the situation that I was attempting to describe, when upstream seems to be ignoring the package, debian can then take on some of the smaller patches that fix functionality that is broken (such as the grafting ability. pretty important in making iso images IMHO) If the maintainer had a way of keeping track of small patches via some method(cvs maybe?) then they could peel them back off once the offical patch made it's way back to them from upstream months (years even? *shudder*) later. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- 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)
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 aj@azure.humbug.org.au 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] http://azure.humbug.org.au/~aj/ 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)
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)
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)
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)
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.)
Anthony Towns dijo: Bas Zoetekouw posted the results of a script in mid November that'd help clearing up packages that've been sitting in the archive unmaintained for ridiculously long periods, Could anyone ponit me to that script? Google can't help me this time :-) -- .''`. No tengo el coño pa ruidos -- David Amor, dear friend : :' : `. `' Proudly running Debian GNU/Linux Sid (Kernel 2.4.14) `-www.amayita.com www.malapecora.com www.chicasduras.com
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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 [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)
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)
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)
On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote: Anthony Towns aj@azure.humbug.org.au 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] http://azure.humbug.org.au/~aj/ 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)
Anthony Towns aj@azure.humbug.org.au 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)
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)
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)
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] http://azure.humbug.org.au/~aj/ 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.)
On Wed, 26 Dec 2001, Brian Wolfe wrote: Where upstream is inactive or unresponsive things are a little different, of course. Yup, this is the situation that I was attempting to describe, when upstream seems to be ignoring the package, debian can then take on some of the smaller patches that fix functionality that is broken (such as the grafting ability. pretty important in making iso images IMHO) If the maintainer had a way of keeping track of small patches via some method(cvs maybe?) then they could peel them back off once the offical patch made it's way back to them from upstream months (years even? *shudder*) later. dbs(doogie build system, debian build system) See autofs, apache, x(contains a pre-alpha version of dbs). Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. Dbs has a larger following(but well under 100 packages use it).
Re: An alarming trend (no it's not flaimbait.) (fwd)
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)
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)
On Thu, 27 Dec 2001, Anthony Towns wrote: On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote: Anthony Towns aj@azure.humbug.org.au 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)
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)
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)
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 [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)
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.
