Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Tue, Mar 27, 2007, Mike Hommey wrote: I like doing bug triage as well. I guess it is because I am a neat freak and anal about organization. Would you still like it if the bug count for one package would number in hundreds ? It's easy to have a huge backlog. I believe a more appropriate metric to estimate whether triaging is realistic for a given package would be the number of new bugs per day. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Tue, Mar 27, 2007 at 08:12:07AM +0200, Mike Hommey wrote: On Mon, Mar 26, 2007 at 09:38:24PM -0400, Roberto C. Sánchez [EMAIL PROTECTED] wrote: People should be given assistance and encouragement in doing it. I actually like doing it, but I have unfortunately relatively little time (sick family members). I like doing bug triage as well. I guess it is because I am a neat freak and anal about organization. Would you still like it if the bug count for one package would number in hundreds ? In fact, yes. More so, even. The higher the bug count the *greater* the reward for triaging everything properly. It helps to prevent getting mired in a sea of bugs. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On 2007-03-27, Roberto C Sánchez [EMAIL PROTECTED] wrote: In fact, yes. More so, even. The higher the bug count the *greater* the reward for triaging everything properly. It helps to prevent getting mired in a sea of bugs. We still miss around 600 bugs in our backlog: http://users.alioth.debian.org/~pusling-guest/pkg-kde-buggraphs/_ALL_-forwarded-year.png feel free to join in. you can start here: http://pkg-kde.alioth.debian.org/bugs.html /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Tue, Mar 27, 2007 at 10:47:38AM +, Sune Vuorela wrote: On 2007-03-27, Roberto C Sánchez [EMAIL PROTECTED] wrote: In fact, yes. More so, even. The higher the bug count the *greater* the reward for triaging everything properly. It helps to prevent getting mired in a sea of bugs. We still miss around 600 bugs in our backlog: http://users.alioth.debian.org/~pusling-guest/pkg-kde-buggraphs/_ALL_-forwarded-year.png feel free to join in. you can start here: http://pkg-kde.alioth.debian.org/bugs.html I will try and do what I can. However, not being a KDE user, I am afraid I will be of limited help. Hopefully some ohter KDE users will step up as well. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
I've been reading the discussion and trying to thresh something out of it. Four points and one proposal. Point 1. --- Contrary to some assumptions, answering I got your bug report but I can't deal with it right now is *very* useful, particularly in encouraging people to help. I've reported some bugs where I got prompt replies of I can't reproduce it, or I can reproduce it but I don't know how to fix it, or I threw it upstream and we hope they'll fix it in the next century, but don't hold your breath, or even Upstream is dead and I can't be bothered to fix it myself but feel free to send a patch, and I've been fairly happy. I've reported some similar bugs where I got no response, even after six months or more, and I was *not* happy. Communication is of value in and of itself. Major comments on the subject are at http://lists.debian.org/debian-devel/2007/02/msg00702.html and http://lists.debian.org/debian-devel/2007/02/msg00707.html and even http://lists.debian.org/debian-devel/2007/02/msg00736.html And perhaps most crucially: http://lists.debian.org/debian-devel/2007/02/msg00697.html (with followup http://lists.debian.org/debian-devel/2007/02/msg00771.html) The take-home message: --- Letting the submitter know that the bug has been looked at is valuable. --- Point 2. --- If you don't have time to read/respond to bug reports within six months, you need help and you should ask for it. If you are not reading your bug reports (again, within six months to a year; I'm not talking about real prompt response here) you are not maintaining your package properly. You have several options: * Orphan it, and make QA uploads when you have the time. * File an RFH saying I want to keep this package but I need more comaintainers in order to manage it properly, and encourage NMUs. Point 3. --- Lack of response to bugs is usually a symptom of a larger problem; if that problem is something other than I need help, then it's a serious problem. We should try to come up with some way of pinpointing and addressing these situations. The worse scenario IMNSHO is not merely a lack of response to bugs, but that *combined with* a proprietorial attitude towards the package. Consider this as the problematic scenario: (1) Person A files bug against package maintained by Mr. X (2) Mr. X doesn't respond for months (3) Person B files patch for bug (4) Mr. X doesn't respond for months (5) Person C NMUs (6a) Mr. X doesn't respond for months -or- (6b) Mr. X complains that the NMU broke his package, or that the patch was bad, or whatever. -or- (6c) Mr. X uploads reverting the NMU In this scenario, Mr. X should not be the maintainer. Period. And it happens fairly often. Actually, after describing the worst-case scenario, I am going to make a new tentative proposal: If a package has a bug with a *patch* attached, where the *patch* has not been reviewed on by the maintainer(s) within six months, the package will be orphaned immediately; the maintainer will not be allowed to adopt it for at least a year, though he may comaintain and make uploads. (This should give a more accurate reflection of the real state of the package and make other people feel more free to fix the package.) The number of *patched* bugs is a lot smaller than the number of bugs total. It is also *far* more frustrating to have a patched bug ignored than to have an unpatched bug ignored. Also, analyzing them is far more likely to give quick package improvements than analyzing other bugs. I have to mention ifupdown in this context. The ifupdown maintainer isn't asking for help (and was offended at the suggestion that he should). He isn't fixing bugs. He has 19 bugs marked patch, most with no comment suggesting that there is any problem with the patch. And he has many bugs over a year old. And ifupdown does *not* get hundreds of bugs per month; there are fewer than 200 total. (No criticism of the hardworking comaintainer though, who's done excellent excellent work.) If the maintainer would release his death grip on the package and orphan it, I believe a team would spring up to maintain it almost immediately; I would be part of that team, and I expect the several previous NMUers might be too. A maintainer who deals with all his or her bugs can afford to be proprietorial. One who doesn't cannot afford to, but they so often do anyway. Point 3. Tedious bug triage is a major portion of package maintenance. Some people wish it wasn't, but it is. When you volunteer to maintain a package, you're volunteering to do at least some, and probably a lot, of this. People should be given assistance and encouragement in doing it. I actually like doing it, but I have unfortunately relatively little time (sick family members). -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Mon, Mar 26, 2007 at 09:12:32PM -0400, Nathanael Nerode wrote: If a package has a bug with a *patch* attached, where the *patch* has not been reviewed on by the maintainer(s) within six months, the package will be orphaned immediately; the maintainer will not be allowed to adopt it for at least a year, though he may comaintain and make uploads. (This should give a more accurate reflection of the real state of the package and make other people feel more free to fix the package.) Out of curiousity, what is the algorithm for determining whether a patch has been reviewed? If it is not an algorithm, per se, then what is the heuristic? Point 3. Tedious bug triage is a major portion of package maintenance. Some people wish it wasn't, but it is. When you volunteer to maintain a package, you're volunteering to do at least some, and probably a lot, of this. Perhaps this can become a component that AMs evaluate in their NM candidates? As part of my NM process, I had to prepare NMUs, prepare sponsored uploads, fix RC bugs, and so on. Adding bug triage in there would be a good thing. People should be given assistance and encouragement in doing it. I actually like doing it, but I have unfortunately relatively little time (sick family members). I like doing bug triage as well. I guess it is because I am a neat freak and anal about organization. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
Roberto C. Sánchez [EMAIL PROTECTED] wrote: Out of curiousity, what is the algorithm for determining whether a patch has been reviewed? If it is not an algorithm, per se, then what is the heuristic? If the maintainer has sent a message to the bug trail mentioning the patch sometime after the patch was attached to the bug trail, or the 'patch' tag has been removed, or the bug has been closed, then the maintainer has reviewed the patch. Reviewed it sufficiently for my purposes anyway! I don't think it can be done programatically because it requires knowing when the 'patch' tag was added and knowning whether the maintainer mentioned the patch; it's easy for a human to tell though. -- Nathanael Nerode [EMAIL PROTECTED] Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Mon, Mar 26, 2007 at 09:38:24PM -0400, Roberto C. Sánchez [EMAIL PROTECTED] wrote: People should be given assistance and encouragement in doing it. I actually like doing it, but I have unfortunately relatively little time (sick family members). I like doing bug triage as well. I guess it is because I am a neat freak and anal about organization. Would you still like it if the bug count for one package would number in hundreds ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wed, Mar 07, 2007 at 06:50:15PM -0500, Kevin Mark wrote: On Thu, Mar 08, 2007 at 12:37:39AM +0100, Pierre Habouzit wrote: snip I'm tired giving the link again and again, ON THE KDE USER LIST where it's the most probable place to find users caring about KDE rignt ? I snip it gave 0 DAMN USER WNATED TO HELP. From my perspective, it shows that the intended audience did not read that list or that particular mail or subscribed after it was sent... That list looks very low-traffic. I see no more than one page of archived posts for the last 4-5 months, compared to between 7 and 11 pages for debian-user. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Kevin Mark [EMAIL PROTECTED] writes: message to its intended target is a hard thing. How about having 'text ads' on the pages of the Debian site that showcase a 'request for help' or similar? I don't like ads. Ads are annoying. That doesn't mean they don't work. If I need some information I usually know where to look for it (for information that is conveyed in an ad anyway). An innocent potential helper will probably start at www.d.o and find the Help Debian link. Following that whould lead to all information needed. The next thing one might try is the Developers Corner If help requests are not accessible through those channels chances are slim that they will be noticed by the target audience. IMHO Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Thu, Mar 08, 2007 at 09:12:52AM -0500, Matthias Julius wrote: Kevin Mark [EMAIL PROTECTED] writes: message to its intended target is a hard thing. How about having 'text ads' on the pages of the Debian site that showcase a 'request for help' or similar? I don't like ads. Ads are annoying. That doesn't mean they don't work. If I need some information I usually know where to look for it (for information that is conveyed in an ad anyway). An innocent potential helper will probably start at www.d.o and find the Help Debian link. Following that whould lead to all information needed. The next thing one might try is the Developers Corner If help requests are not accessible through those channels chances are slim that they will be noticed by the target audience. IMHO It will likely be one of my last post on that matter because I feel that valuable contributors left it long ago. You're (not you Matthias, You the other people with those ideas) take the problem from the wrong side. The question is not about _how_ to attract people, but how did people that are now valuable contributors were attracted to what they do right now. When you'll know that we will be able to improve those things so that it gets even more attractive than now. I think I was a quite decent contributor for the kde group. I worked with those people because the project was on alioth, that the team was nice and open, and that there was an active IRC channel to talk with people on. I never went on debian.org that is the last idea I would have had to find an information, given how badly the site is designed and organized. I never knew about debian.org//help page before today. And I've never read RFH's for that, as again IMHO it's like some alarm thing, not meant as a permanent thing. Now everyone's experience is different. But ask that to good contributors, and you'll know what is important. Just know that none of the suggestions made so far would have helped me more when I was searching who/what to help, it would even have bored me. shouting for help everywhere is like noise: it's absurdly painful, and will itch people way too much. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMGEr0Qj6AQ.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Pierre Habouzit [EMAIL PROTECTED] writes: ] ] Again, I do not appreciate the latent criticism of the big teams ] ] to ] ] hide their understaff problem. It's blatantly bogus hence iritating, ] ] almost insulting. ] ] ] ] Don't you wonder why it is perceived like that? Which do seem like a quite not very hidden accusation, so yes, somebody is playing finger-pointing games here, and I'm tired of it. Actually, I am trying to not to accuse anybody of anything and not to point fingers. I know that you are very active within Debian and I appreciate the work you do. The same is true for many contributors. I just meant there must be a reason if many people say: I didn't now you needed help. Appearently you and others were unsuccessful in conveying the message that you do need help. And I was trying to promote the idea to use a central and permanently visible platform for such help requests (the RFH list). And I don't mean at all to say: Blame yourself for not getting help because you didn't send in a RFH! Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Thursday 08 March 2007, Pierre Habouzit wrote: It will likely be one of my last post on that matter because I feel that valuable contributors left it long ago. gee, thanks for the (probably unintented as the above statement includes yourself) implied insult You're (not you Matthias, You the other people with those ideas) take the problem from the wrong side. The question is not about _how_ to attract people, but how did people that are now valuable contributors were attracted to what they do right now. When you'll know that we will be able to improve those things so that it gets even more attractive than now. err ... logical flaw above look at how current contributors got attracted, and improve on what attracted them is a particular solution to the question how do we go about attracting people Also as I've pointed out several times in this thread now: _I_ got attracted as contributor to Debian because I saw a mail asking for help with something small and easy (and that gave an easy step-by-step on how to get involved with that). - the approach of sending mails asking for help that you've labeled pointless is an example of exactly what you say you're looking for above. Just know that none of the suggestions made so far would have helped me more when I was searching who/what to help, it would even have bored me. point to keep in mind is that people are different, respond to different things, and take different approaches - periodically asking in different ways makes sense, as does trying to making sure that whatever the path somebody might take to getting involved. That someone is likely to notice your request for help. shouting for help everywhere is like noise: it's absurdly painful, and will itch people way too much. There's a difference between 'shouting' and 'politely and invitingly asking for help' (or to use your metaphore noise has levels it's not a question of noise or no noise). As usual the key is balance: - you don't want to overdo it by constantly spamming every available channel. - But you don't want to go to the other extreme either. For example (and please keep in mind that I do _not_ mean this to be an attack on either you or the kde team) the information in this thread tells me that it has been over a year since the single mail from the kde team asking for help with bugs. Now that undoubtfully doesn't give the entire picture, as I'm sure there've been RFH's in other channels then debian-kde. Still it's been over a year since the last RFH on the debian-kde list, that's a rather long time. IMO a frequency of a couple (say 3 or 4) of RFH's per year would seem more likely to produce results. That said nobody is forcing you or any other DD/packaging team to ask for help in any particular way (or at all). So no need to get all worked up, if you find the suggestions in this thread impractical/useless then by all means ignore them, they're only suggestions. -- Cheers, cobaco (aka Bart Cornelis) pgpmiLjSYEQZo.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thu, Mar 08, 2007 at 09:12:52AM -0500, Matthias Julius wrote: Kevin Mark [EMAIL PROTECTED] writes: message to its intended target is a hard thing. How about having 'text ads' on the pages of the Debian site that showcase a 'request for help' or similar? I don't like ads. Ads are annoying. That doesn't mean they don't work. If I need some information I usually know where to look for it (for information that is conveyed in an ad anyway). I see no harm in addressing the issue in multiple ways. I have no problem with a FLOSS project 'asking' for help in an ad. I dont like ads for most other things. People take multiple paths to find stuff. Instead of assuming that 'if I found it, then everyone can!', I'd simply like to increase the avenues for people to find the help requests. More pageviews of help requests, the more possible help. I'd simply like for it to be given a trial rather than 'I know it will not work, therefore it must not be tried'. An innocent potential helper will probably start at www.d.o and find the Help Debian link. Following that whould lead to all information needed. The next thing one might try is the Developers Corner see above. If help requests are not accessible through those channels chances are slim that they will be noticed by the target audience. IMHO see above. -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
On Thu, Mar 08, 2007 at 03:43:39PM +0100, Pierre Habouzit wrote: snip It will likely be one of my last post on that matter because I feel that valuable contributors left it long ago. Would it be useful to personally email those people and 'ask them why' as a way to address the issue? You're (not you Matthias, You the other people with those ideas) take the problem from the wrong side. The question is not about _how_ to attract people, but how did people that are now valuable contributors were attracted to what they do right now. When you'll know that we will be able to improve those things so that it gets even more attractive than now. attracting and keeping people are 2 different things. Are you suggesting that debian-kde is attacting sufficient people but lately has had people leave for specific reasons? I think I was a quite decent contributor for the kde group. I worked with those people because the project was on alioth, that the team was nice and open, and that there was an active IRC channel to talk with people on. this sounds like a collegial and active community with many useful and friendly communication channels! Are any of those missing in other Debian subprojects? I never went on debian.org that is the last idea I would have had to find an information, given how badly the site is designed and organized. So you seem to seperate the 'alioth' environment from the 'debian.org' environment in your mind because of the more positive associations you've had with it. Makes sense to stay there and not wander elsewhere. I never knew about debian.org//help page before today. And I've never read RFH's for that, as again IMHO it's like some alarm thing, not meant as a permanent thing. Now everyone's experience is different. But ask that to good contributors, and you'll know what is important. see first comment. Just know that none of the suggestions made so far would have helped me more when I was searching who/what to help, it would even have bored me. Which is why multiple should be used. -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
Kevin Mark [EMAIL PROTECTED] writes: I see no harm in addressing the issue in multiple ways. I have no problem with a FLOSS project 'asking' for help in an ad. I dont like ads for most other things. People take multiple paths to find stuff. Instead of assuming that 'if I found it, then everyone can!', I'd simply like to increase the avenues for people to find the help requests. More pageviews of help requests, the more possible help. I'd simply like for it to be given a trial rather than 'I know it will not work, therefore it must not be tried'. Ads for non-commercial stuff are a little better than commercial ads. There is nothing wrong with publicizing a help request through several different channels. One can send an RFH, write a wiki page, post it on Alioth or on some mailing list. What I wouldn't like too much is a banner on www.d.o A clearly labelled link to the relevant information should be sufficient. I think it is better to make information easily accessible for someone who is interested in it than to push it out to everyone. Matthias
Re: On maintainers not responding to bugs
On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote: Pierre Habouzit [EMAIL PROTECTED] writes: Like every packaging team in debian, mailing the [EMAIL PROTECTED] or [EMAIL PROTECTED] depending on how old the team is. Usually that list is in the Maintainer or Uploaders field of the control file. #debian-$team is also a good place to look. Those things are _obvious_. Do you expect potential helpers to search various list archives or mail maintainers to ask whether they need help? I would guess only no I expect them to contact the teams, and entry points are obvious. Hiding behind the fact that entry points are not waved under their nose and that because of that they can't help is, well, Ubuesque. The mails I alluded to earlier (to seek for help) have seen (at least for the KDE guys, I'll let the Gnome guys tell you how it worked for them) 0 answer. My experience is that RFH bugs works well when Norbert put it on vim to ask for co-maitenance or such very interesting software to package. But when the job is to deal with KDE bugs, there is really less people eager to do the job. What does it hurt to file a RFH bug? At least it is a centralized platform where potential helpers can find out about who need help. And it is a logical place for that. And the list is posted weekly on -devel. because that's not one, but 1500, and that would not be very useful to flood RFH that are often specific needs for technicals matters. Here it's manpower missing, RFH seems inapropriate to me. Again, I do not appreciate the latent criticism of the big teams to hide their understaff problem. It's blatantly bogus hence iritating, almost insulting. Don't you wonder why it is perceived like that? Yes I do, especially given that in that thread those teams have claimed many times they need help, and that people continue to pretend like it never happened. So Yes I wonder if it's not that it's just easier to pretend it's our fault, than to question onself wtf didn't I helped before already ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp7NlVHTQFZ8.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tue, Mar 06, 2007 at 11:39:16AM -0800, Don Armstrong wrote: On Tue, 06 Mar 2007, Pierre Habouzit wrote: And if your point is that the current BTS UI sucks, then well, yes I believe it, and it seems one of our DPL candidates thinks the same As I've indicated to the DPL candidate who has mentioned this, and I'll say again: If there are specific things about the BTS which you do not like, file wishlist bugs or clarify existing wishlist bugs for them. One does not need to be running for DPL to do that. Just complaining about it is pointless. I know, and I'm not making any reproaches, only stating a fact. I've no time right now to think of a better interface yet. I don't like the lookup interface of our BTS, though I do not like any query interface of any bug tracking system I know. So it's not just making suggestions it's also defining something new, and I've no time for that. The mail you are answering to was against forums, not really against the BTS btw. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTLKdFLvBR5.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Le Wed, Mar 07, 2007 at 02:19:17PM +0100, Pierre Habouzit a écrit : The mail you are answering to was against forums, not really against the BTS btw. Bonsoir Pierre, I have lurked a bit on the ubuntu forums, and found intersting threads. For instance, some persons wrote about doing a sort of medical Ubuntu project, and then realised that debian-med was alive, and wrote at the end of the thread that being less people with less experience, they could not do better than us. The conclusion I took after reading this is that there are people (often young) eager to find a niche in which they can be leaders (this is also how I interpreted one of your previous email). The question is wether we should try to attract them, and if yes, where and how. Maybe having a way to quantitatively evaluate bug triaging and giving conditional access to some reward could for instance motivate untrained persons to contribute ? The reward can be as simple as using the score to provide some social status on communauty websites. For instance, in the forums of Ubuntu, people have more or less brown coffee grains (to suggest that they are stronger ?). I have tried a few fishing experiments when Google brought me on places dealing with free medical or bioinformatical software, and I have to admit that for the moment my fish basket is empty. But if it is in forums and other platforms which we deem sub-optimal there that people who have energy to spend are, isn't it where Debian should go if it wants to increase its manpower ? I will continue to do opportunistic fishing for a while... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wed, Mar 07, 2007 at 10:47:09PM +0900, Charles Plessy wrote: Le Wed, Mar 07, 2007 at 02:19:17PM +0100, Pierre Habouzit a écrit : The mail you are answering to was against forums, not really against the BTS btw. Bonsoir Pierre, I have lurked a bit on the ubuntu forums, and found intersting threads. For instance, some persons wrote about doing a sort of medical Ubuntu project, and then realised that debian-med was alive, and wrote at the end of the thread that being less people with less experience, they could not do better than us. The conclusion I took after reading this is that there are people (often young) eager to find a niche in which they can be leaders (this is also how I interpreted one of your previous email). The question is wether we My point was not becoming a local leader, but having a place in the team where my opinion matters. No need to be a leader for that, at all. E.g. I've never ever felt beeing in the place of a leader in the KDE team, there even was nothing like a leader in it. And I shall say, it was, and think still is a very nice team to work with, I enjoyed the people in it a lot. should try to attract them, and if yes, where and how. Maybe having a way to quantitatively evaluate bug triaging and giving conditional access to some reward could for instance motivate untrained persons to contribute ? The reward can be as simple as using the score to provide some social status on communauty websites. For instance, in the forums of Ubuntu, people have more or less brown coffee grains (to suggest that they are stronger ?). I have tried a few fishing experiments when Google brought me on places dealing with free medical or bioinformatical software, and I have to admit that for the moment my fish basket is empty. But if it is in forums and other platforms which we deem sub-optimal there that people who have energy to spend are, isn't it where Debian should go if it wants to increase its manpower ? I will continue to do opportunistic fishing for a while... Any kind of help is welcomed IMHO. Point is, if we _have_ to invest time to fish contributors like you say, those will have to be worth the investment, hence meaning that they should have a high probability to become regular contributors. Youngs people are often enthusiastic, a lot, but I'm not sure this is the kind of people that gets things done either. Note that I don't say it's not worth trying, it's just that I would not do that myself, I _think_ it's too time consuming when you balance it with the gain for debian. I may be wrong. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoaqwKo0iKO.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Wednesday 07 March 2007, Pierre Habouzit wrote: On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote: Pierre Habouzit [EMAIL PROTECTED] writes: Like every packaging team in debian, mailing the [EMAIL PROTECTED] or [EMAIL PROTECTED] depending on how old the team is. Usually that list is in the Maintainer or Uploaders field of the control file. #debian-$team is also a good place to look. Those things are _obvious_. Do you expect potential helpers to search various list archives or mail maintainers to ask whether they need help? I would guess only no I expect them to contact the teams, and entry points are obvious. Hiding behind the fact that entry points are not waved under their nose and that because of that they can't help is, well, Ubuesque. You're missing a couple of points here: 1) That only gets you the help of those that are actively seeking to get involved (and that's a small minority of potential helpers) 2) Those actively seeking to get involved with Debian will tend to look jump in in areas that both interest them AND obviously need help (or at least they'll jump in there first. To give an anecdotal example: I first got actively involved with Debian, because I saw a message asking for translations of the debian-edu install questions, that stated a translation would only take 10-15 minutes. I figured I can do that, and got more and more involved from there (and I wasn't the only one to help out in reaction to that mail) From what I've observed that's a quite common patern - asking for help, and taking care where and how to ask, can make a huge difference in the amount of help you receive. Again, I do not appreciate the latent criticism of the big teams to hide their understaff problem. It's blatantly bogus hence iritating, almost insulting. Don't you wonder why it is perceived like that? Yes I do, especially given that in that thread those teams have claimed many times they need help, and that people continue to pretend like it never happened. There's been a couple of blogs about the fact that in response to this thread somebody jumped in and started working on antiquated KDE-bugs. - seems like asking for help had some effect in this case doesn't it? Secondly debian-devel is probably not the best forum for getting help with triaging old bugs why not? Because most people on the list are already heavily involved with Debian, and busy working on their own little problems. So maybe asking for help on debian-kde, where there's people around who might be convinced to pitch in a little time and effort once or twice would be more productive. I'm thinking something along the lines of: Subject: Adopt a bug community drive Hi all, greetings from the KDE-team First for the good news: we're currently managing to keep up with new bugs and quality of the KDE packages is good and improving :) However we have a lot of old antiquated bugs on kdebase that pre-date the formation of the kde-team, and we need your help to clean those up. We'd like each of you to pick out just 1 old bug and help update the information in it (you're of course welcome to do more then 1 :). Mostly this is a question of doing what people on this list are always doing, namely aks the submitter for the necessary information to get at the cause of the bug, and checking if the bug has been reported in the KDE bugzilla, and so on. To make helping even easier here is a step by step instruction on cleaning up old bugs in the Debian BTS: 1) point your browser to the list of kdebase bugs at [1] 2) pick a bug (send a reply to this message on list to avoid multiple people picking the same bug) 3) check the upstream BTS to see if the same bug is reported there, if so ... NOTE: point 2 is opportunity for a bit of bit of social engineering: if everybody in the team picks 1 antiquated bug to follow up on and sends a reply to the list, people will have the impression that something good is happening, mostly the'll go well, I can do that, and will thus be more likely to jump in. Important points here are: 1) you ask for help 2) you do so in a forum where people are interested in KDE, and a lot of people won't be heaviliy involved yet 3) you point out that helping out does not require special skills or major effort (thus lowering the barrier to entry) 4) you give a step by step instruction of how to get involved (again lowering the barrier to entry) So Yes I wonder if it's not that it's just easier to pretend it's our fault Nobody is saying anybody is at fault, which doesn't mean there's no room for improvement. -- Cheers, cobaco (aka Bart Cornelis) pgpWIPSilGjgg.pgp Description: PGP signature
Re: On maintainers not responding to bugs
cobaco (aka Bart Cornelis) [EMAIL PROTECTED] wrote: [snip] So maybe asking for help on debian-kde, where there's people around who might be convinced to pitch in a little time and effort once or twice would be more productive. I'm thinking something along the lines of: This might have even bigger impact on debian-user. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote: Pierre Habouzit [EMAIL PROTECTED] writes: Do you expect potential helpers to search various list archives or mail maintainers to ask whether they need help? I would guess only no I expect them to contact the teams, and entry points are obvious. Hiding behind the fact that entry points are not waved under their nose and that because of that they can't help is, well, Ubuesque. It's a matter of how someone arrives at the point where he wants to help. If he wakes up one morning and thinks I want to help the KDE team he will probably contact the KDE maintainers. If he thinks Since 3 years I am using Debian it's time for me to contribute. he might look in more generic places to find out who requests help. What does it hurt to file a RFH bug? At least it is a centralized platform where potential helpers can find out about who need help. And it is a logical place for that. And the list is posted weekly on -devel. because that's not one, but 1500, and that would not be very useful to flood RFH that are often specific needs for technicals matters. Here it's manpower missing, RFH seems inapropriate to me. Does a RFH need to be that specific? I think those 0-day NMU mails from last week might be well suited for RFH. I think it is beneficial if the help request is permanently visible compared to being burried in some list archive. If you wanted to request help for a specific bug you would tag it 'help'. Am I correct? Again, I do not appreciate the latent criticism of the big teams to hide their understaff problem. It's blatantly bogus hence iritating, almost insulting. Don't you wonder why it is perceived like that? Yes I do, especially given that in that thread those teams have claimed many times they need help, and that people continue to pretend like it never happened. So Yes I wonder if it's not that it's just easier to pretend it's our fault, than to question onself wtf didn't I helped before already ? Well, of course, it is always easier to blame everybody else. I just think an argument like We have a RFH out since one year and nobody cared. will work better for you than We sent a request to -kde a year ago and nobody responded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Matthias Julius, 2007-03-07 11:32:32 -0500 : It's a matter of how someone arrives at the point where he wants to help. If he wakes up one morning and thinks I want to help the KDE team he will probably contact the KDE maintainers. If he thinks Since 3 years I am using Debian it's time for me to contribute. he might look in more generic places to find out who requests help. In that case, I suppose http://www.debian.org/intro/help should be made a bit more helpful. More visible, more readable, and so on. I understand one of the DPL candidates intends to work (or get people to work) on the Debian website; I suggest this page could be considered during that endeavour. Roland. -- Roland Mas With the arrest of Dimitry Sklyarov it has become apparent that it is not safe for non US software engineers to visit the United States. - Alan Cox -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wed, Mar 07, 2007 at 03:28:45PM +0100, cobaco (aka Bart Cornelis) wrote: So maybe asking for help on debian-kde, where there's people around who might be convinced to pitch in a little time and effort once or twice would be more productive. I'm thinking something along the lines of: yadayadayada just consider mailing debian-kde _HAS FG BEEN DONE ALREADY_ and I'm tired giving the link again and again, ON THE KDE USER LIST where it's the most probable place to find users caring about KDE rignt ? I recall for the other here that debian-kde is a user list, the maintainer one is debian-qt-kde. The damn mail is here: http://lists.debian.org/debian-kde/2006/01/msg00215.html it gave 0 DAMN USER WNATED TO HELP. IS IT CLEAR ENOUGH OR SHOULD I USE SOM ASCII-CAPS-LOCK-TOILET-POWERED MAIL ? So Yes I wonder if it's not that it's just easier to pretend it's our fault Nobody is saying anybody is at fault, which doesn't mean there's no room for improvement. This was answering to: ] ] Again, I do not appreciate the latent criticism of the big teams ] ] to ] ] hide their understaff problem. It's blatantly bogus hence iritating, ] ] almost insulting. ] ] ] ] Don't you wonder why it is perceived like that? Which do seem like a quite not very hidden accusation, so yes, somebody is playing finger-pointing games here, and I'm tired of it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpBs6tWWvcmz.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thu, Mar 08, 2007 at 12:37:39AM +0100, Pierre Habouzit wrote: On Wed, Mar 07, 2007 at 03:28:45PM +0100, cobaco (aka Bart Cornelis) wrote: So maybe asking for help on debian-kde, where there's people around who might be convinced to pitch in a little time and effort once or twice would be more productive. I'm thinking something along the lines of: yadayadayada just consider mailing debian-kde _HAS FG BEEN DONE ALREADY_ and I'm tired giving the link again and again, ON THE KDE USER LIST where it's the most probable place to find users caring about KDE rignt ? I recall for the other here that debian-kde is a user list, the maintainer one is debian-qt-kde. The damn mail is here: http://lists.debian.org/debian-kde/2006/01/msg00215.html it gave 0 DAMN USER WNATED TO HELP. From my perspective, it shows that the intended audience did not read that list or that particular mail or subscribed after it was sent... Also, how often do you view advertisements on TV for say food, movies or other items? Once? no, often! Why? Advertising is something that has to be done as an on going process to get maximum results. Getting your message to its intended target is a hard thing. How about having 'text ads' on the pages of the Debian site that showcase a 'request for help' or similar? -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
Roland Mas [EMAIL PROTECTED] writes: Matthias Julius, 2007-03-07 11:32:32 -0500 : It's a matter of how someone arrives at the point where he wants to help. If he wakes up one morning and thinks I want to help the KDE team he will probably contact the KDE maintainers. If he thinks Since 3 years I am using Debian it's time for me to contribute. he might look in more generic places to find out who requests help. In that case, I suppose http://www.debian.org/intro/help should be made a bit more helpful. More visible, more readable, and so on. I understand one of the DPL candidates intends to work (or get people to work) on the Debian website; I suggest this page could be considered during that endeavour. I don't consider it to be too bad. But it would be a good step forward if it contained a reference to the RFH list. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tue, Mar 06, 2007 at 09:06:42AM +0900, Charles Plessy wrote: So to generalise, it seems that there is the choice between seeing repetitive work done imperfectly by beginners, or never done by experienced people who are busy doing something else. Definitely the way the contributors are supervised can raise the quality strongly. In the end, there has been a lot of talk to judge wether some teams accept or refuse help, but in my opinion, a more relevant question is why the help is not coming to those who ask for it. Obvously, one answer can be that help is not asked the most efficient way. For instance, irc is an very unfriendly communication channel, and even mailing-lists are somewhat unpopular among a broad category of internauts, who prefer forums. eeerm I'm not sure to follow you, how to you help in bug triaging (which is the thing that needs the most manpower and was discussed here) through a forum ? I'm a bit confused, it seems like you're telling some generalities, and not really proposing solutions. And if your point is that the current BTS UI sucks, then well, yes I believe it, and it seems one of our DPL candidates thinks the same :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpIrJEc2DCc5.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, Mar 05, 2007 at 05:35:43PM +, Jon Dowland wrote: wow, I'm really amazed. For the KDE and Gnome teams (and I'm sure others did it as well) there was mails requesting help to triage bugs and so on (from january 2006). Reading this thread could let people believe that those teams neved did that, and always denied they needed help. Well, sorry if I don't like the sound of that, but I really don't because it's at the antipodes of the reality. Reading this thread makes me think that people are not aware that those teams have requested help. Like every packaging team in debian, mailing the [EMAIL PROTECTED] or [EMAIL PROTECTED] depending on how old the team is. Usually that list is in the Maintainer or Uploaders field of the control file. #debian-$team is also a good place to look. Those things are _obvious_. Do you expect potential helpers to search various list archives or mail maintainers to ask whether they need help? I would guess only people who have a specific issue with a package they want to get fixed would do that. One way is the existing wnpp system. http://www.debian.org/devel/wnpp/help_requested lists packages which have RFH filed. This list is very short and doesn't seem to include the examples which have been put forward in this thread at all. For such packages, where triage would be needed, would it not make sense to file an RFH bug to that effect? The mails I alluded to earlier (to seek for help) have seen (at least for the KDE guys, I'll let the Gnome guys tell you how it worked for them) 0 answer. My experience is that RFH bugs works well when Norbert put it on vim to ask for co-maitenance or such very interesting software to package. But when the job is to deal with KDE bugs, there is really less people eager to do the job. What does it hurt to file a RFH bug? At least it is a centralized platform where potential helpers can find out about who need help. And it is a logical place for that. And the list is posted weekly on -devel. What it probably needs is a link from http://www.debian.org/intro/help to make it more obvious for people not yet familiar with Debian. Again, I do not appreciate the latent criticism of the big teams to hide their understaff problem. It's blatantly bogus hence iritating, almost insulting. Don't you wonder why it is perceived like that? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tue, 06 Mar 2007, Pierre Habouzit wrote: And if your point is that the current BTS UI sucks, then well, yes I believe it, and it seems one of our DPL candidates thinks the same As I've indicated to the DPL candidate who has mentioned this, and I'll say again: If there are specific things about the BTS which you do not like, file wishlist bugs or clarify existing wishlist bugs for them. One does not need to be running for DPL to do that. Just complaining about it is pointless. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote: Simply replying to a bug won't get it fixed any sooner or decrease the impact it has on the user. In addition, it distracts us from doing what is potentially far more productive work. Writing a mail to a bug along the lines of I've read the bug, it's valid, thanks takes seconds if anything. What really takes the time is reading the bug, and determining if it is valid. Until you've done that, how can you know how important the bug is, and whether it is a lower priority than the productive work that you think sending such a mail would distract you from? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 10:57:46AM +0100, Pierre Habouzit wrote: And I think the list can grow larger just by looking at the reality, and not dreaming stupid ideas and trying to defend them. snip Just _look_ at that: [0]. I mean _look_, not pretend to. Instead of answering to that thread, arrogantly explaining to us how bad we suck, snip Even if you do think it's a crazy idea you should not be angered or offended by the suggestion and debate of such an idea. That's what an open operating system should encourage. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 07:07:33PM +0100, Mike Hommey wrote: Now, the iceape case is interesting: *you* (as in, the one complaining about rotting bugs) are also allowed to help the maintainers instead of whining. One very positive thing from this thread is the number of packages / teams that are openly admitting that there is a manpower problem. I think that there is an untapped pool of people who could help a lot with the triage work, but the question is, where do they start? How do they know that they are welcome to start responding to a given packages bugs with some kind of analysis? One way is the existing wnpp system. http://www.debian.org/devel/wnpp/help_requested lists packages which have RFH filed. This list is very short and doesn't seem to include the examples which have been put forward in this thread at all. For such packages, where triage would be needed, would it not make sense to file an RFH bug to that effect? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Mar 05, 2007, Jon Dowland wrote: I think that there is an untapped pool of people who could help a lot with the triage work, but the question is, where do they start? How do they know that they are welcome to start responding to a given packages bugs with some kind of analysis? I think you missed the 0-day bug forwarding and bug patching on * bugs mails: http://lists.debian.org/debian-devel/2007/02/thrd2.html#00785 -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Mar 05, 2007 at 05:35:43PM +, Jon Dowland wrote: On Mon, Feb 26, 2007 at 07:07:33PM +0100, Mike Hommey wrote: Now, the iceape case is interesting: *you* (as in, the one complaining about rotting bugs) are also allowed to help the maintainers instead of whining. One very positive thing from this thread is the number of packages / teams that are openly admitting that there is a manpower problem. wow, I'm really amazed. For the KDE and Gnome teams (and I'm sure others did it as well) there was mails requesting help to triage bugs and so on (from january 2006). Reading this thread could let people believe that those teams neved did that, and always denied they needed help. Well, sorry if I don't like the sound of that, but I really don't because it's at the antipodes of the reality. I think that there is an untapped pool of people who could help a lot with the triage work, but the question is, where do they start? Like every packaging team in debian, mailing the [EMAIL PROTECTED] or [EMAIL PROTECTED] depending on how old the team is. Usually that list is in the Maintainer or Uploaders field of the control file. #debian-$team is also a good place to look. Those things are _obvious_. How do they know that they are welcome to start responding to a given packages bugs with some kind of analysis? Well, you don't need to be a developer neither a regular contributor to do that, don't hide behind false excuses. One way is the existing wnpp system. http://www.debian.org/devel/wnpp/help_requested lists packages which have RFH filed. This list is very short and doesn't seem to include the examples which have been put forward in this thread at all. For such packages, where triage would be needed, would it not make sense to file an RFH bug to that effect? The mails I alluded to earlier (to seek for help) have seen (at least for the KDE guys, I'll let the Gnome guys tell you how it worked for them) 0 answer. My experience is that RFH bugs works well when Norbert put it on vim to ask for co-maitenance or such very interesting software to package. But when the job is to deal with KDE bugs, there is really less people eager to do the job. Again, I do not appreciate the latent criticism of the big teams to hide their understaff problem. It's blatantly bogus hence iritating, almost insulting. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDl4u7GFVqs.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Le Mon, Mar 05, 2007 at 07:48:01PM +0100, Pierre Habouzit a écrit : Like every packaging team in debian, mailing the [EMAIL PROTECTED] or [EMAIL PROTECTED] depending on how old the team is. Usually that list is in the Maintainer or Uploaders field of the control file. #debian-$team is also a good place to look. Those things are _obvious_. Hi all, I sometimes look over the fence to see how our neighbour does, and it seems to me that the way they recruit helpful people is through communication channels which does not require ab-initio knowkedge of their internal organisation. There are forums and mailing lists, and also they have a welcome gift for people who start to contribute, a shiny @ubuntu.com email alias. I have witnessed a period of activity on ubuntu-science, and clearly there are pros and cons on getting the help of newcommers. One one hand the work is done, but on the other, you can not expect its quality to be the same as what a DD with 10 years of experience would do. For instance, many .desktop files were created, icons were added, and licence of icons were not checked. So to generalise, it seems that there is the choice between seeing repetitive work done imperfectly by beginners, or never done by experienced people who are busy doing something else. Definitely the way the contributors are supervised can raise the quality strongly. In the end, there has been a lot of talk to judge wether some teams accept or refuse help, but in my opinion, a more relevant question is why the help is not coming to those who ask for it. Obvously, one answer can be that help is not asked the most efficient way. For instance, irc is an very unfriendly communication channel, and even mailing-lists are somewhat unpopular among a broad category of internauts, who prefer forums. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Fri, 2007-03-02 at 18:57 +0100, Pierre Habouzit wrote: but I would obviously lessen my implication and work for other teams where I've a single damn chance to see my contribution to be compareable to the others. Better a big fish in a small pond than a small fish in a big pond huh? So much for the idea of team work. -Sigh -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: On maintainers not responding to bugs
On Sat, Mar 03, 2007 at 09:03:40PM +1100, Robert Collins wrote: On Fri, 2007-03-02 at 18:57 +0100, Pierre Habouzit wrote: but I would obviously lessen my implication and work for other teams where I've a single damn chance to see my contribution to be compareable to the others. Better a big fish in a small pond than a small fish in a big pond huh? So much for the idea of team work. You misread me. Better a fish of the same size of the other in a team as large as you want, than a ridiculous small fish aside a gigantic one. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp3Y6aIlPEdL.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Fri, Mar 02, 2007 at 06:57:01PM +0100, Pierre Habouzit wrote: You forgot a single damn point: in debian, like in many projects, the one that do things is often the guy that decide things because he's the one there. If you put people that work 5 times more as me because they have the time to do that, I will obviously feel they took my place. I'm not sure what I would do in those cases. Obviously not refusing the help and people that have the time to do this, but I would obviously lessen my implication and work for other teams where I've a single damn chance to see my contribution to be compareable to the others. The principle you stated obviously tends to be the case in volunteer organizations, true. It does not have to be the case of a paid employee, but yes, even if the maintainer team sets the general policy and gives direction to the employee, there will be a lot of hour-to-hour operational control which you will be ceding to the employee (unless you want to be one of those awful micro-managing managers --- but that's not a path to productivity, either for the manager or the managee! :-) I would feel bad to impose my views to a person that has huges amounts of time to work in the team. And necessarily (because of human nature) a decision will happen that I would not like or would have made differently, and at that point I guess that I would just leave. Well, anytime we have people working on a package with team maintenance, there are bound to be disagreements. If we all left the moment a decision was made that we didn't agree with, Debian would be empty. I can't read your mind, of course, but it may be that the harder psychological hurdle is the one where a DD realizes that (say) 10 hours a week of volunteer labor is no longer enough to be one of the primary contributors on a package team. That is a real issue, and perhaps maybe _the_ major issue. Whereas in balanced teams where every contributor has the same level of contribution, I would have argued my point, or tried to make the proposal better, or discussed it or... whichever adequate behaviour in a team where every single member is equal to the other. Although this may be a great platonic ideal, the reality is that no team is going to be completely balanced. First of all, not everyone does _can_ contribute at the same level. Some people have jobs that cause them to work very long hours, for example. (And of these, some of them would like to be able to help Debian, and one of the ways they might be willing and able do so is via contributing money, not time.) Secondly, even if assume that everyone could give the same number of hours of contribution, the reality is that different people have different levels of talent --- and it is still the case in the programming world that differences in talent can account for 2+ orders of magnitude in productivity. So in the end, talent will probably still dominate far more than whether someone can work 10 hours as a volunteer versus 40 hours as a paid employee. (This I think is one of the ways that an examples of paid versus volunteer firemen may not be applicable for Debian.) Money introduces bias. OK you were talking about bug triaging, and bug triaging is not necessarily a big decision making place, I agree. Though it will depend a lot of the kind of people you want to recruit: * if those are already contributors they will want to take more and more decisions, and won't only do bug triaging: if you do bug triaging you begin to know packages a lot, and become skilled enough to take decisions, and so on. Then commits rights are granted, and you take more and more responsibilities. That's good, it's indeed what is often suggested to newcomers. Though we end up in the not-so-nice situation I described. Money introduces bias; no question. But it also does introduce a certain amount of control. For example, suppose we only paid people to do bug triaging. If they want to do more, that's great but it will be on their own time. Would something like this magically make all of the problems go away? Of course not, but I think it shows that with the right amount of thoughtfulness, it's possible to make the benefits outweight the costs. but please, I'm not sure there is a damn single maintainer in a big team that will refuse help, paid or not. I don't really understand how that mythical maintainer in a big team that refuses help has emerged in the discussions, but I'd really like names here. In fact, that seems pretty contradictory with the very notion of a team. Of course, there is teams with 1 single member in it in debian, but that's not a large team and is out of the scope if I'm not mistaken. Well, Josselin has been very negative about the whole concept of paying volunteers, and given that he was asking for help, and saying that his GNOME team was drowning under bug reports, I couldn't help but reply that if he
Re: On maintainers not responding to bugs
Le samedi 03 mars 2007 à 10:45 -0500, Theodore Tso a écrit : Well, Josselin has been very negative about the whole concept of paying volunteers, and given that he was asking for help, and saying that his GNOME team was drowning under bug reports, I couldn't help but reply that if he really was serious about wanting help, would it extend to accepting paid help since many people have asserted that they would leave the project if some of the contributors to debian were paid, in effect trying to hold the project hostage against paying developers. Part of the reason why I suspect they are doing this is specifically because of some of the fears which you outlined above, and which I acknowledge are real ones and ones which are legitimate. You are again biasing the discussion by trying to make your dunc-tank paid developers look like paid developers we already have. If some company wishes to see GNOME in Debian work better and starts paying someone to do packaging and bug-triaging work on the GNOME packages, he will be welcome. This may lead to other members of the team doing less, but the overall quality of the packages would improve. Oh, and this already happens with volunteer members. When someone has more time and does plenty of uploads, you can magically see contributions from other members decrease. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: On maintainers not responding to bugs
On Sat, 3 Mar 2007 10:45:47 -0500, Theodore Tso [EMAIL PROTECTED] said: The principle you stated obviously tends to be the case in volunteer organizations, true. It does not have to be the case of a paid employee, but yes, even if the maintainer team sets the general policy and gives direction to the employee, there will be a lot of hour-to-hour operational control which you will be ceding to the employee (unless you want to be one of those awful micro-managing managers --- but that's not a path to productivity, either for the manager or the managee! :-) I can't read your mind, of course, but it may be that the harder psychological hurdle is the one where a DD realizes that (say) 10 hours a week of volunteer labor is no longer enough to be one of the primary contributors on a package team. That is a real issue, and perhaps maybe _the_ major issue. Volunteers volunteer because of non-monetary rewards they gain from contributing. And merely improved quality of packages does not explain spending the time giving away ones labour for no mopnetary remuneration when you could be working on paid basis to get the money for eating out at a fancy restautrant or buying the new guitar. Volunteers take part in activity that is fun, accomplishing tasks that give one a feeling of accomplishment, and, to a large extent, respect from their peers for the work they do. If a paid employee does the lions share of the work, and thus makes the decisions, garners (rightly) the kudos for the work done, then the volunteer might have lost all the incentives they had to do the activity in the first place. In order to get the fun (decisions, design, crafting a well made piece of work), and recognition, it is not unreasonable to expect the volunteer to find other areas where they can still get the rewards and satisfaction they sought in their volunteer work in the first place. So it seems to me that there would be a significant motion of volunteers to paid employees. And then, or course, all the underlying forces that govern a company with paid employees would be in play in Debian. Perhaps such a transition is what is best for someone, I suppose. But I definitely do not look at these influences with equanimity. manoj -- A good awakening have ever Gotama's disciples, whose recollection is always established, day and night on the body. 299 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote: Volunteers volunteer because of non-monetary rewards they gain from contributing. Really? I volunteer (in addition to the altruistic reasons) because I want to learn more about Linux and Debian, which makes me a better consultant to people and also improves future job prospects. Those two things are decidedly monetary gains. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
On Saturday 03 March 2007, Theodore Tso wrote: So I understand where people are coming from when they say that they want Debian to remain 100% fully volunteer. But first of all, that isn't even true even now; HP is funding some DD's to work mostly on Debian-related projects, and certainly some DD's are being paid by Cannonical, for example. But secondly and more importantly, there people withour community that have aspirations to be better than what we can currently offer to our users now, and this includes responding to bug reports in a timely fashion, and for some people at least, getting releases out on time and with stable not being quite so embarassingly out-of-date for quite as long before we can get the next release of stable out. There's a humongous difference between Debian paying people to work on Debian and 3rd parties like HP paying people to Debian. In particular having Debian paying for labor, moves the decision of who gets payed to work on what into Debian. Doing so brings with it a whole new level of politics. I think we should be very, very carefull before we change the equation that way. - There's a difference between saying that Debian should remain 100% volunteer, and sayin Debian should not become an employer. -- Cheers, cobaco (aka Bart Cornelis) pgpyrwRlmfZhu.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Sat, Mar 03, 2007 at 11:26:51AM -0500, Roberto C. Sanchez wrote: On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote: Volunteers volunteer because of non-monetary rewards they gain from contributing. Really? I volunteer (in addition to the altruistic reasons) because I want to learn more about Linux and Debian, which makes me a better consultant to people and also improves future job prospects. Those two things are decidedly monetary gains. If you're volunteering on a project and someone with more time does all the work that involves learning, you don't end up learning much because you don't end up solving much. On the other hand, if your job involves so much of the same work over and over again, you don't get to learn new things either. I've spent the last year and a half (two years? I've lost count) trying to learn more about X, but I've spent most of my time just doing packaging because it takes so much time. I can't say I've been able to learn much and improve my skills though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sat, Mar 03, 2007 at 11:50:56AM -0500, David Nusinow wrote: If you're volunteering on a project and someone with more time does all the work that involves learning, you don't end up learning much because you don't end up solving much. On the other hand, if your job involves so much of the same work over and over again, you don't get to learn new things either. I've spent the last year and a half (two years? I've lost count) trying to learn more about X, but I've spent most of my time just doing packaging because it takes so much time. I can't say I've been able to learn much and improve my skills though. Good and valid points. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
On Sat, 3 Mar 2007 11:26:51 -0500, Roberto C Sanchez [EMAIL PROTECTED] said: On Sat, Mar 03, 2007 at 10:16:17AM -0600, Manoj Srivastava wrote: Volunteers volunteer because of non-monetary rewards they gain from contributing. I should have known better to not guard against nit picking. Let me put it this way: if one volunteers to do some work for $REWARD, where $REWARD != money, and if one does not have tie to spend on it as one would for a full time job, then the situation *MAY* arise that the paid employee, with more time, and focus, has done the taks before you get a round tuit. That means $REWARD does not come to you. Let me now address the specific case you raise: Really? I volunteer (in addition to the altruistic reasons) because I want to learn more about Linux and Debian, which makes me a better consultant to people and also improves future job prospects. Those two things are decidedly monetary gains. So, when you find that you are not learning much because the paid employee has tackled everything on your plate to do to learn things while you were struggling with item number 1, and does anything quicker than you do, because, well, they have more time, and are learning faster than you because they do the work and, you know, practice helps. You are relegated to reading other people's code, with is not the best way to learn. You'll be learning faster, making mistakes and learning from them, were you to go into an area where no one just steps in and does your work for you. manoj who, since Ted is involved in this thread, is not gonna post more than twice in a 24 hour period. With this mail, my quota is up for the day. -- Happiness isn't having what you want, it's wanting what you have. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tue, Feb 27, 2007 at 10:30:39AM +0100, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? So how do you help a maintainer who refuses help if it is paid? OK. The large teams are *COMPLETELY UNDERSTAFFED*. Volunteer labor is not able to keep up. Suppose we or some outside organization like dunc-tank raised money to pay someone who could afford to work full-time, 40 hours a week, doing bug triage for these large projects. Would those projects refuse help if the people doing the work happened if some of the people who showed up to help you from not drowning in bug reports just happened to be paid by Debian or by an outside group to do this work for which you have so eloquently said it's hard to get volunteers, and for which others have said is completely unfun, tedious work? Even if one or two people (for reasons that I don't understand) would stop spending maybe 10-12 hours a week on top of whatever they do during the day to earn money to feed his family because there is now some paid help, I would think that raising money to find someone to work 40 hours a week would be a Good Thing - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Le vendredi 02 mars 2007 à 08:37 -0500, Theodore Tso a écrit : So how do you help a maintainer who refuses help if it is paid? Hahaha, awesome. You don't miss any occasion, do you? Thanks, you really made my day. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. This mail is not about Mark Shuttleworth. signature.asc Description: Ceci est une partie de message numériquement signée
Re: On maintainers not responding to bugs
On Fri, Mar 02, 2007 at 08:37:01AM -0500, Theodore Tso wrote: On Tue, Feb 27, 2007 at 10:30:39AM +0100, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? So how do you help a maintainer who refuses help if it is paid? OK. The large teams are *COMPLETELY UNDERSTAFFED*. Volunteer labor is not able to keep up. Suppose we or some outside organization like dunc-tank raised money to pay someone who could afford to work full-time, 40 hours a week, doing bug triage for these large projects. Would those projects refuse help if the people doing the work happened if some of the people who showed up to help you from not drowning in bug reports just happened to be paid by Debian or by an outside group to do this work for which you have so eloquently said it's hard to get volunteers, and for which others have said is completely unfun, tedious work? Even if one or two people (for reasons that I don't understand) would stop spending maybe 10-12 hours a week on top of whatever they do during the day to earn money to feed his family because there is now some paid help, I would think that raising money to find someone to work 40 hours a week would be a Good Thing You forgot a single damn point: in debian, like in many projects, the one that do things is often the guy that decide things because he's the one there. If you put people that work 5 times more as me because they have the time to do that, I will obviously feel they took my place. I'm not sure what I would do in those cases. Obviously not refusing the help and people that have the time to do this, but I would obviously lessen my implication and work for other teams where I've a single damn chance to see my contribution to be compareable to the others. I would feel bad to impose my views to a person that has huges amounts of time to work in the team. And necessarily (because of human nature) a decision will happen that I would not like or would have made differently, and at that point I guess that I would just leave. Whereas in balanced teams where every contributor has the same level of contribution, I would have argued my point, or tried to make the proposal better, or discussed it or... whichever adequate behaviour in a team where every single member is equal to the other. Money introduces bias. OK you were talking about bug triaging, and bug triaging is not necessarily a big decision making place, I agree. Though it will depend a lot of the kind of people you want to recruit: * if those are already contributors they will want to take more and more decisions, and won't only do bug triaging: if you do bug triaging you begin to know packages a lot, and become skilled enough to take decisions, and so on. Then commits rights are granted, and you take more and more responsibilities. That's good, it's indeed what is often suggested to newcomers. Though we end up in the not-so-nice situation I described. * Or it's a one-time job (even if that need to be run for 6 month to reduce the backlog we have in some teams) and well, I don't really see the durability here. If you really want to spend money to make bug triaging better, then there is a lot of room for improvement in our BTS. At least it was our BTS that made things the most painful when I dealt with bugs, and I had to develop many tools, many url-crafters, many scripts to extract the very information that I would have had in the first place. Not to mention the absolutely horrible delays in the time the BTS needs to deal with mails to control@ (but I know this improved a lot recently thanks to the new host, dunno for how long though). but please, I'm not sure there is a damn single maintainer in a big team that will refuse help, paid or not. I don't really understand how that mythical maintainer in a big team that refuses help has emerged in the discussions, but I'd really like names here. In fact, that seems pretty contradictory with the very notion of a team. Of course, there is teams with 1 single member in it in debian, but that's not a large team and is out of the scope if I'm not mistaken. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoNrC6sLxAp.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: On maintainers not responding to bugs
#include hallo.h * Josselin Mouette [Wed, Feb 28 2007, 09:08:42AM]: Le mercredi 28 février 2007 à 02:02 +0100, Eduard Bloch a écrit : #include hallo.h * Josselin Mouette [Tue, Feb 27 2007, 10:30:39AM]: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. Who is not acknowledging such obvious things? Dunno. I think you confused the subthreads when replying here. As usual somebody needs to make the hands dirty and deal with the old odd bug reports. And yes, I know that my talk here does not help but I have no time to help either so I am stopping here. I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Don't put words into my mouth. Eduard. -- Rhonda maxx: Testing hat den Anspruch, jederzeit im Release-Fertigen Zustand zu sein. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Mike Hommey [Wed, Feb 28 2007, 07:52:44PM]: On Wed, Feb 28, 2007 at 07:26:24PM +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit : On Wed, Feb 28, 2007, Eduard Bloch wrote: But it seems like you maintain only few simple packages. Did you really just say that to Loïc Minier? Well. Double looking on how Loïc, Josselin and me are related to each other I guess I see the problem. The problem is: knowledge is result of perception. You both are in the same team, you see the activity of each other much more than outsiders, especially people like me who don't come in touch with Gnome packaging regularly. And I think more should try to imagine the perspective of other people sometimes before joining a flame war. But I am not a prima donna either. Hey, that's true. He maintains many complicated packages, but only few simple ones. I guess Eduard looked at http://qa.debian.org/developer.php?login=lool which implies he maintains only few simple packages and sponsor a lot, rather than http://qa.debian.org/[EMAIL PROTECTED] You got it. Eduard. -- Frisch erhält sich nur eine Liebe, der auch ein bißchen Kühle beigemischt ist. -- Michèle Morgan (eig. Simone Roussel) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Thursday 01 March 2007, Josselin Mouette wrote: Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. flaw in your logic: the quoted part does not say maintainers have enough manpower, it only says that they haven't expressed the need for more manpower,or at least not in a forum followed by the potential helper. -- Cheers, cobaco (aka Bart Cornelis) pgpQBodoPlXwM.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thu, 2007-03-01 at 14:46 +0100, Josselin Mouette wrote: Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. Lets all start the Pile-On Joss thing again and watch him explode. Hi Joss! How are you doing? Hope you are well! -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup
Re: On maintainers not responding to bugs
On Thu, Mar 01, 2007 at 03:20:24PM +0100, cobaco (aka Bart Cornelis) wrote: On Thursday 01 March 2007, Josselin Mouette wrote: Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. flaw in your logic: the quoted part does not say maintainers have enough manpower, it only says that they haven't expressed the need for more manpower,or at least not in a forum followed by the potential helper. No it says that they refuse to acknowledge they need help, which they did many times. Maybe my english is flawed, but to not admit sth implicates active denial in my understanding. As a member of such teams, and co-issuer of help requests statements on user lists (debian-kde@) I did felt quite itched by Eduard statement. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnWteLu66vy.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Le jeudi 01 mars 2007 à 09:22 -0500, Greg Folkert a écrit : Lets all start the Pile-On Joss thing again and watch him explode. Still talking to yourself? Hi Joss! How are you doing? Hope you are well! Fine, I like clowns so much. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: On maintainers not responding to bugs
On Thursday 01 March 2007, Pierre Habouzit wrote: On Thu, Mar 01, 2007 at 03:20:24PM +0100, cobaco (aka Bart Cornelis) wrote: On Thursday 01 March 2007, Josselin Mouette wrote: Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. flaw in your logic: the quoted part does not say maintainers have enough manpower, it only says that they haven't expressed the need for more manpower,or at least not in a forum followed by the potential helper. No it says that they refuse to acknowledge they need help, which they did many times. Maybe my english is flawed, but to not admit sth implicates active denial in my understanding. From gcide: Admit \Ad*mit\, v. t. [imp. p. p. Admitted; p. pr. vb. n. Admitting.] [OE. amitten, L. admittere, admissum; ad + mittere to send: cf. F. admettre, OF. admettre, OF. ametre. See Missile.] 4. To concede as true; to acknowledge or assent to, as an allegation which it is impossible to deny; to own or confess; as, the argument or fact is admitted; he admitted his guilt. [1913 Webster] or in other words an admission is an explissive confirmation of a fact. Not giving explissive confirmation (that he knows of) does not imply denial. (it helps if you think of the word in a non-courtroom setting; e.g. a reporter asks if it's true that X, if you reply 'no comment' you've not admitted X is true, but neither have you said X is false) As a member of such teams, and co-issuer of help requests statements on user lists (debian-kde@) I did felt quite itched by Eduard statement. I can see how if you read it that way... being an optimist, I choose to always interpret statements in the non-offensive interpretation even when that interpretation is non-obvious. That way I both don't feel offended, and I avoid unnecessary bad feelings when no offense was intended. On the other hand I find that when offense was intended, taking the positive interpretation, really annoys those trying to offend (and doing so without me having to descend to flaming back :) -- Cheers, cobaco (aka Bart Cornelis) pgpXtt2ZYOiot.pgp Description: PGP signature
Re: On maintainers not responding to bugs
#include hallo.h * Josselin Mouette [Thu, Mar 01 2007, 02:46:02PM]: Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : I'm not the one who said maintainers don't admit they need help. And I am not the one who said that Mozilla/KDE/GNOME have enough manpower. Who said that? Somebody in another subthread maybe. I don't care. It is not in Message-ID: [EMAIL PROTECTED] or in the other mails in that subthread, looking at References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Pine.LNX.4. [EMAIL PROTECTED] [EMAIL PROTECTED]. OTOH you answered to my message pretending that I have said that crap. Maybe you refered to some of those stories and just picked my mail to answer while being inspired by other rants. Whatever. It's your problem if you cannot follow the discussion flow, not mine. Don't put words into my mouth. How about these words: And how do you help a maintainer that does not admit that he needs help? Are they yours, or not? If not, you should consider signing your emails, as someone is trying to fake you on mailing lists. Would you please copy the quoted part to restore the context and then try to judge without emotions? Please. This part refers to the cases where maintainers actually _refuses_ help and not the cases where help is appreciated. Eduard. -- Alfie *prust* Alfie #, fuzzy Alfie msgid Failed Alfie msgstr Weiblich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Le mercredi 28 février 2007 à 02:02 +0100, Eduard Bloch a écrit : #include hallo.h * Josselin Mouette [Tue, Feb 27 2007, 10:30:39AM]: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. Who is not acknowledging such obvious things? Dunno. I think you confused the subthreads when replying here. As usual somebody needs to make the hands dirty and deal with the old odd bug reports. And yes, I know that my talk here does not help but I have no time to help either so I am stopping here. I'm not the one who said maintainers don't admit they need help. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 09:51:13PM -0500, Joey Hess wrote: maintainers not always responsing to bugs, then probably the simplest thing to do would be to code up a view in the BTS that lists bugs that have not had a maintainer response (filtering out responses that appear to be from the bug submitter, or filtering out all responses not from a given email, or something reasonable). If I had an easy[1] way to see More generally, I would say a view in which the bugs are sorted in reverse order of last activity; with activity defined either as received mail from anyone or mail from the maintainer(s). I have no clue about the code of the web interface of the bts, but I can try to mock-up a sorting criterion to be integrated in the bts devscript. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 03:41:57PM -0700, Warren Turkal wrote: This is from the perspective of a non-DD systems administrator. While most maintainers are good. Some are pretty lousy with regard to addressing issue even when one is proactive about finding a solution. On Monday 26 February 2007 14:55, Don Armstrong wrote: I don't believe any maintainer of packages, given enough hours in the day, would fail to respond to reasonable bug reports. I don't agree with this statement. I have dealt with some maintainers that refuse to acknowledge a bug when I report it. At the worst, the maintainer makes some wild assumption and code dumps a new revision of their package. That action causes me to have to totally work around their packages to make things work. The aoetools package is a fine example of this phenomenon. I have to completely override what that package does with it's init script to get my aoe devices working. [1] is a good example of a maintainer refusing to acknowledge any level of my trying to help find a solution for a bug. In all fairness, you didn't seem to comment on his response to your suggestion. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552;msg=30;att=0). This seems to be more of a case of not liking his solution than having a legitimate grievance? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Loïc Minier [Tue, Feb 27 2007, 06:51:05PM]: On Tue, Feb 27, 2007, Eduard Bloch wrote: I already warned you about this privately in december; here's another Warn? You feel the need to warn me? Does bringing me to STFU make you happy or so? No; I warned you not to put everybody in the same bag in the same pointless discussion that was happening back then about maintainer not applying patches timely. The proposals you made in this thread do not match the attitude you follow yourself... put everybody into the same bag? Jeez, what else are you interpreting into it? Nice game. Pointless attempt to create a who wants to throw the first stone situation. Looking at your dirty clothes: 401095 359033 371694 372127 372611 373277 375904 403194 What about them? Now don't tell me It is okay the package was adopted from other bad maintainer. I adopted some bug hives too. You could _at least_ search for good examples. First, most of the bugs That is what BTS reported on a quick request. But it seems like you maintain only few simple packages. As you can imagine it is hard to look for optimal examples there. your took are from Galeon which is RFAed /and/ obsolete; second, these bugs do not have patches; third, I AM NOT THE ONE WHO ARGUES THAT MAINTAINERS SHOULD RESPOND TO ALL BUGS, remember: it's you. Yeah. Keep constructing bogus arguments. You're the guy who's been complaining about the maintainer is doing uploads but only for bugs that have RC priority or important and proposed the solution shall be setting some RC priority to all bugs then. Oh boy. Now I see what you are on. Please tune your irony detector and guess why I added a comment after the last statement. Back in december, you were also pestering about maintainers that prefer to let such bug reports rot instead of tagging them, and back then I already sent you another list of bug reports to which you did not bother replying to for MONTHS, even bugs _I_ filed, _with patches_. And the worse is that you are upstream for most of the bugs I quoted. That is worse? Have you ever considered that I get more bug reports because I am upstream and the Debian BTS catches both, upstream and Debian related problems? Apparently not. You prefer to play with simple packages and only packagement problems where you can come and close lots of bugs with simple changes. At least this is my impression looking at the attitude shining through. So, yes, please, SFTU; your position is so naive that it is pointless; instead of complaining about what busy maintainers could do, do it yourself, or find more people to do it. Instead of reading your bitching about Debian bug handling, I spent some hours yesterday backporting the 10 bugs with the most duplicate reports from GNOME upstream (check: http://lists.debian.org/debian-devel-changes/2007/02/threads.html), I bet this was at least 1200% more useful than your arguing. 1200%? ROTFL. Yes, master, now you are my hero after making 10 trivial fixes. Eduard. -- Y_Plentyn hmhm... hier ist bestimmt niemand, dem die begriffe RED und ns im kontext netzwerke was sagen, oder? Gem`Xevy Y_Plentyn: rot kennt jeder, und ueber NS redet man nicht mehr... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tue, 27 Feb 2007 08:10:08 +0100, Mike Hommey wrote: The other half of the problem that noone has talked about here yet, is that the users are as responsive as the maintainers, i.e. pretty badly. Why do we have rotting unclosed bugs concerning old fixed issues ? Why don't most users just send in a message to say if the bug they reported is gone with a new upstream version ? Because they either don't care or moved along. Not necessarily because the maintainers didn't answer, because it happens even when we do. I'd say that frequently the reason is simple ignorance on the part of the user: i.e. they don't know how to send in an update or they don't know that one would be welcome. IMO, it would be perfectly appropriate in these cases to ping the user and, if no reply is forthcoming, to close the bug. And not only when bug are fixed don't we get feedback. We sometimes also face non-responsiveness to our requests for more precisions on the bug... I think in these cases it's also often appropriate to close the bug. Reid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wed, Feb 28, 2007, Eduard Bloch wrote: But it seems like you maintain only few simple packages. Did you really just say that to Loïc Minier? Amazed, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit : On Wed, Feb 28, 2007, Eduard Bloch wrote: But it seems like you maintain only few simple packages. Did you really just say that to Loïc Minier? Hey, that's true. He maintains many complicated packages, but only few simple ones. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: On maintainers not responding to bugs
On Wed, Feb 28, 2007 at 07:26:24PM +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit : On Wed, Feb 28, 2007, Eduard Bloch wrote: But it seems like you maintain only few simple packages. Did you really just say that to Loïc Minier? Hey, that's true. He maintains many complicated packages, but only few simple ones. I guess Eduard looked at http://qa.debian.org/developer.php?login=lool which implies he maintains only few simple packages and sponsor a lot, rather than http://qa.debian.org/[EMAIL PROTECTED] Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wednesday 28 February 2007 01:19, Hamish Moffatt wrote: In all fairness, you didn't seem to comment on his response to your suggestion. I did comment on his suggestion. Yes, it should start before NFS because its not just mounting a file system like NFS. It needs to make the block devices available. Not to mention there was a thread on debian-devel at the time where I thought he was MIA because he was so unresponsive. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552;msg=30;att=0). This seems to be more of a case of not liking his solution than having a legitimate grievance? The solution flat out does not work. I mean, as his scripts are written, the machine hangs on shutdown. Here's the basic happenings of that bug. Sept. 14 - I send initial bug report. Oct. 2 - After 3.5 weeks the maintainer releases a new package, claiming it fixed the bug. I then attempt to point out that the script is not working. Oct. 3 - I attach my implementation of the init script that at least lets the filesystems mount. Oct. 9 - I try to get the maintainer to do something about letting it propagate to testing as I think the fix is not a fix. I do not escalate the bug myself because I am not the maintainer. Oct. 12 - The maintainer replies only because a thread on debian-devel[1] calls into question his ability to maintain the package. I then respond with a comment on the only thing relevant in the email (the order of start scripts and how AOE is different from NFS). I provide a link to Coraid's (the implementer of aoe in the kernel) documentation about setting up this hardware. Nov. 8 - I document why the new revision of the package doesn't work even for the mounting case, and I document that udev may be the right way to completely avoid the race condition. I'd like to point out that the above occurred over about a two month period. One response from the maintainer that was prompted by pinging debian-devel is ridiculous. As you can see there is only one human response in there, and I did respond to the critical question of his email. He seems to only respond when things get emotionally charged or when I publically tried to see if some other developer could comment on my changes. The maintainer's behavior made him very discouraging to work with. I just stopped dealing with him after a while. It hasn't stopped me from filing other bug reports. You may think I'm a whiner, but the fact of the matter is that my hardware flat out does not work with his scripts, and he was unresponsive to my suggestions for fixing them. He didn't even want to consider the use case that someone might want to treat a block device like a block device instead of a filesystem container. If you don't want to consider it non-responsive, it was at least really unproductive and frustrating. [1]http://lists.debian.org/debian-devel/2006/10/msg00451.html wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On 2007-02-27, Joey Hess [EMAIL PROTECTED] wrote: maintainers not always responsing to bugs, then probably the simplest thing to do would be to code up a view in the BTS that lists bugs that have not had a maintainer response (filtering out responses that appear to be from the bug submitter, or filtering out all responses not from a given email, or something reasonable). If I had an easy[1] way to see that in my open bugs, I would be more inclined to prioritise that first when doing my periodic reviews of all my open bugs. It is not a view, but it might be able to help a bit: http://www.enricozini.org//2007/tips/bts-utils.html /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Don Armstrong [Mon, Feb 26 2007, 01:55:42PM]: On Mon, 26 Feb 2007, Andreas Tille wrote: A maintainer who refuses to respond to a reasonable bug report of a user does not deserve any user. It's not a case of maintainers refusing to respond, it's a case of some maintainers of some packagages drowning in bugs and not being able to respond to all of them. [I don't believe any maintainer of packages, given enough hours in the day, would fail to respond to reasonable bug reports.] Or they do not respond in time and forget about those bug reports even later when they have time. Closing the eyes is soo easy. I'm open to suggestions of real solutions to this problem, (indeed, I continue to suggest that interested people jump in and help out) but technical hurdles for maintainers to overcome and waste their limited time in trivialities are pointless, and not something I'm willing to support. And how do you help a maintainer that does not admit that he needs help? I would support a semi-automated solution: BTS tracks an eta2fix value which maintainer can set telling the planed schedule for fixing this bug in the near future. Not setting ETAs indicates that the maintainer is MIA/lazy/ignorant. Missing the own ETAs may indicate that maintainer needs help and this can be make public automaticaly in a common place. I think this solution should quickly unveil those ignorant kings of my package and help people find the best place where they can help. And please don't tell me this is a technical curdle since this would be crap. Every time you use a keyboard instead of speaking freely you have to jump over hurdles. Eduard. -- LGS Halloechen, ihr Spinner, so frueh auf? nusse nein, wir schlafen alle im kollektiv knorke mein alkoven ist kaputt teq alkohol kaputt? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Ben Finney wrote: Ben Finney [EMAIL PROTECTED] writes: cobaco (aka Bart Cornelis) [EMAIL PROTECTED] writes: - an indication the effort of submitting a bug report is apreciated - an indication the effort will _not_ be ignored in the long run - an indication that actual fixing of the bug will take a while I think this is significantly more than the OP was proposing. I also think that it's unreasonable to expect that *every* bug, no matter the severity, should receive this treatment before allowing a new version to migrate to testing. That should read ... unreasonable to expect that *every* bug, regardless what severity threshold is chosen, ... I'm not asking that such a message be sent to every bug, what I'm asking is that: IF you're not going to do anything with a bug for a long period that you send a message to that effect. Note that this basically consists of: 1) gather the list of bugs that are unanswered 2) send 1 short message to that list of bugs In other words 1 mail every week (or 2 weeks) or so. I really don't think that's an unreasonable think to ask (and 1 could possibly be automated by BTS) -- Cheers, cobaco (aka Bart Cornelis) pgpA3LRewQqGe.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: SO rather than sending excuses-templates, when I've had time to check the bug is actually there, I do use the confirmed tag to: * ack this is an actual bug ; * ack that I've been able to reproduce it (hence implying that I've read the report) ; * remember that I already read that report. For my part, this use of the 'confirmed' tag, which (I believe) gets sent back to the submitter, is ample feedback that the bug has been triaged by a real human. I agree completely here, if visible action has been taken there's no need for an ack mail -- Cheers, cobaco (aka Bart Cornelis) pgpIST5DS9QYe.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. So let's rephrase that: how does a bug submitter the maintainer needs help if that hasn't been communicated in a forum the submitter follows? YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? People heavily involved with Debian know such things, bug submitters that aren't involved (yet) most likely don't. - asking them to either pitch in or be patient seems a completely sensible thing to do, it decreases frustration, and for some percentage of submitters it will be the last little push they need to start getting involved And as I noted elsewhere in this thread this only needs you to a) keep track of which bug reports aren't being handled (presumably you already have those bugs somewhere low on your todo list, right?) and b) compose 1 mail to that list of bug repports every couple of weeks or so. -- Cheers, cobaco (aka Bart Cornelis) pgpHwZm6eX7UI.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tue, Feb 27, 2007 at 11:04:47AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 27 February 2007, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? WTF ?! YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? People heavily involved with Debian know such things, bug submitters that aren't involved (yet) most likely don't. - asking them to either pitch in or be patient seems a completely sensible thing to do, it decreases frustration, and for some percentage of submitters it will be the last little push they need to start getting involved Ooooh you mean telling all the user base we need help and are overwhelmed like in [0] or [1] ? [0] http://lists.debian.org/debian-kde/2006/01/msg00215.html [1] http://lists.debian.org/debian-gtk-gnome/2006/01/msg00037.html We've seen how good it was for us, at least in the KDE team we got about ... errr... 0 help offers. Could one stop thinking teams packaging large things are as uncommunicative as some core teams in debian ? Actually we do speak our problems out. It's just followed up with a huge silence. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpsA6E3KlbwU.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Pierre Habouzit wrote: On Tue, Feb 27, 2007 at 11:04:47AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 27 February 2007, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : Who is not acknowledging such obvious things? People heavily involved with Debian know such things, bug submitters that aren't involved (yet) most likely don't. - asking them to either pitch in or be patient seems a completely sensible thing to do, it decreases frustration, and for some percentage of submitters it will be the last little push they need to start getting involved Ooooh you mean telling all the user base we need help and are overwhelmed like in [0] or [1] ? [0] http://lists.debian.org/debian-kde/2006/01/msg00215.html [1] http://lists.debian.org/debian-gtk-gnome/2006/01/msg00037.html Nope: not every bug submitter reads debian-kde or debian-gtk-gnome, or whatever list is most current for the package in question (in fact i'd say it's more likely that most do not). But let me point out something you seem to have missed (or lost sight of): people are more likely to help you fix a problem if they are directly affected by it (cause people tend to scratch their own itches). - instead of asking for help on a mailinglist with no direct relation to BTS, it would make more sense to ask bug submitters suffering the effect of the maintainer not having enough time to do sufficient bug triage for either help or patience. We've seen how good it was for us, at least in the KDE team we got about ... errr... 0 help offers. you send a mail for help - good you didn't get any help - bad but keeping in mind the above, you might want to retarget the request for help? Could one stop thinking teams packaging large things are as uncommunicative as some core teams in debian ? Nothing in this thread has said that. The only point this thread makes regarding large packages/package sets is that large things get more bugs reported, making it harder to keep up, and they also tend to suffer from lots of antiquated bugs from the pre-team erra Note that's 2 sepperate problems: 1) timely response to new bugs 2) cleanup of antiquated bugs In the case of the KDE team it has in fact been pointed out in this threead that the main problem is 2) and that 1) hasnt't been a problem since the introduction of bts-link. Since this whole discussion is about handling problem 1), it would seem that this discussion isn't pointed at KDE at all ATM, so I'm not sure why you're feeling attacked (or at you least you give that impression). So let me make it explicit: we're not looking to point fingers, we're looking for ways to: a) adress a recurring problem b) get a handle on what the size of the problem is -- Cheers, cobaco (aka Bart Cornelis) pgpa7PMRwoezJ.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tue, Feb 27, 2007 at 01:37:56PM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 27 February 2007, Pierre Habouzit wrote: On Tue, Feb 27, 2007 at 11:04:47AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 27 February 2007, Josselin Mouette wrote: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : Who is not acknowledging such obvious things? People heavily involved with Debian know such things, bug submitters that aren't involved (yet) most likely don't. - asking them to either pitch in or be patient seems a completely sensible thing to do, it decreases frustration, and for some percentage of submitters it will be the last little push they need to start getting involved Ooooh you mean telling all the user base we need help and are overwhelmed like in [0] or [1] ? [0] http://lists.debian.org/debian-kde/2006/01/msg00215.html [1] http://lists.debian.org/debian-gtk-gnome/2006/01/msg00037.html Nope: not every bug submitter reads debian-kde or debian-gtk-gnome, or whatever list is most current for the package in question (in fact i'd say it's more likely that most do not). But let me point out something you seem to have missed (or lost sight of): people are more likely to help you fix a problem if they are directly affected by it (cause people tend to scratch their own itches). That's the theory. My experience for KDE bugs, is that something like 60 to 75% of the bug submitters do not answer to more-info requests, or precisions requests. It's true even if you answer in the couple of weeks after the submission. I shall say for the sth like 20 bugs I've dealt with in the libc, I've had the great surprise to see people answer to bugs, even some 6-years old ones. My opinion on this matter is that _users_ (to be opposed to developers) don't really care, it's fire and forget reporting. Whereas developers do really care about the bug being fixed the right way, and do answer. And libc bug reporters are often developers. Sadly, if we may be able to fix _our_ social/technical/... issues, we're not going to fix our users any time soon. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp3541teK4cg.pgp Description: PGP signature
Re: On maintainers not responding to bugs
Ben Finney [EMAIL PROTECTED] writes: If I receive automatic notification from the BTS that the maintainer has attached a confirmed tag to the bug, that is plenty of acknowledgement. or pending, upstream, wontfix, help or change in severity. Any of those actions indicates that someone is dealing with the bug. And the submitter (or anyone) can look that up in the BTS. But, a notification email to the submitter might be a good idea. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
* Joey Hess [EMAIL PROTECTED] [2007-02-26 21:51:13 -0500]: If someone would actually like to do something about the problem of maintainers not always responsing to bugs, then probably the simplest thing to do would be to code up a view in the BTS that lists bugs that have not had a maintainer response (filtering out responses that appear to be from the bug submitter, or filtering out all responses not from a given email, or something reasonable). If I had an easy[1] way to see that in my open bugs, I would be more inclined to prioritise that first when doing my periodic reviews of all my open bugs. -- see shy jo [1] It can be done now with usertags, but hardly easily. Not to mention that such a view could be very helpful to any DD who has a few minutes for bug triage and would be more productive if he didn't have to trawl through all bugs looking for stuff to follow up on. I know it would be very helpful to me. Cheers, Alex. signature.asc Description: Digital signature
Re: On maintainers not responding to bugs
On Tue, Feb 27, 2007, Eduard Bloch wrote: I already warned you about this privately in december; here's another Warn? You feel the need to warn me? Does bringing me to STFU make you happy or so? No; I warned you not to put everybody in the same bag in the same pointless discussion that was happening back then about maintainer not applying patches timely. The proposals you made in this thread do not match the attitude you follow yourself... Nice game. Pointless attempt to create a who wants to throw the first stone situation. Looking at your dirty clothes: 401095 359033 371694 372127 372611 373277 375904 403194 What about them? Now don't tell me It is okay the package was adopted from other bad maintainer. I adopted some bug hives too. You could _at least_ search for good examples. First, most of the bugs your took are from Galeon which is RFAed /and/ obsolete; second, these bugs do not have patches; third, I AM NOT THE ONE WHO ARGUES THAT MAINTAINERS SHOULD RESPOND TO ALL BUGS, remember: it's you. You're the guy who's been complaining about the maintainer is doing uploads but only for bugs that have RC priority or important and proposed the solution shall be setting some RC priority to all bugs then. Back in december, you were also pestering about maintainers that prefer to let such bug reports rot instead of tagging them, and back then I already sent you another list of bug reports to which you did not bother replying to for MONTHS, even bugs _I_ filed, _with patches_. And the worse is that you are upstream for most of the bugs I quoted. So, yes, please, SFTU; your position is so naive that it is pointless; instead of complaining about what busy maintainers could do, do it yourself, or find more people to do it. Instead of reading your bitching about Debian bug handling, I spent some hours yesterday backporting the 10 bugs with the most duplicate reports from GNOME upstream (check: http://lists.debian.org/debian-devel-changes/2007/02/threads.html), I bet this was at least 1200% more useful than your arguing. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Loïc Minier [Mon, Feb 26 2007, 01:32:50PM]: On Mon, Feb 26, 2007, Eduard Bloch wrote: A good example already comes to my mind where the maintainer is doing uploads but only for bugs that have RC priority or important and are easy to fix. Not matching this criteria? Then you are simply ignored. No answer. Not one single word from the maintainer over many months even while people are providing patches to fix it. I already warned you about this privately in december; here's another Warn? You feel the need to warn me? Does bringing me to STFU make you happy or so? slap (all bugs with patches in packages you maintain): #402483: 77 days, no reply #402521: tentative upload, but missed the patch, 49 days without action #408718: 29 days, no reply #362994: 315 days, no reply #287154: 2 years and 63 days, no reply Nice game. Pointless attempt to create a who wants to throw the first stone situation. Looking at your dirty clothes: 401095 359033 371694 372127 372611 373277 375904 403194 What about them? Now don't tell me It is okay the package was adopted from other bad maintainer. I adopted some bug hives too. I've lost enough time I could use in better ways by compiling these 5 If you need that much time to find extreme cases for all the packages I maintain then I think the percentage is quite low. reports, I do hope they'll bring your position back to a more reasonable definition of what is acceptable and what is not. You need to make an example on myself to create some definition? Sounds like a lame excuse for a childish contest. If you don't like to hear that then I am sorry but you started it. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Pierre Habouzit [EMAIL PROTECTED] writes: cobaco (aka Bart Cornelis) wrote: people are more likely to help you fix a problem if they are directly affected by it (cause people tend to scratch their own itches). That's the theory. My experience for KDE bugs, is that something like 60 to 75% of the bug submitters do not answer to more-info requests, or precisions requests. It's true even if you answer in the couple of weeks after the submission. So, in your experience, 25% to 40% of bug submitters *do* answer more-info requests? That seems quite a good response rate to me. You present this in response to people are more likely to help you fix a problem if they are directly affected by it. Are you suggesting that people who are *not* directly affected by a bug are 25% to 40% likely to answer a more-info request? My opinion on this matter is that _users_ (to be opposed to developers) don't really care, it's fire and forget reporting. Anecdotally, I'd agree that many bug submitters fit this profile. So we should increase the likelihood that people who *do* care can know that they are doing the right thing by submitting quality bug reports, even if the fix is a long time in coming. -- \ [...] a Microsoft Certified System Engineer is to information | `\ technology as a McDonalds Certified Food Specialist is to the | _o__)culinary arts. -- Michael Bacarella | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
OoO En cette nuit nuageuse du mardi 27 février 2007, vers 01:04, Russ Allbery [EMAIL PROTECTED] disait: Maintaining packages should be fun and rewarding too. Punishing people for not doing something that we think is important has its place, but only sparingly. Reporting bug should be fun too. Not getting an answer is not very polite and some users may feel that their bug reports are useless. -- Take care to branch the right way on equality. - The Elements of Programming Style (Kernighan Plauger) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Vincent Bernat [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] disait: Maintaining packages should be fun and rewarding too. Punishing people for not doing something that we think is important has its place, but only sparingly. Reporting bug should be fun too. Not getting an answer is not very polite and some users may feel that their bug reports are useless. Sure, which is why I'm all in favor of responding where possible. I just don't want to see us let the best become the enemy of the good or hold maintainers to standards that work fine for small packages but which don't scale to huge ones. Upstream projects frequently have unanswered bugs. This is a problem with all large free software products I've ever been involved with. I'm all for trying to do the right thing, but let's not burn ourselves out or turn on each other over unrealistic standards. If the entire rest of the free software community is struggling with something, we're probably not going to have a silver bullet that's going to make it easy for us, and we should probably be realistic about what we can accomplish. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Josselin Mouette [Tue, Feb 27 2007, 10:30:39AM]: Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : And how do you help a maintainer that does not admit that he needs help? I can't believe people are thinking such crap. Please show me where a current maintainer of Mozilla, KDE, GNOME, the glibc, the kernel, X.org or any such big group of packages said he didn't need help for them. YES. WE NEED HELP. NOW. We are *all* *COMPLETELY UNDERSTAFFED*. We are drowning in bug reports and are not able to answer all of them, especially old ones dating from the pre-teams era. Who is not acknowledging such obvious things? Dunno. I think you confused the subthreads when replying here. As usual somebody needs to make the hands dirty and deal with the old odd bug reports. And yes, I know that my talk here does not help but I have no time to help either so I am stopping here. Eduard. -- HE Myon: Einigkeit und Recht und Allohol! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Tue, 27 Feb 2007, Eduard Bloch wrote: #include hallo.h * Don Armstrong [Mon, Feb 26 2007, 01:55:42PM]: I'm open to suggestions of real solutions to this problem, (indeed, I continue to suggest that interested people jump in and help out) but technical hurdles for maintainers to overcome and waste their limited time in trivialities are pointless, and not something I'm willing to support. And how do you help a maintainer that does not admit that he needs help? You put them on Jerry Springer and arrange an intervention? I would support a semi-automated solution: BTS tracks an eta2fix value which maintainer can set telling the planed schedule for fixing this bug in the near future. This solution is already trivially implementable using usertags. If people begin to tag their packages using things like eta2fix-rsn eta2fix-weeks eta2fix-months eta2fix-snowinhell then I'll consider adding a feature to the BTS to output the time remaining to the ETA. [Indeed, this is my (personal) metric[1] for adding all new tags and tag-like features; show me you'd use it using user tags, and I'll implement it.] And please don't tell me this is a technical curdle since this would be crap. Yes, it's a technical curdle of crap. I'm going to use it to make fecal cheese. Don Armstrong 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237140;msg=12 -- Of course, there are cases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_ http://www.donarmstrong.com http://rzlab.ucr.edu
Re: On maintainers not responding to bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/07 01:27, Don Armstrong wrote: On Mon, 26 Feb 2007, Ben Finney wrote: Sune Vuorela [EMAIL PROTECTED] writes: [snip] [Frankly, if you're concerned about whether someone has seen your mail, surely the ack from the BTS is sufficent. Anything else requires someone to actually do the work.] Does the BTS ack *mean* that an actual living breathing human has eyeballed the bug? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF4pVaS9HxQb37XmcRAlG+AJ9F1lotvLUaKEF26YxcCRwk4xEuqACg6MEH 8bu08b5YXspjLmOZMSlT+TU= =aU07 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, Am Mo den 26. Feb 2007 um 3:03 schrieb Pierre Habouzit: errrm, let me think. YES ! [some calculation] so well, hmm let me think again ... YES THIS IS A DAMN PERFECT ARGUMENT. Sorry, but NO. It only shows that there is more people needed for maintaining the package! Moreover, responding for a bugreport can end in less time needed to fix the bug. Maybe the reporter has still a (local) solution and did not append it as patch. Simply asking would help to get this patch. Maybe a response can also be like do you have some experience? Can you help out fixing the bug? I'm sure that there are some bug reporter out there who are able to fix bugs and would answer positive to such questions. But if there is no response to a bug report nobody is engaged to spend only a minute to fix it. Regards Klaus Ps. Syntax bugs in this message have to be ignored. - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBReKgwJ+OKpjRpO3lAQI1Ewf+JN26Q7Nieot+gvUyNf5TgWOS2EI6OGsA BpTejPiwYPpNClKIQUr3jXpBlAejyR1865ps0qY8hl0TIeNbPjraiMR11AUbD+qv bO4k1O2Sv9KXR3GDU979nMKsBlvoICa092kH8gJkaFwWWtSyXLAXR61UsRGbq1zH V61uyewN75uOuUYpJn65XlkFqMlnvXlp/KekgIcoqTyBl4pQobWxaaV6rwVZuwSE NwhBwxpb2wRRA3xofZCv6alXgxprjqg5HhnRhJwUezMhdsnx0n8MTlDZY0vUMQaq kQu3TUfn501mScQLZJXVYOdBDtINHdoo2E5gmT/kApfaIPAmxl9B1g== =nKRX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
* Marco d'Itri [EMAIL PROTECTED] [070226 02:35]: If a maintainer keeps doing uploads we can be almost sure that he is not ignoring bugs too. Especially with the big packages used as example why this would be hard this is not obvious, and I think for many packages it is even simply not true. Providing an useful answer to a bug requires proper bug triage, which requires time. But it is a time that is well invested. If a maintainer does not look at the bugs, he cannot give them due priority. Thus a maintainer needs to look at them anyhow and do a fast assessment how important it is, how much work it would involve to fix it or even what kind of tests or considerations would be needed to make sure it is a bug at all. And if it is done, a short answer can be made with the results of that. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sun, Feb 25, 2007 at 10:32:41PM -0500, Roberto C. Sanchez wrote: On Mon, Feb 26, 2007 at 02:55:39AM +0100, Pierre Habouzit wrote: And btw, help for bug triaging for any of those kind of packages is vastly appreciated... But here is a newsflash: 100 bugs is fairly easy to reduce. the 5 or 600 bugs the KDE team has closed was a year of work. Yes a damn year, during which there has been many upstream releases (getting a release ready is a week of work, plus the RC that always come with them, so you can add another week on top of this one). So please explain me how a team that has had sometimes less of 2 to 3 _actually active_ members at a given time do manage to keep up with bugs as well ? I'll tell you: they just don't. Sorry to seem pissed, but well, I am. Your mail (and others with the same thoughts) are completely disconnected from reality. Totally. Sorry. I was arguing for the value of bug triage and communicating with submitters. I still on't think that holding up migration over unanswered bugs is a good idea. Hope that clears things up for you. The Debian would have KDE 3.1 (as we couldn't make it with KDE 3.5.5) and that would be a nightmare as it's now unsupported upstream. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpE3zNLbg01E.pgp Description: PGP signature
Re: On maintainers not responding to bugs
* Pierre Habouzit [EMAIL PROTECTED] [070226 03:03]: So now let's do a simple calculation. 100 bugs, 20 minutes, that's 2000 minutes, over 6 weeks, that's 333 minutes a week, meaning at least 6 hours a half of work. Just to keep up with bugs. Of completely tedious work. Add to that: working on the backlog, working on the bugs that in fact need 1hour of work, packaging new upstreams, doing some maintenance on the repository and so on, and KABOOOM, either you have a time machine, or there is not enough time. so well, hmm let me think again ... YES THIS IS A DAMN PERFECT ARGUMENT. Sorry to say it that way. But after I read this, not letting such packages in a stable release before they get enough manpower to be handled, sound a better idea then before. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
* Ron Johnson: Does the BTS ack *mean* that an actual living breathing human has eyeballed the bug? No, it doesn't. But would an ack from a human being mean that the bug will be fixed in due course? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
* Nikita V. Youshchenko: What do people look on the following idea: not allow packages to migrate from sid to testing if they have unanswered bug reports with severity = normal? I don't think fiddling with testing propagation in this way is a good idea. After all, even if the package has got unacknowledged bug reports, propagating the version to testing might actually decrease the overall bug count. And if you really think that this information is helpful to system administrators, you could create an APT plugin that warns before installing such packages (perhaps even a patch to apt-listbugs would do it). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sun, Feb 25, 2007, Steinar H. Gunderson wrote: On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote: What do people look on the following idea: not allow packages to migrate from sid to testing if they have unanswered bug reports with severity = normal? Honestly, this would kill almost any larger package. You sound like it would not make the maintainers care more about their bugs and start answering them. The problem is that way too often, maintainers don't really care about packages migrating to testing. If they did, we wouldn't have 398 RC bugs on packages that are not in testing... I don't think this is /the/ problem. It's /another/ problem. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 05:20:31AM +0100, Ana Guerrero wrote:
On Sun, Feb 25, 2007 at 10:35:48PM -0500, Roberto C. Sanchez wrote:
OK. But is there not a fairly sizeable team working on KDE packaging
for Debian?
No. FYI, the KDE team is currently about 6 *active* members, 3 working
a lot and 3-4 working when they have some free time. Last kde 3.5.6 has been
packaged for only 3 members of the team (one of them is not even in NM).
And that's in fact a _lot_. We were quite less not so long ago.
Now let's think a bit:
- iceweasel is Eric and Mike (2 people): 528 bugs.
- XSF packages is (mostly I think) Julien and David (2 people): I'd
say more than 900 bugs (500 on xorg solely).
- OOo.org is René (_1_ active people): 459 bugs.
- Glibc is mostly done by aurel32, and I try to help (1.5 people):
~300 bugs.
And I think the list can grow larger just by looking at the reality,
and not dreaming stupid ideas and trying to defend them. KDE team has
more people, but ... there is also a _lot_ of gigantic packages to deal
with: two versions of Qt (yay libs in c++), main modules, ...
Just _look_ at that: [0]. I mean _look_, not pretend to. Instead of
answering to that thread, arrogantly explaining to us how bad we suck,
because we don't have the 30 hours a week that would be needed (per team
member) to deal with KDE packages.
And just consider you can s/KDE/{anything that is large in the project}/
[0] http://qa.debian.org/[EMAIL PROTECTED]
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpdzsQNWW4OA.pgp
Description: PGP signature
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 10:45:24AM +0100, Bernhard R. Link wrote: * Pierre Habouzit [EMAIL PROTECTED] [070226 03:03]: So now let's do a simple calculation. 100 bugs, 20 minutes, that's 2000 minutes, over 6 weeks, that's 333 minutes a week, meaning at least 6 hours a half of work. Just to keep up with bugs. Of completely tedious work. Add to that: working on the backlog, working on the bugs that in fact need 1hour of work, packaging new upstreams, doing some maintenance on the repository and so on, and KABOOOM, either you have a time machine, or there is not enough time. so well, hmm let me think again ... YES THIS IS A DAMN PERFECT ARGUMENT. Sorry to say it that way. But after I read this, not letting such packages in a stable release before they get enough manpower to be handled, sound a better idea then before. Stripping KDE, php, xorg, gnome, iceweasel, the libc out of stable would indeed make releases a lot less painful. Any other brilliant idea around ? Also consider that in the huge mass of bugs, for any of the mentioned packages, I'd say 25 to 50% of the bugs are just either invalid or long gone. Those teams do an amazing job dealing with the most urgent bugs, _AND_ keeping up with upstream. Because such packages aren't supported very long, because upstreams have the same man power issues, and they only support _some_ releases, if we do not keep up, then it means putting an unbearable pressure over the already quite loaded security team. Could we go back to sanity and reality, please ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJfr4WAWtSO.pgp Description: PGP signature
Re: On maintainers not responding to bugs
* Pierre Habouzit [EMAIL PROTECTED] [070226 11:05]: Stripping KDE, php, xorg, gnome, iceweasel, the libc out of stable would indeed make releases a lot less painful. xorg just sees activitiy to look at bugs (and it was really overdue), libc is a beast of itself. For the others I have no strong preference, and if we cannot even garantee that someone looks at the bugs, why put them in stable? Also consider that in the huge mass of bugs, for any of the mentioned packages, I'd say 25 to 50% of the bugs are just either invalid or long gone. That is even more a reason to look into them. More old invalid bugs means more time for submitters to search for their bug. Which means either more duplicates, less times for submitters to invest into bug reports making things easy. Those teams do an amazing job dealing with the most urgent bugs, _AND_ keeping up with upstream. Because such packages aren't supported very long, because upstreams have the same man power issues, and they only support _some_ releases, if we do not keep up, then it means putting an unbearable pressure over the already quite loaded security team. Hey, I was speaking about not releasing such packages at all (perhaps except libc and the kernel (at least until hurd is ready ;-)). So no problem at that front. After all, if noone reads the bug reports anway, how should one find security relevant ones? Could we go back to sanity and reality, please ? I'm also against putting a such a automatism as suggested in. (Especially as it can be easily circumvented). It's better to help than to punish. (What about forcing NMs to take a look at a dozen bugs in high-profile packages not yet answered, trying to verify them and collect some data on them?) But in all sanity, saying you cannot cope with bug-reports is no reason at all that the package should be released in its current form but only a reason against it. I'm not suggesting that should be done, but that it is the only logical conclusion from your argument. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Pierre Habouzit [Mon, Feb 26 2007, 02:32:28AM]: On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote: On Mon, Feb 26, 2007 at 11:12:43AM +1100, Ben Finney wrote: Sune Vuorela [EMAIL PROTECTED] writes: You and others are most welcome to take a stab at the 1000 open bugs against the official kdepackages. You and others cannot substitute for a response *from the package maintainer* acknowledging (or otherwise) the bug report. That's the criterion being discussed here: not a resolution for the reported bug, but rather a first response from the package maintainer to the bug report, to acknowledge that it has not been ignored. And what he's telling you, and what I'm telling you, is that it's a completely crap criterion for those of us who deal with massive packagesets like KDE. Simply replying to a bug won't get it fixed any sooner or decrease the impact it has on the user. In addition, it distracts us from doing what is potentially far more productive work. bleh, you're totally wrong ! That *is* an excellent criterium, if you need proof, look at the libc: too many unanswered bugs, it should not be in testing. End of story. They have good teachers. My last upstream report was closed after waiting for months with provide the data, issue is through, closing the bug. The fact the problem does still exist and that this feature has been working in previous versions have been just forgotten. Close the bug and/or let's pretend there is no problem. And now wonder why there are many unofficial packages, forks, et cetera. People are not happy? What a surprise. Eduard. -- LGS Halloechen, ihr Spinner, so frueh auf? nusse nein, wir schlafen alle im kollektiv knorke mein alkoven ist kaputt teq alkohol kaputt? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
#include hallo.h * Marco d'Itri [Mon, Feb 26 2007, 02:36:13AM]: On Feb 26, Ben Finney [EMAIL PROTECTED] wrote: You and others cannot substitute for a response *from the package maintainer* acknowledging (or otherwise) the bug report. That's the criterion being discussed here: not a resolution for the reported bug, but rather a first response from the package maintainer to the bug report, to acknowledge that it has not been ignored. If a maintainer keeps doing uploads we can be almost sure that he is not ignoring bugs too. Nonsense. A good example already comes to my mind where the maintainer is doing uploads but only for bugs that have RC priority or important and are easy to fix. Not matching this criteria? Then you are simply ignored. No answer. Not one single word from the maintainer over many months even while people are providing patches to fix it. The solution shall be setting some RC priority to all bugs then. Then he will need to touch the bug report at least once to downgrade the severity (in theory). Obviously not a good solution. For me, I decided to NMU sooner in the next situation like that. Why wasting time when you can improve the package and the maintainer does obviously not want to, right? Providing an useful answer to a bug requires proper bug triage, which requires time. Typing does XY's patch solve you problem so I can schedule the fix for my next upload does cost you more than 20 seconds? What about joining a fast keyboard typing course then? Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
Le lundi 26 février 2007 à 09:56 +0100, Klaus Ethgen a écrit : Sorry, but NO. It only shows that there is more people needed for maintaining the package! Yes. We need more people to maintain GNOME, KDE, X.org, the glibc, OOo, and Mozilla. Any volunteers around? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: On maintainers not responding to bugs
Le lundi 26 février 2007 à 10:57 +0100, Pierre Habouzit a écrit : Now let's think a bit: - iceweasel is Eric and Mike (2 people): 528 bugs. - XSF packages is (mostly I think) Julien and David (2 people): I'd say more than 900 bugs (500 on xorg solely). - OOo.org is René (_1_ active people): 459 bugs. - Glibc is mostly done by aurel32, and I try to help (1.5 people): ~300 bugs. GNOME is 3 active people (2 uploading, 1 doing *only* bug triage), plus 6-7 less active people, for 145 packages totalising 1618 bugs. You can add evolution and its 398 bugs for 2-3 people. We are lucky to be even able to manage this number of bugs. I have absolutely no idea of how e.g. the upstream nautilus developers can handle more than 50 bugs per *day*. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
