Re: What bug reports are for
Hi, Josselin: En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió: Le dimanche 27 février 2011 à 14:50 +0200, Dmitry Baryshev a écrit : Who should do this investigation? I did it because I know how to debug this. If user don't know how to debug this, his bug report will be closed without reassigning to proper package. Hence this investigation should be done by maintainer, not user. You seem to forget the very reason bug reports are here. Their point is not to offer a service to our users - if you want that, you’ll need paid support. Bug reports are here to help improving the distribution. Good to know. Is *that* Debian's official position? That the bug report system is not there to offer a service to Debian users? Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103011947.58328.jesus.nava...@undominio.net
Re: What bug reports are for
Hi, Russ: En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió: Jesús M. Navarro jesus.nava...@undominio.net writes: En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió: Now, maintainers receive a lot of bug reports, and have limited time to spare on Debian. Given the choice between: 1. packaging a new upstream release that fixes a lot of bugs; 2. fixing a nicely reported bug with a reproducible and well-identified cause; 3. investigating a dubious bug report that seems to be triggered by a broken user configuration; only masochistic maintainers will spend time on #3 when they can help a lot more users on #1 and #2. It’s not that it’s easier (I remember spending entire days on single bugs), but it’s more useful. True, and I don't think anybody would expect any more. But #3. is still a bug and unless it's been at least tried to be reproduced is no good behaviour to close it just because I've not the time and I prefer focusing on #1 and #2. I'm not telling this is the case for this bug since I really don't know it but as a general matter, but *if* that were the case, no, I don't think sweeping bugs under the carpet is a proper policy. Well, maybe #3 is still a bug. That's the problem, right? We don't know that. No, I don't think it is. #3 *is* a bug since the moment somebody has referred it as such. The trouble with things that fall into category #3, apart from just taking way more time to investigate, is that they may or may not actually be bugs. Frequently once one investigates, one finds that it's not a bug in any useful fashion (it's already fixed, it's caused by something on the user side against which it's not reasonable for the package to take precautions, the user's system was in some broken state, or no one can reproduce the problem and the user isn't replying). That maybe the case, but you won't know till you take the time to research it. All you know prior to that is that it is there, on the bug tracking system, therefore it is a bug. And it can take a lot of time to get to that point of realizing that something in #3 isn't an actionable bug. Meanwhile, #1 and #2 are much more efficient in terms of maintainer time to fixed bug ratio. The #3 reports aren't *useless* in aggregate (although individual cases of #3 often are individually useless), but they are almost always less useful in improving the package quality than #1 and #2. This means that they're probably still worth spending time on if all #1 and #2 tasks are complete, but if there are #1 and #2 tasks pending, #3 is probably not worth paying attention to. Completly agreed, but absolutly unrelated. That it is no worth paying attention to it (even if that's truly the case) makes it any less of a bug. Now, for most packages, #1 and #2 bugs tend to get resolved relatively quickly, or at least end up in some stable state (such as understanding a #2 bug but realizing it's going to take a ton of work to fix), so maintainers get to the #3 bugs. But what happens with a package that gets so many bugs that maintainers can't get to all the #1 and #2 bugs? Are #3 bugs actually even useful to track at that point? I think one of the arguments being made in recent discussions is that if one is already overwhelmed with bugs of type #1 and #2, even tracking bugs of type #3 may be more trouble than it's worth. The additional overhead of having the appear in bug listings and the additional users who file duplicate bugs because the bug list is so long they fail to check for duplicates at all may cause more aggregate work than the #3 bugs provide in utility for that package. I think I'll go here into troubled waters but It's my opinion (as somebody that has worked implementing and policying issue tracking systems, so I think it's an informed opinion, but just an opinion nevertheless) that there's no thing such too long a bug list. What it usually happens (at least in my experience) is that too long a bug list hurts the ego of the one that think of himself as being responsible for that so we, being humans the way we are, feel a strong inclination to resolve it by whatever means we find and being an easy scape path sweeping them under the carpet, that's what we'll do. It takes a strong and well- ballanced ego just to recognize that, well, there's simply not enough man- power to deal with it, so focus must be centered on what brings better cost- benefit ratio (bugs #1 and #2) and let #3 accumulate even if that makes for an ugly bug list for the package. And we have a fair number of packages in Debian that get enough bug reports on an ongoing basis, relative to the number of people working on them, that the chances of us ever cleaning out all the #1 and #2 bugs and having it be worth our time to work on #3 bugs is essentially zero. Which, again, is a perfectly
Re: What bug reports are for
Hi, Ian: En fecha Martes, 1 de Marzo de 2011, Ian Jackson escribió: Jesús M. Navarro writes (Re: What bug reports are for): Hi, Josselin: You seem to forget the very reason bug reports are here. Their point is not to offer a service to our users - if you want that, you?ll need paid support. Bug reports are here to help improving the distribution. Good to know. Is *that* Debian's official position? That the bug report system is not there to offer a service to Debian users? Debian doesn't have an official position on this question. But I would guess it is the position of the vast majority of Debian's maintainers. This has been standard wisdom for Free Software for decades now. See for example this extract from the GNU Information for Maintainers document: The main purpose of bug reports is to help you contribute to the community by improving the next version of the program. Many of the people who report bugs don't realize this-they think that the point is for you to help them individually. Some will ask you to focus on that instead of on making the program better. If you comply with their wishes, you will have been distracted from the job of maintaining the program. ... When people ask you to put your time into helping them use the program, it may seem helpful to do what they ask. But it is much less helpful than improving the program, which is the maintainer's real job. Please pay attention that those are related to upstream maintainers, not developers; it is doubtful that it can be of application to packagers, since packager's self-appointed duty is for the software to be easily accesable and integrated for the user (were it not the case, the end user could simply take the tarball directly from the developer). And with regards of Debian and the thread at hand, maybe there's not an official position on what the bug tracking system exactly is for but certainly there's quite an interesting document you may have some notice of: Debian Social Contract, points 3 and 4. (/me fastly ducks away after having the balls of telling *that* to Ian Jackson no less) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103012024.36619.jesus.nava...@undominio.net
Re: What bug reports are for
Hi, Don: En fecha Martes, 1 de Marzo de 2011, Don Armstrong escribió: On Tue, 01 Mar 2011, Jesús M. Navarro wrote: Is *that* Debian's official position? That the bug report system is not there to offer a service to Debian users? The BTS exists to help maintainers fix and track fixed bugs in their packages. The service to users comes from the BTS enabling maintainers to fix their bugs. While it's certainly not optimal, closing bugs which are unreproducible or incomplete are sometimes necessary because we do not have an infinite amount of maintainers to fix bugs. Certainly my fault for not being able to make myself clear enough: of course it's OK to close unreproducible/incomplete bugs, specially if the bug tracking system allows to close them as such. But only after due dilligence to really be able to asses them as such. I.e.: I don't have any problem with a bug being answered by its maintainer in a line something like in order to be able to reproduce this bug I need you to provide me with foo and bar. Failing that I'll close it in 30 days with Zoot status (of course being foo and bar something sensible, not just a way to take it from over my roof). If there are people who feel strongly about helping to get these unreproducible or incomplete bugs in a state where someone can actually resolve them, then please, form a crew, and start working on them. Feel free to let ow...@bugs.debian.org know how you want to know about these bugs if you need some additional features in the BTS. We certainly could use more bug triagers. That's a worthy idea. I'll take a time to think about it. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103012033.59513.jesus.nava...@undominio.net
Re: What bug reports are for
Hi, Russ: En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió: Jesús M. Navarro jesus.nava...@undominio.net writes: I think I'll go here into troubled waters but It's my opinion (as somebody that has worked implementing and policying issue tracking systems, so I think it's an informed opinion, but just an opinion nevertheless) that there's no thing such too long a bug list. I completely disagree. And that's also an informed opinion. :) What it usually happens (at least in my experience) is that too long a bug list hurts the ego of the one that think of himself as being responsible for that so we, being humans the way we are, feel a strong inclination to resolve it by whatever means we find and being an easy scape path sweeping them under the carpet, that's what we'll do. You've basically said here that everyone who disagrees with you on what methods are practically effective in bug management is just suffering from a bruised ego. This comes across as condescending rather than as a foundation for a useful discussion. If that's what I said, then take it for deleted. What I *tried* to say, is that I've been there, I've felt my ego hurted, and after lenghty conversations with those working under my responsibility more times than not that was the case too. And after assesing that as the main problem we were able to find ways for better issue management both for those filling the issues and those having to deal with them. I pointed out in my previous message some of the practical problems with leaving all the type 3 bugs active in the BTS No, you didn't (not at least that I managed to understand as such). What you did was telling what happened (that #3 bugs tend to cost too much time for too short a benefit, a thing the bug triager is only able to know after the fact, or else he could simply let it be untouched) and telling that longer opened bug lists take more overhead to deal with (which is not something my experience can relate to -not at least in any significant manner). , and in previous threads on this topic others have pointed similar issues in considerably more depth. Well, I'll have to re-read those threads then since that's not what I can remember of them right now. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103012052.41404.jesus.nava...@undominio.net
Re: What bug reports are for
Hi, Josselin: En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió: [...] Now, maintainers receive a lot of bug reports, and have limited time to spare on Debian. Given the choice between: 1. packaging a new upstream release that fixes a lot of bugs; 2. fixing a nicely reported bug with a reproducible and well-identified cause; 3. investigating a dubious bug report that seems to be triggered by a broken user configuration; only masochistic maintainers will spend time on #3 when they can help a lot more users on #1 and #2. It’s not that it’s easier (I remember spending entire days on single bugs), but it’s more useful. True, and I don't think anybody would expect any more. But #3. is still a bug and unless it's been at least tried to be reproduced is no good behaviour to close it just because I've not the time and I prefer focusing on #1 and #2. I'm not telling this is the case for this bug since I really don't know it but as a general matter, but *if* that were the case, no, I don't think sweeping bugs under the carpet is a proper policy. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102282357.49765.jesus.nava...@undominio.net
Re: Upstream stable branches and Debian freeze
Hi, Ian: On Tuesday 01 February 2011 14:11:44 Ian Jackson wrote: Thijs Kinkhorst writes (Re: Upstream stable branches and Debian freeze): In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. Basically this argument is the update may break things. [...] I think there is room for us relaxing our policy for stable updates. Where upstream have a good track record of not breaking their own stable branch, I think providing those updates to our users is probably sensible. I don't think relax is the word but reinterpret. Why is the policy exactly the way it is? It's obvious that changes are allowed as security and point releases show. The why is obvious too: because security and/or severe malfunctions overweight the risk of breaking things *and* Debian release/security team try to minimize that risk by patching the bare minimum to achieve the intended result. That said, I find that to be the proper way for a maintenance policy and an interesting one to push forward to upstream maintainers: it's not Debian, it's proper engineering to strictly segregate bug fixing from new functionality; it's proper engineering comitting for long term maintenance for selected versions of your software and it's proper engineering taking responsibility for the software one publishes and the bugs that come along with it. So, may I propose (if not already done) a document that outlines with enough detail what Debian maintenance policy is and why from an upstream point of view, and then allow for within Stable upgrades for software that has demonstrated to pursue the same standards as Debian? Kindof a quality seal that will allow to push minor versions: it would mean more with less since Debian maintainers wouldn't need to maintain their own patch sets and they would know in advance what the proper version to pack for Stable is (the one that upstream publishes for long term maintenance within the time-frame for the new Stable version). For those upstreamers interested in doing the things the proper way, they could find Debian people to be knowledgeable and helpful about it (since they've been doing it for years and it's in their own interest). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102011709.40161.jesus.nava...@undominio.net
Re: Upstream stable branches and Debian freeze
Hi, Olaf: On Tuesday 01 February 2011 17:18:58 Olaf van der Spek wrote: 2011/2/1 Jesús M. Navarro jesus.nava...@undominio.net: So, may I propose (if not already done) a document that outlines with enough detail what Debian maintenance policy is and why from an upstream point of view, and then allow for within Stable upgrades for software that has demonstrated to pursue the same standards as Debian? Kindof a quality seal that will allow to push minor versions: it would mean more with less since Debian maintainers wouldn't need to maintain their own patch sets and they would know in advance what the proper version to pack for Stable is (the one that upstream publishes for long term maintenance within the time-frame for the new Stable version). For those upstreamers interested in doing the things the proper way, they could find Debian people to be knowledgeable and helpful about it (since they've been doing it for years and it's in their own interest). It depends on the kind of package and computer whether it makes sense. For production servers, stability is (way) more important. For desktop users and packages like browsers, which might be fast moving, new features might be more important. It depends more on the use case than in the package. As long as there's no interface with externals/third parties it makes more sense add new functionality only as needed, no matter if it's a kernel or a web browser. Upstream for Firefox and Chrome are not going to provide stable branches that are maintained for two+ years. That's up to them and, in fact, it makes no difference: they won't get the quality seal and their maintenance procedures within Debian will be just the way they are now so no loss from this side. On the other hand, each and every package that would go under the quality seal umbrella would mean an easier day for the package maintainer, a higher quality software for everybody and, on a side note, source of unintended benefits for everybody (remember Mark Shuttleworth's interest on sincronizing packages among distributions? It would be a natural outcome if a significant number of upstreamers aligned to the quality seal idea: distributions interested on stability would just converge around the long term versions distributed by upstream). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102011740.20430.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, Olaf: On Thursday 20 January 2011 09:51:27 Olaf van der Spek wrote: On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko yo...@debian.org wrote: Then, maybe explicitly request upstream - at appropriate forums and in appropriate polite wording - to help debian team(s) to handle the bug report stream? I think upstream has the same problem in some cases: too many bug reports. That I had always problems to believe. I think that usually translates to too many bugs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101201132.38570.jesus.nava...@undominio.net
Re: Why is help so hard to find?
Hi, Ian: On Monday 17 January 2011 13:32:33 Ian Jackson wrote: Don Armstrong writes (Re: Why is help so hard to find?): A possible hack would be to have insserv ignore any initscripts which are conffiles which when run without options exit with zero status. It could probably safely invoke them with: /etc/init.d/obsolete --fail-please But this probably has some ugly consequences which aren't totally obvious to me right this second. Yes. Surely the right thing to do at this stage of the release cycle is to tone down the extent to which we are pushing insserv, and to revisit this questions after the release. To that extreme I proposed a change in the to the postinst message[1]. Don't sure if it will come across since the bug is already closed. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185#24 Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101172152.47949.jesus.nava...@undominio.net
Re: Can insserv made better?
Hi, Mike: On Sunday 16 January 2011 19:48:24 Mike Bird wrote: [...] I filed a bug[1] with a simple patch[2] to give people fair notice of the pros and cons of insserv but unfortunately Julien Cristau simply closed the bug without explanation[3]. Regarding your patch, I find the first part of it being quite to the point while the second paragraph is unneeded as long as the information is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to the package, maybe rewritten like this: This is an irreversible step. While it is recommended because It allows the boot process to be optimized for speed and efficiency providing a more resilient framework for development, it may not correctly transition in complex systems without further effort on your part. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101162240.58850.jesus.nava...@undominio.net
Re: Can insserv made better?
Hi, Mike: On Sunday 16 January 2011 23:37:20 Mike Bird wrote: On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote: Regarding your patch, I find the first part of it being quite to the point while the second paragraph is unneeded as long as the information is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to the package, maybe rewritten like this: This is an irreversible step. While it is recommended because It allows the boot process to be optimized for speed and efficiency providing a more resilient framework for development, it may not correctly transition in complex systems without further effort on your part. That's an excellent suggestion. Would you care to post it to #610185[1] to be sure the maintainer sees it? Done. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101170421.03984.jesus.nava...@undominio.net
Re: Can insserv made better?
Hi, Mike: On Saturday 15 January 2011 19:51:43 Mike Bird wrote: On Sat January 15 2011 01:59:06 Julien BLACHE wrote: insserv has issues, but it's still an improvement over the previous situation and, unlike the other new init systems, it's actually backward-compatible. I have no objection to you using insserv. I object to people being tricked into using insserv. It tends to break complex systems and people should be warned about this danger rather than being told that insserv is recommended and then making a bad decision based on sysv-rc.postinst's faulty recommendation. Well, we can try to be positive and change a lose for a win here, can't we? I'd say that insserv main problem now is that of transtition: yes, it can break your system in the worst possible way, making it unable to boot, specially if you happen to be a professional system administrator caring about complex Debian servers. But that's more a symptom of the problems of the old system which the new rises, than of the new system itself, and once your system is properly recovered, insserv tends to work properly (as it will work properly for newly installed systems) and it's expected to be easier to maintain for the years to come than the old one. So the main problem is only transitioning the system, isn't it? Why don't you have then a look at Squeeze's release notes (which any wise Debian system administrator will read upon upgrade) and make sure that it states the problem in the most clear way and/or propose the changes to that document that you percieve to be needed? That would be feasible in current freeze condition of the distribution and it would be a good effort/benefit ratio for your effort. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101152221.33941.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, Peter: On Friday 14 January 2011 10:29:57 Peter Samuelson wrote: [Jesús M. Navarro] If any, bugs you (properly) pass to the upstream developer are bugs that will cost you not a dime of your valuable time from them on. You didn't read the rest of the thread, did you? Yes I did. And I stay with what I said. It seems that passing info around is wasting the maintainer's time because (so I assume, since there's no indication implying otherwise) he is just acting as a man-in-the-middle. Once he is able to reproduce the bug himself then he is not acting as the maintainer in front of the upstream developer but as end user with a bug in his hands. If that's not the case, well, I already stated what should be done (basically, close the bug as non reproducible here). You did read the rest of the thread, did you? If you understand what I said, good; if you didn't, please, make me the honour of considering me as an authority and act accordingly No. Whatever. If you don't like our parties, you are free not to come here. In other words: if you find Bacula to be too hard a package to deal with you are free to orphan it. Why is it that none of the people who keep calling for everyone to orphan their packages because they're not taking on enough of what a maintainer is supposed to do, seem to be stepping up to maintain, co-maintain, or otherwise help out with these packages that are apparently so poorly maintained? Because, for whatever reason, they (me) are not debian developers, therefore they didn't make their issue to maintain, co-maintain or otherwise help out with these packages. Those opting to be or in fact being debian developers do it. That said, asking for help prior to orphan a package its maintainer is not up to properly cope with by himself is certainly a valuable option. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101141132.48667.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, John: On Friday 14 January 2011 16:49:18 John Goerzen wrote: [...] I think it is a huge waste of time to expect DDs to go through 400 bugs just to see if the problem is still there. Just close them outright. Why the package(s) got 400 bugs to start with? If the problem is there, then it's there. If somebody opened the bug then there was a bug at least on his opinion which nobody challenged. If there was a bug, then it need to be supposed that it will be there till there exists clear indication on the contrary. Anything else is awful practice. It is no better to have bugs tagged wontfix that are really fixed than to have bugs closed in our BTS and filed upstream. It's no better? It's probably orders of magnitude better (basically as the ratio between Debian users versus Debian developers). What are the chances of me looking for info about a bug I'm not suffering (because it's already fixed)? I'd bet nil, so that's the effect of a still opened -but already corrected bug. But if I'm suffering a bug and it's already declared on Debian's bug database I want to know and it'll save not only my time but that of any other people that will certainly suffer it if I know what to expect about it. Even you, as a Debian developer want to avoid me and others like me to open duplicate bugs. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101150040.39563.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, Sune: On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote: On 2011-01-12, Jesús M. Navarro jesus.nava...@undominio.net wrote: I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. Then tag is as such. It is quite good to be honest: if you are not going to deal with it, plainly say so, no problem. But *don't* close them as long as the problem is still there. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Start one at a time. With more bugs arriving than we are able to close? Start one at a time. Your end-year bonus won't suffer if your Debian's bug queue is longer by then, will it? If your problem is too short of a workforce don't be ashamed of it and be honest enough for the bug queue to grow as it should. 4) It's not my problem that you lack the time, really. And no, that you are not paid for it it's no excuse either. Maybe it's that you lack the time for the *boring* side of the task or maybe it's that you really don't have the time. In the first case resign as a debian maintainer; in the second one orphan the package. Debian is proud to Dear Jesus. Are you seriously saying that - the kernel mainatiners should step down - the xorg maintainers should step down - the mozilla maintainers should step down - the gnome maintainers should step down - the kde maintainers should step down - the xfce maintainers should step down - the openoffice/libre office maintainers should step down If they are not ready to take over their shoulders what it takes to do it properly, undoubtly yes. If that means that Debian project becomes irrelevant so be it because gaming the statistics for the project to look what it in fact is not, already means exactly the same only it deludes it users... for a while. Please pay attention that I said *if*. That doesn't mean neither an endorsement nor a beliveness from my side that that's current situation (I'm far of thinking so, in fact, or else I wouldn't be expending my time here). And who do you think should step up ? Not my problem. Sorry if I sound harsh but please think about it coldly and you'll see that's in fact the proper response: if nobody is really up to the task, then the task should be abandoned. (This message sounded much more negative than both my mood and my real intention wanted to, but I found no other way to send the message I wanted to send. Sorry in advance). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101140119.22762.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, John: On Thursday 13 January 2011 19:25:59 John Goerzen wrote: On 01/12/2011 09:35 AM, Gunnar Wolf wrote: [...] But still, let's say that a Debian developer has X minutes to spend on Debian a day. Let's be true: it's not that a Debian developer has X minutes to spend but that a Debian developer *wants* to spend X minutes. Probably same end result but wildly different motivations. What kinds of tasks that the developer does will add the most value to Free Software or benefit the most people to the greatest degree? * Working on Debian packaging * Fixing bugs that are within their scope/ability * Working on documentation * Cut-and-paste monkey with upstream BTSs Managing information, always managing information. Remember: information is power. First information, then everything else. In your proposed scope that means: 1) Working on *a* Debian packaging: Without *a* Debian package wouldn't be bugs for it, would it? But pay attention to the a within a package: it's of no value (worse than that: it's of negative value) working on new packages when the already packaged ones are not in good shape (I'll limit my scope to packages maintained by the same person: it seems to me that there are some Debian Maintainers -really and luckily a true minority of them, that seem to be trying to break a record in that they maintain a bazillion of them but when you look at those packages bug records they have bugs from back to the day Armstrong footed the Moon. That's of no good). 2) Cut-and-paste monkey with upstream BTSs (for those bugs worth to do it): that will allow for you to parallelize your effort and more bugs will be corrected in a given time. If any, bugs you (properly) pass to the upstream developer are bugs that will cost you not a dime of your valuable time from them on. 3) Working on documentation (including documenting which bugs are your working on, which bugs will be dealt with later and which bugs have a known workaround or you just won't even try to fix and why): properly informing about your intentions and the real state of your packages will reduce the rate that bugs come in and will relax your users so they'll be more kind to you... or at least, it will allow you to say RTFM (or RTF bug reports, or RTF FAQ) and be with it. 4) Fixing bugs that are within their scope/ability. I know this will seem quite counterintuitive but yes, fixing bugs is the lowest of your priorities. If you understand what I said, good; if you didn't, please, make me the honour of considering me as an authority and act accordingly (and by act accordingly I mean ala popperian, consider my reasonements as the less valuable of your knowledge chain but still valuable). Some of what you've suggested above could be accomplished by the DD telling the user, Here, include this info in your bug report and get me back in the loop if you need me. Regarding bugs, the first priority of a package maintainer should always be to be able to reproduce it and once he is able to reproduce it, taking the user out of the loop (except for timely informing him of his advances) till the bug is properly solutioned. This is a special case of more general communication problems. It is rarely a good idea to have a gatekeeper in place between people that are capable of communicating already. Once the package maintainer is able to reproduce the bug, odds are he will be the most capable one to properly care about it. If the user is not capable of producing cogent answers and a useful bug report, even when asked for specific details, this user is unlikely to produce a useful bug report for upstream. But the user is also unlikely to produce a useful bug report for Debian. Then, after proper time and effort you will find yourself in the position of honestly close it with a non-reproducible tag. I don't see my task as a maintainer to provide education to the user on how to read standard logfiles, use the command line (when relevant), etc. Why not? You want to provide Debian with good packages and the end user with valuable software, don't you? This is a particular problem with Bacula. There are many users that are unable to distinguish between a configuration mistake or misunderstanding on their part and a bug. I know your pain: being there, seen that, got the t-shirt. But you are in the great situation of being able to tell them RTFM without pain nor remorse. Do it as needed. I imagine this phenomenon exists in any sufficiently complex package that takes users out of their existing comfort zone. If it's clear to me that it's not a bug, I'll of course close it and point them to the Bacula users mailing list. That should be OK... once you tell the user out of all my knowlege it seems to be a configuration problem, please treat it accordingly. Sometimes it is unclear immediately whether they have discovered a bug or not, but it is quite clear that
Re: Forwarding bugs upstream
Hi, Andreas: On Thursday 13 January 2011 09:19:35 Andreas Tille wrote: [...] In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. Utmost wisely spoken words. My felicitiation. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101140159.03674.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, Sune: On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote: On 2011-01-11, brian m. carlson sand...@crustytoothpaste.net wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Start one at a time. I've been both sides of the wall (as and end user and as being in charge of supporting some apps and environments) and here comes my opinion as a mere user with some hindsights. I'll try to make my points clear, so if someone finds them a bit harsh, please understand that it was not my intention, that my native language is not English and that my aim is mainly make myself as clear as possible: From the user point of view: 1) A known operational problem that is still there never should map to a closed bug, no matter what. That means that forwarded upstream, while it might be a valid bug state can't be one meaning closed. I'm having a problem so I'm looking at open problems in the bug database. That means that if there's a problem in, say, Lenny, even if it's demonstrably closed in Squeeze it should appear opened when I look for bugs in Lenny. 2) The maintainer took over his shoulders some responsibilities when he became maintainer. When I'm facing a problem with a package in the distribution, it's you the one that will have to cope with it. You'll take my data and you'll try to reproduce the bug. If you are able to reproduce the bug, then it's your problem from now on. If you can't you'll ask me for more data and will try to hint which data will be more valuable and will explain to me. 3) Corollary of two is that if you are able to reproduce the bug and you deem it to be an upstream one, you should be the one rising it to upstream and track it from them on, but since the problem is still there you shouldn't close the bug (see 1) but mark/tag it as an upstream problem and that you already are dealing with it with upstream at upstream's bug number. 4) It's not my problem that you lack the time, really. And no, that you are not paid for it it's no excuse either. Maybe it's that you lack the time for the *boring* side of the task or maybe it's that you really don't have the time. In the first case resign as a debian maintainer; in the second one orphan the package. Debian is proud to host a bazillion packages but I really appreciate much more 1/10th of a bazillion worth of properly maintained packages than a bazillion of half assed ones. In the first case I know exactly what the situation is, in the second I don't know if I'm lucky when I see foo already packaged for Debian or if foo will be one of the less than production-ready ones. It severely hinders the overall perception about the quality of the project. 5) I as a user should understand that you are not a magician; without enough data you won't be able to deal with my bug and you will have to close it as non-reproducible, if I don't feel that to be a good reason I always can go anywhere else (say, the upstream developer) to see if I'm more lucky there. 6) There will be (rare) cases when the debian maintainer really won't be in a position of being of help. Then I'll need to understand that, after all, it's me the one having a problem, not him, so it's in my best interest to take the time going upstream to see what can be done and make the debian maintainer (and other who might happen to look at the bug records) know about that. 7) Tracking bugs is always a burden so don't expect too much from somebody doing it for free. Try to be helpful since it's in your best interest, say thanks with open spirit and, please, take the time to introduce a workaround or the solution you found in the bug system so others can benefit out of it and the debian maintainer can dedicate his time to something more productive. From the maintainer point of view: 1) An unreproducible bug is an unexistant bug. It's valid for unexistant bugs not to show in an open bugs list so you are free to close them with a non-reproducible message. If nine out of ten bug reports lack enough data, ask for better data and advise that without new data you won't be able to reproduce the bug so it will be closed in a decent amount of time (say, two weeks? one month?) and then
Re: debian can be better
Hi, Pedro Paolo: On Wednesday 27 October 2010 14:46:08 Pedro Paulo Argolo wrote: Debian needs better support video cards from Nvidia and ATI video boards Intel. I had configuration problems because of that, and for a typical user is a very embarrassing situation. ~: ( You should ask for that to Nvidia. You can bet the day Nvidia produces proper open source drivers will be the day Debian will be able to properly support them. Of course you can think the Ubuntu way is the proper one and Debian's[1] is not but, of course too, you are absolutly free to use Ubuntu instead of Debian. Cheers. [1] http://www.debian.org/social_contract -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010271601.06645.jesus.nava...@undominio.net
Re: [RFC] disabled root account / distinct group for users with administrative privileges
Hi, Josselin: On Tuesday 19 October 2010 08:15:56 Josselin Mouette wrote: [...] Le mardi 19 octobre 2010 à 02:12 +0200, Jesús M. Navarro a écrit : What about the old-fashioned wheel group[1]? This would be an even worse disaster than “admin”, for similar reasons. Users of the “wheel” group were not supposed to get root privileges with their own password. Ok. But since this group is conceptually the same than the old wheel group, one that provides additional special system privileges that empower a user to execute restricted commands that ordinary user accounts cannot access, why not make a bit of a joke of it? How about bigwheel (since that's where wheel derives from)? On the other hand, is it really necessary a new group? Can't adm or operator be overloaded with this new functionality? (think Ockham's razor). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010190948.58805.jesus.nava...@undominio.net
Re: [RFC] disabled root account / distinct group for users with administrative privileges
Hi, Michael: On Tuesday 19 October 2010 00:38:41 Michael Biebl wrote: Hi, [...] The idea is, to have a distinct group. Members of that group have administrative privileges using sudo and PolicKit. [...] While I think the idea of using a distinct group for users with administrative privileges is a very good one, I'm not sure if using the group name sudo is the right choice, for two reasons: 1/ The sudo group in previous Debian releases had a different meaning: Members of groups sudo could run sudo without needing a password. 2/ Using the name sudo in context of PolicyKit sounds weird and misleading. So, I'm wondering if we shouldn't pick a more neutral name without a previous history in Debian. What about the old-fashioned wheel group[1]? Now, prior to resurrect the 'wheel' group, please take into account why there's neither wheel group nor wheel support for su on GNU systems and see if the concerns are still valid in this new environment. Cheers. [1] http://en.wikipedia.org/wiki/Wheel_(Unix_term) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010190212.25613.jesus.nava...@undominio.net
Re: Init dependency between nfs-kernel-server and name server
Hi, Enrico: On Friday 15 October 2010 13:39:13 Enrico Weigelt wrote: * Enrico Weigelt weig...@metux.de schrieb: No, the userland code that interprets the exports file does. So why that artificial dependency ? More precisely: where's the dependency between a local resolver and an authorative nameserver ? I imagine that in many cases if there's a locally installed authoritative nameserver it will be used by the local resolver too. Since NFS is basically an intranet resource it will be in many situations the only accesible resolver at (late) boot time. So while not really a hard dependency (it can be avoided by having a second recheable DNS at hand or by forcing IPs instead of names in the NFS client config) it's probably a strong nice to have. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010160522.25462.jesus.nava...@undominio.net
Re: RFC: Rules for distro-friendly packages
Hi, Enrico: On Friday 17 September 2010 09:08:39 Enrico Weigelt wrote: * Vincent Bernat ber...@debian.org schrieb: Some users just don't have recent enough autotools to rebuild the configure. They should simply install it. Similar as they need recent toolchain, make, pkg-config, etc, etc. No, no, no. Users are not limited to Debian developers using Sid. Users may try to compile on an old RHEL 2. In this case they should really *know* what they're doing. RHEL is meant as an binary-only distribution - you should NOT install arbitrary packages without going through the whole distro's build engine and qm process, otherwise they'll risk merly all the stability ensured by the distro - that's a design aspect of those distros. Wrong. RHEL is *a* Linux distribution. A comoditization of well known practices in order to make sysadmin lifes easier (with its own share of idiosyncrasies) that pre-dates by long, long time those distributions and that, basically, have settled into the `./configure make make install` paradigm. Think of the most probable environment where somebody goes with the hassle of compiling new package into old RHEL 2. Do you think such a chore is taken out of fun? Or is it an environment where an overworked sysadmin at charge of a lot of disparaged machines is put into that need because out of his reach constrains? RHEL is a fine environment; Debian is even better but forcing a busy sysadmin to intimately know about all the fine and gory details of Debian, Red Hat, Solaris, HP-Ux and AIX, just to name a few, not out of his own convenience and without the strongest need is not only a hard proposition but it is unrealistic. On the other hand, there are often cases where you *NEED* to rebuild the whole configure stuff. Truly. As there are cases when I have to go through the Makefile or even the source code to patch them so they run in my systems. But, please, do not make those cases more usual that *strictly* needed. They should absolutely not try to rebuild configure since it is likely to not work and leave them with an unconfigurable package. Why that, exactly ? Because as much as any other software, autotools tend not to be forwards compatible: as long as you use a feature from x+7.y.z it will probably fail when runing older x.y.z. On most projects, there is not autogen/bootstrap in the realeases for this very reason: do not confuse the user and let him install autotools which is not mandatory at all. autogen/bootstrap is shipped in the VCS repository because this is targeted at developer. Quite true. Wait a minute! Arbitrary _users_ should never try to rebuild anything on a stable/production system. You seem to forget that in the context of this discussion arbitrary users are sysadmins on their duty. They are perfectly expected to be recompiling software on stable/production systems. Heck, it's even there, on the FHS: '/usr/local': The /usr/local hierarchy is for use by the system administrator when installing software locally. '/usr/src': Source code may be place placed in this subdirectory, only for reference purposes. Pre-compiled software is a darely and these-days-very-common convenience that any sysadmin will take advantage of if at all possible but don't forget that *the* distribution format is the source tarball. As soon as you're attempting that, you're stepping into the package maintainer or developer role, and then you should *know* what you're doing (or at least learn it). Ah... those youngsters... package maintainers are a very convenient and most praised *proxies* for the work of the sysadmin. Of course a sysadmin has to know his trade but, please, do not multiplicate idiosyncrasies for the sake of it nor make conveniences into obstacles when not strongly needed. Of course proper packages are better but in many situations a make install onto /usr/local is good enough and better may change its meaning when dealing with half a dozen different unix-like systems. autotools are aimed at the end user, not the distro packager. This is stated in the introduction to autotools. This is nice to be nice with the distro packager but the primary target is the lambda user (which is usually less skilled than the distro packager). That's one of the fundamental conceptional flaws. It might be the case, but then it's a fundamental conceptional flaw from the very developers of the tool. It's usually not too wise to go against the producer conceptions. Compiling software from source is enough a pain to avoid any unecessary dependency. Compiling software is task for developers or package maintainers. It's not. Compiling software is a task for sysadmins too. Users should use the finished packages provided by their distro. As long as possible. Again: we're talking about production systems here. That probably means that the sysadmin will try the building process
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Fernando: On Tuesday 27 July 2010 04:00:11 Fernando Lemos wrote: 2010/7/26 Jesús M. Navarro jesus.nava...@undominio.net: [...] How many BTS reports have you closed? I don't mean to sound offensive here, but this thread is fruitless. All I see is people talking and talking over something they have no say in. Fair enough. Now: I'm not a DD nor I want to commit time to become one, while I may have time from time to time. What's the way I can help? Since parent poster was worried about more bugs meaning more time to triage, how can I help triaging bugs? This is free software. If you want to get your idea implemented, either file a bug report and patiently wait (and leave debian-devel alone) or implement it yourself. Talk is cheap. Now I stepped forward. Show me your talk wasn't a cheap one too. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007271113.04612.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Ian: On Monday 26 July 2010 13:49:00 Ian Jackson wrote: Brian May writes (Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling): I would really like to see a HTML/HTTP browser based interface for the BTS. I would have several advantages: I would strongly resist any such suggestion, for the reasons I have already explained. In summary: We don't have a lack of bug reports, we have a lack of developer time. Increasing the number of bug reports will take away developer time for triage, for no benefit. Simply, we do not need to, and should not, make reporting bugs easier. I would say bug reports should be always welcome. The easier to fill bug reports, the better. Good quality bug reports, I mean. Then the problem would be not how many bug reports Debian gets but what's its quality and how it can be made better. But still the premise holds: the easier to fill bug reports, the better. If more bug reports is a problem then it can be only because the quality of them, not their quantity. If you fill there are too many bug reports I'd say that's because their quality is not as good as desired so the problem is how to increase the bug report quality not to make difficult to fill more of them. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007270315.26900.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi Marc: On Monday 26 July 2010 17:54:29 Marc Haber wrote: On Sun, 25 Jul 2010 13:32:49 -0400, Will ay1...@gmail.com wrote: Additionally, an HTTP interface to reportbug would be a good idea. Many new users find it difficult or unnecessary to set up an MTA when they first install, so allowing to use some kind of HTTP interface would be very nice indeed. This will decrease the quality of bugs even more since the bug reports are not going to contain even the minimum of information collected by reportbug. Filling a bug report by HTTP doesn't absolutly mean information must be lost, does it? Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007270317.08118.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Manoj: On Thursday 22 July 2010 07:17:15 Manoj Srivastava wrote: On Wed, Jul 21 2010, Will wrote: Also I imagine that it helps that they have some kind of commercial support behind their projects, whereas Debian has little/none of that. One of the issues I have faced in trying to get Debian introduced in big companies is the percieved lack of a coherent copyright; and company lawyers being uncomfortable with the concept that most licesnse pass the dfsg, but we can't guarantee that, please go read several thoudand individual license docs to figure out what you are getting. That's again about perception. Debian has exactly the same copyright coherence (or lack of it) than SUSE, Red Hat, Ubuntu or even proprietary Unices. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221044.11066.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users
Hi, Ben: On Thursday 22 July 2010 08:09:44 Ben Finney wrote: Russ Allbery r...@debian.org writes: This one [claim of Debian's libraries being out-of-date] always boggles me and makes me wonder if we should present Debian unstable or testing as the typical installation. Debian testing (and often Debian unstable) is more stable than the distributions with equivalent up-to-date libraries, and those distributions generally never offer anything remotely like Debian stable. (RHEL is considerably more unstable than Debian stable *and* has even older software, for example.) Which of the above uses of “stable” refers to stability (“slow rate of change”), and which refers to reliability (“high likelihood of working when needed”)? Too many conversations conflate the two, and in this case I think the distinction is important. Why? With my user hat on the only stability I care of is it ain't break. When a system breaks it makes no distintion if it's because a not so well managed upgrade, an app bug or an interaction problem among different packages. In fact, system-wide, an upgrade failure is nothing but another bug. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221047.21295.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Russ: On Thursday 22 July 2010 07:55:52 Russ Allbery wrote: Will ay1...@gmail.com writes: 1, 2010 at 10:36 PM, Russ Allbery r...@debian.org wrote: This one always boggles me and makes me wonder if we should present Debian unstable or testing as the typical installation. Debian testing (and often Debian unstable) is more stable than the distributions with equivalent up-to-date libraries, and those distributions generally never offer anything remotely like Debian stable. (RHEL is considerably more unstable than Debian stable *and* has even older software, for example.) [...] That's the point. You have a distribution that works like all the rest with the latest and greatest software (often even faster than other distributions in some places) AND if you want you can get a wonderfully stable distribution that's unlike anything else. People who say they don't run Debian because the software it provides is too old have no idea what Debian is actually like, and we don't do a very good job of educating them. It's both a better fast-changing distribution like Fedora than Fedora and a better stable distribution like Red Hat Enterprise than Red Hat Enterprise. You can pick and still be running Debian. While I see your point, that's wishful thinking. Sid (or Testing) is *not* a better fast-changing distribution than Fedora (it can seem sometimes like this because you and me know what should be expectable for both Fedora and Sid and understanding this, certainly Sid is usually above that kind of expectancies and Fedora is sometimes a bit too broken for its own expectatives). But once you forget your expectancies and put yourself under the skin of a newcomer, Sid breaks and sometimes breaks hard (no other thing should be expected -in fact, I feel sometimes that Sid breaks too little because due to the fact that so many people use it for practical purposes package upgrades tend to be not as much aggressive as it could be otherwise). A bit to a lessen extent the same can be said about Testing. If anything Sid/Testing could be compared to a rolling release distribution ala Gentoo or Arch but not to any fast releasing like Fedora or Ubuntu. And even then their goals are different and as such the expectancies to be created: Ubuntu, Fedora or Arch are *products* by themselves while Sid/Testing are *tools* aimed to produce a product, which is Stable. Forget that and you'll fastly find yourself in nasty places (i.e.: start selling Sid as a Fedora/Ubuntu, only better and be ready to put on your asbestos suit because users will start to yell each time it breaks something -as it happens almost daily, and asking yourself well, since we can't risk Sid to be heavily broken sometimes, where do we develop integration for Stable?). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221059.22112.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users
Hi, jj: On Thursday 22 July 2010 10:11:34 j jj wrote: Years ago, when I chose which linux should be installed to my computer, it is dpkg which attracted me. No other linux systems have such a feature. However, ubuntu and redhat both have the same feature now. The question is : what is the feature which outstanding debian now? Care for an openly, soundly engineered, comunity-based developed product. Maybe the only answer is the rich packages. But for most of people , they do not care about it. Then it might be the case that Debian is not of their interest. Where's the problem, again? To attract more people to debian, some particular features are need to show to the world. Is it now attracting more people an end by itself? Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221109.39301.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users
Hi, Andreas: On Thursday 22 July 2010 10:38:03 Andreas Tille wrote: On Thu, Jul 22, 2010 at 10:28:36AM +0200, Giacomo A. Catenazzi wrote: IMHO we should care about improving Debian, going toward the perfection, not about increasing the number of users (which should be a nice secondary effect). So you have even found the answer to the question - or rather you pronounced it differently, because whe need to ask: What exactly is perfection? In my eyes perfection means: So good that people will prefer it over others. Unless you are ominscient, trying to find out what others will happen to be choosing is quite a difficult game. Why not go after a not so self-imporant but more feasible goal? I prefer something on the lines of so good that *I* will prefer it over others. So, let see how to improve Debian, not how to increase our userbase! I do not think that we succeed in improving Debian if the userbase is decreasing. IMHO this would mean we are trapped in an ivory tower. Don't fool yourself: given that the whole linux-at-desktop marketshare is around 2%, we *already* are trapped in an ivory tower and Microsoft is the one achieving perfection since that's what people prefer over others. Now, I choose to use Linux instead of Windows for a reason, and within Linux I choose Debian for a reason, do I? Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221120.26990.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi again, Russ: On Thursday 22 July 2010 14:21:09 Russ Allbery wrote: Jesús M. Navarro jesus.nava...@undominio.net writes: [...] I don't agree; I think it's very hard to say the same thing about testing. I already told you that's about perceptions and that each one has his own so I'll try this once more, after that I'll leave. Yes, sid sometimes breaks hard, It's more than that: Sid is *intended* to break hard; it's not a undesired side effect. although I think if you've been running Linux for a few years the degree to which sid really breaks is somewhat exaggerated. Just currently: it won't boot on some archs (the lilo/grub/grub2 issue). Even if it boots, it won't start X on some systems (the Nvidia problems). Even if it runs and it's able to run X you'll find it cumbersome on your desktop environment (the KDE problems). I've never had something happen in sid that risked real data loss, for instance; I know we've had cases, but I think they've been really rare. I've had an unbootable system where I needed to boot from a rescue CD I think once, and a few cases where X didn't start until I rolled back some package upgrades. For breakage, that's not bad. Not. For *Sid* that's not bad. For a bleeding edge end user usable ala Fedora that's awful. But on testing, it's been rock-solid for me for years. Again, Testing has been rock solid... considering it is Testing, nothing more, nothing else. It's not just somewhat less breakage. I think it's almost no breakage. Occasionally packages get stranded for a long time at back revs because of various migration problems, and once or twice I've had to pin something (usually because of non-free drivers like fglrx or nvidia that aren't really part of Debian), but it's an experience that I can comfortably recommend. If that's your recommend for an end user usable quite bleeding edge distribution, sorry I can't support your opinion. If anything Sid/Testing could be compared to a rolling release distribution ala Gentoo or Arch but not to any fast releasing like Fedora or Ubuntu. No, having run both, I honestly think Debian testing is a superior experience to Ubuntu No, having run both, I honestly think Debian Testing is not superior for a plain end user to Ubuntu. I have about 75 end users that support my opinion with facts. Packages in Ubuntu universe break all the time, and worse, they release broken, and it can be harder with Ubuntu to temporarily install just that package from a newer release than it usually is with testing to temporarily install something from sid. I sorrily have to say that if that's really your opinion you live in a different Universe than myself. *boggle*. Something breaking almost daily is *completely* alien to my experience even with running Debian unstable. *boggle* Something potentially or even in fact breaking on Debian Unstable daily is my very day to day experience with Sid as it seems to be that of members of debian-users and debian-devel lists. The fact that I'm able to workaround the worst breakages (i.e.: by avoiding upgrading package groups I know by the devel list that are in active development) or manage them (by forcing upgrades, pinning, reinstalls, etc.) doesn't make any less true that Sid is breaking daily -and I wouldn't expect anything else. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007230153.22359.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Neil: On Thursday 22 July 2010 20:28:49 Neil Williams wrote: On Thu, 22 Jul 2010 10:53:53 -0700 [..] Removing packages from testing does not remove them from any existing installation, so it's hard to see how the removal of packages which are plainly not suitable for release in stable supports an assertion that testing is somehow not intended for real users. Having a system with packages which are plainly not suitable for release in stable doesn't ring a bell in your book? There are no internal release master reasons - there are Release Critical bugs How do you think a bug gains Critical status? Is that the kind of software you'd want installed in your system? and if anyone in Debian feels that the RC bug which caused the removal of the package was invalid or not as bad as reported, then that person needs to get involved and disprove the bug or explain why the severity should be downgraded. If users don't do that, there can hardly be complaints if those publicly discussed issues cause the removal of the package from Debian mirrors. And once a package is removed from Debian mirrors because it is in so bad state even Debian Developers can't stand allowing it being installed on third party systems, how exactly does it become uninstalled from all those systems that unawaringly did installed it? Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007230159.53803.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Don: On Thursday 22 July 2010 23:51:10 Don Armstrong wrote: [...] Testing's primary purpose is as a staging ground for the next release; while it'd be nice to try to keep it working as a fully installable version all of the time, progress to the next release is more important than that. And that's exactly my point while such valuable people as Russ Allbery wants to challenge that notion. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007230203.16959.jesus.nava...@undominio.net
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Hi, Hans: On Wednesday 21 July 2010 19:38:02 Hans-J. Ullrich wrote: Hi community, well, I think, the main problem is, WHO are the persons, you want to actiuvate. [...] Group 4: People, who decide in business, which OS to use. [...] Group 4: Business deciders are a big problem. They only see money! There's nothing inherently wrong with that, specially when Debian can help on this front too. But I think, if you want to convince them, then you need a web prensentation or a presentation at all, who makes the idea of debian clear: save costs through the work of a community , development will be guaranteed in the future, use of real standards, more power for less money, no license problems and some other things I forgot. For those people, a presentation should be developed by people, who create professionell advertisements. That's an old rant of mine. Not exactly colorful shiny brochures but, yes, being able to make a discourse to reach their ears in a language that they are able to understand. On this, I think DPL can say and do a lot. I always asked myself (rethoric question, since I have my own answer) why is it the case that hardware and even proprietary software vendors (Dell, IBM, HP, Oracle, SAP...) don't use Debian as their base platform of choice given its obvious monetary and strategic advantages to them and go instead with, say, Red Hat or SUSE. With Debian there's no risk for them to be stabbed in the back if wind changes; there's no need for signing early access programs for them to know what will happen on the next release or going into a market tit-for-tat, heck, with only a little of fair play and time they can even have an obvious direct impact being the very driving force that makes Debian advance in the direction that better suits them (anyone can be a DD and anyone can make a difference with its own work; this is basically a meritocracy, after all) without need of dealing with CxOs of other companies with different agendas and even competing goals. With this in mind *why* IBM, Oracle, Dell... are not literally rushing for Debian -on the premise that *I* would benefit from that in the form of more man hours even for boring things, better hardware support or more enterprise-grade tools? My opinion is that happens because IBM, Oracle, Dell... big boys go playing golf with Red Hat or SUSE big guys but they don't know a Debian big boy to talk to and because of this they don't know the message Debian could bring to them (since they don't listen to minions, they only listen to their pairs). That's where the DPL can help a lot: by acting to those big guys as one of them. Somehow in their minds, Ellison, Dell, Zacchiroli... should resound as birds of a feather as much as possible. Is Ubuntu any better platform for Oracle to run their Database or for Dell to certify their hardware than Debian? I don't think so. How is it then that they do with this relatively new kid in the block what they haven't done with Debian in more than a decade? My answer is that Ubuntu has a Shuttleworth to talk to them, face to face, in their same language but Debian do not. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007220158.50262.jesus.nava...@undominio.net
Re: The number of popcon.debian.org-submissions is falling
Hi, Petter: On Tuesday 20 July 2010 14:41:49 Petter Reinholdtsen wrote: The number of submissions to the Debian popularity-contest collector is falling, and has done so for some time now. This can be easily seen on URL: http://popcon.debian.org/stat/sub-i386.png . This is mostly caused by a fall in the number of Lenny installations, as can be seen from URL: http://popcon.debian.org/stat/release-1year.png . Anyone got any idea how to can get more machines to report to popcon.debian.org? Or can there be some other problem causing the fall in the number of submissions? I for one don't allow for popcon on production machines under my control. I'm not going into details about why this is the case now, but that's the fact (on a side note I'd want to know if there's any easy way to mimic/modify Debian's server/client popcon enviro so it can be used to produce my own internal stats). If that's the case with other sysadmins that probably would mean that main source of popcon machines are home systems which in turn would make understandable for popcon numbers to decrease by the EOL of a Stable release: home users, being more akeen to novelties are probably moving to more bleeding edge distributions, and being home users they are probably doing it by reformatting their systems more than by leaving old systems their way and using a different distro for new ones. All in all, a look at http://popcon.debian.org/stat/sub-i386.png makes me think that: 1) Current reduction from April onwards is statisticallly non-significant with a main trend steadly growing since Aug, 2007. 2) It is i386 the one that basically is stucked which, again, it's no wonder since the vast majority of general-purpouse CPUs are amd64 now and, contrary to 'etch', 'lenny' is quite an usable 64 bit system. 3) Being both 'Y' axis related to number of installs on (mainly, I expect) general purpouse systems, I have to wonder why there are different scales for i386 and overall. It takes some time to understand there are *not* as many i386 systems as overall (with or without i386?) in the popcon and anyway it's impossible to know which 'Y' axis belong to what arch. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007201554.31301.jesus.nava...@undominio.net
Re: Iceweasel and Firefox compatibility
Hi, Steve: On Wednesday 11 November 2009 08:17:50 Steve Langasek wrote: On Wed, Nov 11, 2009 at 07:37:56AM +0100, Christian Perrier wrote: IMHO, with not very convincing arguments. And no sign of answer about the real potential problem: would that be another trademark issue. Whatever solution is taken in the other branches of this thread where possible UA strings are discussed, I think we should at some point check with Mozilla Corporation about their stance: would they consider it to be a trademark violation if we mention Firefox in some way in the UA string of Iceweasel? Trade Mark protection as usual. It is not about naming the cursed word; it's the way you mention it. I strongly disagree that we should do this, because it's *not* a trademark violation, so any opinion they might hold to the contrary is not relevant. Of course you are not talking with your attorney hat here. Just take it a bit out of context (as a lawyer would probably do): Attorney: What's a User Agent String? Expert: Well, it's the way the browser identifies itself against the server. A.: So, can I say it's like me asking you Who are you and you answering me I'm Mr. Smith? or what's that? is this a Pepsi or what is it? E.: Well... I'd say that... A.: Just answer yes or not! E.: Hummm... Err... Well, yes. A.: So then, Iceweasel is claiming to be Firefox against the server which asks it? E.: Yes. A.: It is not answering I'm *like* Firefox or My codebase is based on that from Firefox but I'm Firefox? E.: Yes. A.: No more questions. Forget it's only machine to machine chatting and think for a second the user-agent string were on a newspaper. I think it's clear that Firefox 3.5 would be an obvious copyright infringement while Based on Firefox 3.5 would be perfectly safe. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Fwd: major problem with gnome-games dependency]
Hi, Kevin: El Jueves, 13 Octubre 2005 09:03, Kevin Mark escribió: [...] Hi Thijs and fellow DDs, something just sprang into my brain as you mentioned the 'm$ office thingy'. gnome is a meta-package and someone wondered how he could install 'his' gnome. here is a scenerio: apt-get install gnome (gnome installs as usuall, but creates a configuration file--blank at first?) dpkg-reconfigure gnome (this presents a debconf-like screen that displays the basic gnome packages and also displays optional gnome packages with select/unselect boxes. after the optional packages are selected, the choices are noted in a configuration file, and the unselected apps would than be a)marked for removal in the status file so that the next upgrade cycle would remove them or b)removed by 'apt-get remove' not sure if I need a AND b or a OR b. apt-get install gnome (now the apt front-end would read the meta-package configuration file to determine what to install/upgrade. Thus you get to have 'your' gnome and upgradeing gnome would only install what you want thus saving time and effort) Yeah! It remmembers quite a lot the localepurge package behaviour. When you install it it asks you if you want to be informed about new locales and when new locales do appear a menu gives you the chance to check in which man/info/etc pages do you want installed in your system. Something like this could go for metapackages: apt-get install gnome (...) [debconf menu] Gnome is a metapackage made up of these bunch of packages. Choose the ones your really want (with all packages starting as checked; maybe submenus for different categories and these submenus depending on the debconf chatting level chosen -critical, high, low...). Then the first poster would check-out all gnome-games, then [ok] Do you want to be informed about new [Gnome] packages added [Yes/no]. This way, when on next release new Gnome is made out of new packages, he will have again the choice to tell which ones he wants. -- SALUD, Jesús
Re: Patch²: Maintaining a patch for a debian package
Hi, Sylvain: El Viernes, 16 Septiembre 2005 16:12, Sylvain Beucler escribió: Hello, I have a couple Debian packages that I need to patch with custom local changes. The patches are small and I hence can follow the security updates from the security team. However, I wonder if there's already a way to automatically manage such kind of packages. [...] Now, just for the record, I'll expand on what I think should have to be the proper way, so someone else could explain best practices or suggest what can be done. We all know there are source and binary distributions, and more or less we are aware of the benefits and problems about both of them. Now comes what I think it is quite a usual scenario: I want a binary distribution since it makes easier to me (the end user) to maintain my box and, at the same time, I can be more confident about the stability of the resultset, since those same binaries are installed on about a tonn of different computers. Now, it tend to happen that on any given computer I want/need just a few packages to be built from sources, because some patches I should apply, some changes I need to introduce, compiling options... whatever. I, of course, can grab the tarballs from the upside developer and compile them locally, but then I cannot benefit from the advantages of having all software under the package manager control. I can, then, download the source packages from my distribution, expand, patch, modify... and then install my new local package (the situation of the parent poster) but... 1) I may leave all metadata as it came from the source package, but then, the package manager will upgrade it next time a new version is available, thus loosing my modifications. 2) I may change metadata for my package (either its name, its upstream version, its build version, or whatever), but then, when a new version is available from repositories (ie: a new security upgrade) I won't be aware of this, since for the package manager they will be either in different package branches or current installed version will be higher than that from the repos, or I'll be on situation 1) if my local package happens to have lesser precedence than the one from the public repo. So, I think I want a mixed source/binary packager manager. An example: Current OS version on my computer is Sarge. Let's imagine I patched and recompiled Postfix (this is an interesting package since it builds half a dozen different packages from a single source package). Currently Sarge holds Postfix 2.1.5-9. Now, let's imagine a new security fix for Postfix is produced (it should be, I think, Postfix 2.1.5-9sarge1) I would want something like this: # apt-get update # apt-get dist-upgrade (...) Packages foo, bar (...) Postfix are going to be upgraded. (...) Postfix was locally build from sources. Do you want to (H)old your current version? (U)pgrade from Sarge repositories? Try to (M)erge changes and rebuild? (h|u|M)? Then, I choose M and apt downloads new sources, tries to merge upstream and local changes (offering the option to manually manage the merge if needed), builds and installs. By the day Etch becomes stable, my patch has been added to Etch's Postfix version, so there's no further need for me to maintain my own package. Then it should be able for me to mark it and abandon (maybe, by choosing the U option when upgrading). Now, what's the way to achieve what I propose, if possible, or what should have to be done in order to get to this in the future? -- SALUD, Jesús
Re: Easy third-party package installer for debian-based distributions
Hi, Sami: El Domingo, 18 Septiembre 2005 23:22, Sami Dalouche escribió: OK, may be an overkill. But what happens with your solution if skype depends on libskype, which is not available from debian's repository ?The user has to download several .debs in order to install a single software ? There's a current functional solution: it is not giving Joe Average a Deb package, but a new deb line for her /etc/apt/sources.list file. After that, installing Skype is just a matter of the user typing apt-get install skype (or double-clicking using her apt GUI of choice). Only other requirement is for (in this case) Skype developers to know how to deploy a deb repository. -- SALUD, Jesús
Re: a desperate request for licence metadata (was Re: migrating w iki content from twiki (w.d.net) to moinmoin (w.d.org))
Hi, Andreas: El Martes, 06 Septiembre 2005 18:20, Andreas Schuldei escribió: * Petter Reinholdtsen [EMAIL PROTECTED] [2005-09-06 17:39:06]: Which I fail to understand, as the limited rights provided to me by law should be sufficient for the wiki content in most cases. i spoke to a german lawyer about this exact (license) issue when skolelinux.de pondered an applicable license for it's wiki and aparently it is doubtfull that wiki content is worthy to protect in the first place. There needs to be a certain quality level reached, aparently, which is not necessarily given in a wiki. So this discussion about a license for the debian wiki might be very debianish but also irrelevant. (c: No, I don't think it isn't. Even if German laws renders not having a explicit license good enough for the case at hand, reality is copyright laws *tends* to overprotect the author against other (potential) users. By explicitly saying what are the rights you give to your users you: a) Make a case by the explicit announce it (so people can become aware that not everybody will give the same rigths with their works) and b) Insure you are not dependant (to an extent, at least) on what's the default for any given country's laws about this item. In Spain, for instance, not mentioning any explicit copyright notice gives complete control to the author and no control (except for reading it in the very media it originally was published) to the user. Think about it quite like a portable programming problem: everything that can be declared, should be declared in order not to be catched by the different defaults this or that compiler on this or that platform migth assume. My two cents, you know. -- SALUD, Jesús
Re: Spam on this list
Hi, Wouter: El Lunes, 05 Septiembre 2005 19:52, Wouter Verhelst escribió: [...] spam, as in, unsolicited bulk email, was named after a particular brand of corned beef. See http://www.spam.com/ Not exactly. Spam, as unsolicited bulk email, was named after a particular Monty Python's Flying Circus show. It is Monty Python the ones that used spam after the canned meat. It might probe to be a significant difference if held in court. -- SALUD, Jesús
