Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > > Ingo Molnar wrote: > > > > > > > >for example git-bisect was godsent. I remember that > > > >years ago bisection of a bug was a very laborous task > > > >so that it was only used as a final, last-ditch > > > >approach for really nasty bugs. Today we can > > > >autonomouly bisect build bugs via a simple shell > > > >command around "git-bisect run", without any human > > > >interaction! This freed up testing resources > > > .. > > > > > > It's only a godsend for the few people who happen to be > > > kernel developers > > > and who happen to already use git. > > > > > > It's a 540MByte download over a slow link for everyone > > > else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > "git-repack -a -d" gives me ~220 MB: > > $ du -s .git > 222064 .git > > anyone who can download a 43 MB tar.bz2 tarball for a kernel release > should be able to afford a _one time_ download size of 250 MB (the size > of the current kernel.org git repository). If not, burning a CD or DVD > and carrying it home ought to do the trick. Git is very > bandwidth-efficient after that point - lots of people behind narrow > pipes are using it - it's just the initial clone that takes time. And > given all the history and metadata that the git repository carries (full > changelogs, annotations, etc.) it's a no-brainer that kernel developers > should be using it. > > (and you can shrink the 250 MB further down by using shallow clones, > etc.) > > yes, some people complained when distros stopped doing floppy installs. > Some people complained when distros stopped doing CD installs. Yes, i've > myself done a 250+ MB download over a 56 kbit modem in the past, and > while it indeed took overnight to finish, it's very much doable. It's > not really qualitatively different from the 1.5 hours a kernel tar.bz2 > took to download. Probably that once in a while, we should set up a complete tree in a tar.bz2 format on kernel.org. It would help a lot of people behind small pipes. I have been encountering problems with git-clone when the link is unstable. After the smallest error, it erases everything and you have to retry from start, which is quite frustrating and expensive. At least, downloading a tar.bz2 with FTP would be easier and a lot more reliable. Also, people could download it from their workplace and bring it home. Willy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 15:35, James Bottomley wrote: clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). Thanks for the comment. That managed to indeed shave a few extra bytes off my already "repack -a -d" packed repo still. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: size of git repository (was Re: [BUG] New Kernel Bugs)
* Pavel Machek <[EMAIL PROTECTED]> wrote: > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > Ingo Molnar wrote: > > > > > >for example git-bisect was godsent. I remember that > > >years ago bisection of a bug was a very laborous task > > >so that it was only used as a final, last-ditch > > >approach for really nasty bugs. Today we can > > >autonomouly bisect build bugs via a simple shell > > >command around "git-bisect run", without any human > > >interaction! This freed up testing resources > > .. > > > > It's only a godsend for the few people who happen to be > > kernel developers > > and who happen to already use git. > > > > It's a 540MByte download over a slow link for everyone > > else. > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > git-prune-packed. What am I doing wrong? "git-repack -a -d" gives me ~220 MB: $ du -s .git 222064 .git anyone who can download a 43 MB tar.bz2 tarball for a kernel release should be able to afford a _one time_ download size of 250 MB (the size of the current kernel.org git repository). If not, burning a CD or DVD and carrying it home ought to do the trick. Git is very bandwidth-efficient after that point - lots of people behind narrow pipes are using it - it's just the initial clone that takes time. And given all the history and metadata that the git repository carries (full changelogs, annotations, etc.) it's a no-brainer that kernel developers should be using it. (and you can shrink the 250 MB further down by using shallow clones, etc.) yes, some people complained when distros stopped doing floppy installs. Some people complained when distros stopped doing CD installs. Yes, i've myself done a 250+ MB download over a 56 kbit modem in the past, and while it indeed took overnight to finish, it's very much doable. It's not really qualitatively different from the 1.5 hours a kernel tar.bz2 took to download. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote: > On 18-11-07 13:44, Pavel Machek wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > >> It's a 540MByte download over a slow link for everyone > >> else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). James - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 13:44, Pavel Machek wrote: On Tue 2007-11-13 12:50:08, Mark Lord wrote: It's a 540MByte download over a slow link for everyone else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? clean-cg? But failure to run "git repack -a -d" every once in a while? Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
size of git repository (was Re: [BUG] New Kernel Bugs)
On Tue 2007-11-13 12:50:08, Mark Lord wrote: > Ingo Molnar wrote: > > > >for example git-bisect was godsent. I remember that > >years ago bisection of a bug was a very laborous task > >so that it was only used as a final, last-ditch > >approach for really nasty bugs. Today we can > >autonomouly bisect build bugs via a simple shell > >command around "git-bisect run", without any human > >interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be > kernel developers > and who happen to already use git. > > It's a 540MByte download over a slow link for everyone > else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 01:50:43PM +1100, Neil Brown wrote: > Virtual Folders. > > I use VM mode in EMACS, but I believe some other mail readers have the > same functionality. > I have a virtual folder called "nfs" which shows me all mail in my > inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject > field. When I visit that folder, I see all mail about nfs, whether it > was sent to me personally, or to a relevant list, or to lkml. Hm (googling around for "mutt" and "virtual folders"): looks like I can get most of the way there in mutt with some macros based on its "limit" command: http://www.tummy.com/journals/entries/jafo_20060303_00 Thanks.--b. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 10:34:37PM +, Russell King wrote: > On Tue, Nov 13, 2007 at 06:25:16PM +, Alan Cox wrote: > > > Given the wide range of ARM platforms today, it is utterly idiotic to > > > expect a single person to be able to provide responses for all ARM bugs. > > > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > > > bugzilla, and really *WISH* I could pull out of that function. > > > > You can. Perhaps that bugzilla needs to point to some kind of > > [EMAIL PROTECTED] list for the various ARM platform > > maintainers ? > > That might work - though it would be hard to get all the platform > maintainers to be signed up to yet another mailing list, I'm sure > sufficient would do. As long as it would just be bug reports, I'm sure that most of us could be persuaded to subscribe. Adding another list for general discussions is probably not going to be read, the current list provides more than enough to keep us busy. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > I don't see any reason that we couldn't have a tool accessible to Ubuntu > users that does a real "git bisect". Git is really good at being scripted > by fancy GUIs. It should be easy enough to have a drop down with all of > the Ubuntu kernel package releases, where the user selects what works and > what doesn't. It's possible users who haven't yet downloaded a git repository have to surmount some obstacles that might cause them to lose interest. First, they have to download some 190 megs of git repository, and if they have a slow link, that can take a while, and then they have to build each kernel, which can take a while. A full kernel build with everything selected can take good 30 minutes or more, and that's on a fast dual-core machine with 4gigs of memory and 7200rpm disk drives. On a slower, memory limited laptop, doing a single kernel build can take more time than the user has patiences; multiply that by 7 or 8 build and test boots, and it starts to get tiresome. And then on top of that there are the issues about whether there is enough support for dealing with hitting kernel revisions that fail due to other bugs getting merged in during the -rc1 process, etc. I agree that a tool that automated the bisection process and walked the user through it would be helpful, but I believe it would be possible for us do better. - Ted - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Thu, 15 Nov 2007, Theodore Tso wrote: > On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > > I don't see any reason that we couldn't have a tool accessible to Ubuntu > > users that does a real "git bisect". Git is really good at being scripted > > by fancy GUIs. It should be easy enough to have a drop down with all of > > the Ubuntu kernel package releases, where the user selects what works and > > what doesn't. > > It's possible users who haven't yet downloaded a git repository have > to surmount some obstacles that might cause them to lose interest. > First, they have to download some 190 megs of git repository, and if > they have a slow link, that can take a while, and then they have to > build each kernel, which can take a while. It should be possible for it to clone only the portion that they actually care about based on where the known-good version is. It should also (in theory, anyway) be possible to put off some amount of the download until it's actually going to be relevant. > A full kernel build with everything selected can take good 30 minutes or > more, and that's on a fast dual-core machine with 4gigs of memory and > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > kernel build can take more time than the user has patiences; multiply > that by 7 or 8 build and test boots, and it starts to get tiresome. None of this is going to take as long, even on a slow link and a slow computer, as waiting for a response to a mailing list post. It'd annoy users who are specifically waiting for it, but if the interface is that the user says "kernel package X didn't work but the current kernel does", and it says "I'll let you know when I've got something to test", and the user watches a DVD, and afterward finds a message saying there's something to test, and tries it, and reports how it went, and the process repeats until it narrows it down to a single commit after a couple of days of the user getting occasional responses, it's not that different from asking for help online. > And then on top of that there are the issues about whether there is > enough support for dealing with hitting kernel revisions that fail due > to other bugs getting merged in during the -rc1 process, etc. Could have a distro-provided mask of things that aren't worth testing and possibly back-ported fixes for revisions in particular ranges. > I agree that a tool that automated the bisection process and walked > the user through it would be helpful, but I believe it would be > possible for us do better. That would probably help for giving the user something to try right away. I still think that the main cost to the user is the number of times that the user has to stop doing stuff to reboot with a kernel to test, whether the test kernels are available quickly from the distro site, slowly built locally, or slowly as suggested by humans helping online. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 14:00, Jörn Engel wrote: And even without mails being held hostage for weeks, every single moderation mail is annoying. Like the one I'm sure to receive after sending this out. Certainly. Upto this thread I wasn't actually aware the list was doing that. While it might be informative once, getting it each time quickly gets old. Don't know if mailman can do anything like it but I'd suggest anyone running a non-subscriber-moderation list configure it to send such messages at most once a per address or some such. And just disable the message if it cannot do that. Fortunately, alsa-devel is (almost) no longer such a list anyway as it's moving to vger. Hurrah. David -- thanks. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
At Thu, 15 Nov 2007 14:17:27 +0100, Olivier Galibert wrote: > > On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > > problem take it up with them but keep ALSA out of it. alsa-devel has only > > ever moderated out spam -- nothing else. > > That is incorrect. Hopefully it is the case now though, since my > experience of the subject was years ago. Yeah, it was really years ago that we once switched to the open list. Funny that people never forget such a thing :) Takashi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. That is incorrect. Hopefully it is the case now though, since my experience of the subject was years ago. OG. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote: > > Can you please just shelve this crap? You have a way of knowing that "ALSA > will accept you" and that is knowing or assuming that the ALSA project > doesn't consist of drooling retards. Well, my experience with moderation has been that moderated mails are stuck in some queue for weeks. Two seperate lists, neither of them was alsa. If also is doing a better job, great. But it still has to live with the general reputation of non-subscriber moderation. > When a project list goes to the difficulty of moderating non-subscribers it > has made the explicit choice to _not_ become subscriber only. Then refusing > valid non-subscribers after all makes no sense whatsoever. I'm sorry you > got your feelings hurt by that other list but it was no doubt an accident; > take it up with them. Been there, done that. In spite of people not being drooling retards, the amount of time and effort they invest into either moderation or improving the ruleset is quite limited. Problems persist. And even without mails being held hostage for weeks, every single moderation mail is annoying. Like the one I'm sure to receive after sending this out. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 13:02, Bron Gondwana wrote: I get the same information from both project websites: "moderated for non-members, public archives" - no way of knowing that ALSA will accept me informing them of something they would be interested without committing to reading or bit-bucketing their list. Can you please just shelve this crap? You have a way of knowing that "ALSA will accept you" and that is knowing or assuming that the ALSA project doesn't consist of drooling retards. When a project list goes to the difficulty of moderating non-subscribers it has made the explicit choice to _not_ become subscriber only. Then refusing valid non-subscribers after all makes no sense whatsoever. I'm sorry you got your feelings hurt by that other list but it was no doubt an accident; take it up with them. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > On 15-11-07 05:16, Bron Gondwana wrote: > >> Totally unrelated - I sent something to the kolab mailing list a couple > > [ ... ] > >> I'm sure if I had something that I considered worth informing the ALSA >> project of, I'd be wary of spending the same effort writing a good post >> knowing it may be dropped in between the by a list moderator just selecing >> all and bouncing them. > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. As an outsider to the list, how do I know what your policy will be other than "I've been rejected out of hand by someone else's list, so my experience is that member only lists aren't willing to listen to something I have to say unless I make the effort to sign up and have yet another folder accumulating unread messages". I don't. Well, ok - maybe I do here since I've let myself be dragged in to the debate. Oops. I get the same information from both project websites: "moderated for non-members, public archives" - no way of knowing that ALSA will accept me informing them of something they would be interested without committing to reading or bit-bucketing their list. The alternative is to subscribe just long enough to send something and then unsubscribe again or cold-email a member and ask them to pass a message along. Or post and hope it doesn't get rejected, not even knowing for a day or so. Bron. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 05:16, Bron Gondwana wrote: Totally unrelated - I sent something to the kolab mailing list a couple [ ... ] I'm sure if I had something that I considered worth informing the ALSA project of, I'd be wary of spending the same effort writing a good post knowing it may be dropped in between the by a list moderator just selecing all and bouncing them. Totally unrelated indeed so why are spouting crap? If the kohab list has a problem take it up with them but keep ALSA out of it. alsa-devel has only ever moderated out spam -- nothing else. ene - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 12:46:24PM +0100, Rene Herman wrote: > On 14-11-07 11:07, David Miller wrote: > > Added Jaroslav and Takashi to the already extensive CC > >> From: Russell King <[EMAIL PROTECTED]> > >>> So, when are you creating a replacement alsa-devel mailing list on >>> vger? That's also subscribers-only. >> The operative term is "alternative" rather than "replacement". >> Perhaps this misunderstanding is what you're so upset about. >> And yes, that alsa list bugs the crap out of me too. I'm more than >> happy to provide an alternative for that one as well. > > [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, > it's _moderated_ for non-subscribers and given that I and other moderators > have been doing our best to moderate quickly (I tend to stay logged in to > the moderation interface all day for example) what specifically bugged the > crap out of you? It's not something a poster needs to concern himself with. Totally unrelated - I sent something to the kolab mailing list a couple of days ago (it's moderated for non subscribers) informing them that I had found the cause of some Cyrus bugs that they had problems with in the past and providing a link to my post to the cyrus list with the patches attached. It sat in the moderation queue and then was rejected with "non subscriber post to subscription only list". Not only was the reponse a day later when I had moved on to other things, but it got me really pissed off that I had put some effort into providing a good quality post that outlined the specific issues and how they applied to their project, and had been summarily dismissed, probably without the effort being put in. There's no way for a non-subscriber to know in advance if the list they are trying to post to will do that to them, completely negating the effort put in to writing something worthwhile to inform that community. It's insular, and it sucks. So yeah, my attitude now is that the Kolab folks can go screw themselves and track down the fix on their own or wait until I've convinced upstream to accept the fixes (likely) and they have moved to the new version (unlikely for a long time, and meanwhile they're missing out on the performance increases that having a more stable skiplist library would give them) I'm sure if I had something that I considered worth informing the ALSA project of, I'd be wary of spending the same effort writing a good post knowing it may be dropped in between the by a list moderator just selecing all and bouncing them. Bron. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tuesday November 13, [EMAIL PROTECTED] wrote: > On Tuesday 13 November 2007 07:08, Mark Lord wrote: > > Ingo Molnar wrote: > > .. > > > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > > it's just that these sorts of things have been largely ignored for > > > years, in favor of the all-too-easy "open source means many eyeballs and > > > that is our QA" answer, which is a _good_ answer but by far not the most > > > intelligent answer! Today "many eyeballs" is simply not good enough and > > > nature (and other OS projects) will route us around if we dont change. > > > > .. > > > > QA-101 and "many eyeballs" are not at all in opposition. > > The latter is how we find out about bugs on uncommon hardware, > > and the former is what we need to track them and overall quality. > > > > A HUGE problem I have with current "efforts", is that once someone > > reports a bug, the onus seems to be 99% on the *reporter* to find > > the exact line of code or commit. Ghad what a repressive method. > > This is the only method that scales. That sounds overly hash, and the rest of you mail sounds much more moderate and sensible - I can only assume you were using hyperbole?? Putting the "onus on the reporter" is simply not going to work unless you have a business relationship. In the community, we are all volunteering our time (well, maybe my employer is volunteering my time to do community support, but the effect is the same). I would hope that the focus of developers is to empower bug reporters to provide further information (and as has been said, "git bisect" is a great empowerer). Some people will be incredibly help, especially if you ask politely and say thankyou. Others won't for any of a number of reasons - and maybe that means their bug won't get fixed. To my eyes, the "only method that scales" is investing effort in encouraging and training bug reporters. Some of that effort might not produce results, but when others among those you have encouraged start answering the newbee questions on the list and save you the time, you get a distinct feeling that it was all worth while. I think we are in agreement - I just wanted to take issue with that one sentence :-) The rest is great. NeilBrown > > Developer has only 24 hours in each day, and sometimes he needs to eat, > sleep, and maybe even pay attention to e.g. his kids. > > But bug reporters are much more numerous and they have more > hours in one day combined. > > BUT - it means that developers should try to increase user base, > not scare users away. > > > And if the "developer" who broke the damn thing, or who at least > > "claims" to be supporting that code, cannot "reproduce" the bug, > > they drop it completely. > > Developer should let reporter know that reporter needs to help > a bit here. Sometimes a bit of hand holding is needed, but it > pays off because you breed more qualified testers/bug reporters. > > > Contrast that flawed approach with how Linus does things.. > > he thinks through the symptoms, matches them to the code, > > and figures out what the few possibilities might be, > > and feeds back some trial balloon patches for the bug reporter to try. > > > > MUCH better. > > > > And remember, *I'm* an old-time Linux kernel developer.. just think about > > the people reporting bugs who haven't been around here since 1992.. > > Yes. Developers should not grow more and more unhelpful > and arrogant towards their users just because inexperienced > users send incomplete/poorly written bug reports. > They need to provide help, not humiliate/ignore. > > I think we agree here. > -- > vda > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wednesday November 14, [EMAIL PROTECTED] wrote: > On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > so please stop this "too busy and too noisy" nonsense already. It was > > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > > what? Deal with it and be intelligent about filtering your information > > > influx instead of imposing a hard pre-filtering criteria that restricts > > > intelligent processing of information. > > > > So you have a preferred method of handling email. Please don't > > force it on the rest of us. > > I'd be curious for any pointers on tools, actually. I "read" (ok, skim) > lkml but still overlook relevant bug reports occasionally. > (Fortunately, between Trond and Andrew and others forwarding things it's > not actually a problem, but I'm still curious). Virtual Folders. I use VM mode in EMACS, but I believe some other mail readers have the same functionality. I have a virtual folder called "nfs" which shows me all mail in my inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject field. When I visit that folder, I see all mail about nfs, whether it was sent to me personally, or to a relevant list, or to lkml. Admittedly if someone doesn't bother to choose a meaningful Subject, then I might miss that. I think this mostly happens when Andrew sends a "-mm" announcement, asked people to change the subject line when following up, and someone follows up without changing the subject line and say "NFS doesn't work any more". I have another virtual folder which matches "md" and "raid" and "mdadm" in any header (so when the people from coraid.com talk about ATA over Ethernet, that gets badly filed, but it is a small cost). Then I have the "bkernel" (boring kernel) folder for all mail from lkml that doesn't mention nfs or raid or md, and isn't from or to me. That folder I skim every week or so and just read the juicy debates and look for interesting tidbits from interesting people - then delete the whole folder, mostly unread. I don't think I could cope with mail without virtual folders. NeilBrown - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007, Theodore Tso wrote: > There are two parts to this. One is a Ubuntu development kernel which > we can give to large numbers of people to expand our testing pool. > But if we don't do a better job of responding to bug reports that > would be generated by expanded testing this won't necessarily help us. > > The other an automated set of standard pre-built bisection points so > that testers can more easily localize a bug down to a few hundred > commits without needing to learn how to use "git bisect" (think Ubuntu > users). I don't see any reason that we couldn't have a tool accessible to Ubuntu users that does a real "git bisect". Git is really good at being scripted by fancy GUIs. It should be easy enough to have a drop down with all of the Ubuntu kernel package releases, where the user selects what works and what doesn't. Then the tool clones a git repository with flags to only get relevant parts, and then leads a bisect run, where it's also configuring, building, and installing the kernels (as a different grub entry), and providing instructions in general. Fundamentally, "git bisect" is a really low-interaction process: you tell it a couple of commits, and then it does stuff, and then you tell it "I tested, and it worked" or "I tested, and it had the problem" or "Something else went wrong", and it asks you something new. Other than that, it just takes time (and a build system hook, which this tool would handle for the kernel). Eventually, it tells you what to report, and you do so. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 21:37:37 +0100 Ingo Molnar wrote: > ok, then you conceded it by not replying to it? good ;-) No, I don't intend to carry on this discussion, but I appreciate the smiley. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007, Ingo Molnar wrote: Dumping even more crap on lkml is not the answer. that "crap" that i'd like to see dumped upon lkml would be netdev traffic mainly - most of the other kernel development lists (and i'm subscribed to many of them) are low-traffic. netdev is the main reason why we cannot do a "one common discussion forum" approach. hmm, how much work would it be to tweak the mail software on vger to have a [EMAIL PROTECTED] that got a copy of any linux-* list hosted by vger. this would solve half the problem (people on linux-kernel not seeing discussions on the other lists) David Lang - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* James Bottomley <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote: > > From: Ingo Molnar <[EMAIL PROTECTED]> > > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > > > In fact this thread is the very example: David points out that on netdev > > > some of those bugs were already discussed and resolved. Had it been all > > > on lkml we'd all be aware of it. > > > > That's a rediculious argument. > > > > One other reason these bugs are resolved, is that the networking > > developers only need to subscribe to netdev and not have to listen > > to all the noise on lkml. > > > > People who want to manage bugs know what list to look on and contact > > about problems. > > > > Dumping even more crap on lkml is not the answer. > > I agree totally with David, and this goes for SCSI too. If it's not > reported on linux-scsi, there's a significant chance of us missing the > bug report. The fact that some people notice bugs go past on LKML and > forward them to linux-scsi is a happy accident and not necessarily > something to rely on. > > LKML has 10-20x the traffic of linux-scsi and a much smaller signal to > noise ratio. Having a specialist list where all the experts in the > field hangs out actually enhances our ability to fix bugs. you are actually proving my point. People have to scan lkml for SCSI regressions _anyway_, because otherwise _you_ would miss them. In the case a user is fortunate enough to realize that a regression is SCSI related, and he is lucky enough to pre-select the SCSI mailing list in the first go, he might get a fix from you. That already reduces the number of useful bugreports by about an order of magnitude. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* David Miller <[EMAIL PROTECTED]> wrote: > From: Ingo Molnar <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > In fact this thread is the very example: David points out that on netdev > > some of those bugs were already discussed and resolved. Had it been all > > on lkml we'd all be aware of it. > > That's a rediculious argument. > > One other reason these bugs are resolved, is that the networking > developers only need to subscribe to netdev and not have to listen to > all the noise on lkml. what noise? If someone really wants networking discussions only, use this procmail rule: :0 HBc * .*net: * sched-patches to separate it into an extra folder and use "net: " as an agreed upon Subject line if you really want to narrow things down. (But there would still be all the other mail just in case the developer has to look at the wider picture. There would be no "I'm only subscribed to netdev" excuse. ) but there should still be one central repository for all kernel discussions - just like there is one central repository for all kernel code. > People who want to manage bugs know what list to look on and contact > about problems. i think that's the problem. Developers (and here i dont mean you) who want to do "development only", without being exposed to the global state of the kernel and without being exposed to bugs. I think that's the basic mindset difference. That is one of the factor that is causing assymetric allocation of developers and the increasing detachment from reality. > Dumping even more crap on lkml is not the answer. that "crap" that i'd like to see dumped upon lkml would be netdev traffic mainly - most of the other kernel development lists (and i'm subscribed to many of them) are low-traffic. netdev is the main reason why we cannot do a "one common discussion forum" approach. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: > > > countered by the underlined sentences above, just in case you missed > > it. > > I didn't miss your claim. ok, then you conceded it by not replying to it? good ;-) Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: > countered by the underlined sentences above, just in case you missed it. I didn't miss your claim. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > > > * Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > > > (and this is in no way directed at the networking folks - it holds > > > > for all of us. I have one main complaint about networking: the > > > > separate netdev list is a bad idea - networking regressions should > > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > > artificial split of the lk discussion space is bad.) > > > > > > but here I disagree. LKML is already too busy and noisy. Major > > > subsystems need their own discussion areas. > > > > That's a stupid argument. We lose much more by forced isolation of > > discussion than what we win by having less traffic! It's _MUCH_ > > easier to narrow down information (by filter by threads, by topics, ^^^ > > by people, etc.) than it is to gobble information together from ^^^ > > various fractured sources. We learned it _again and again_ that ^^^ > > isolation of kernel discussions causes bad things. ^^ > > > > In fact this thread is the very example: David points out that on > > netdev some of those bugs were already discussed and resolved. Had > > it been all on lkml we'd all be aware of it. > > or had been on netdev. countered by the underlined sentences above, just in case you missed it. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote: > From: Ingo Molnar <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > In fact this thread is the very example: David points out that on netdev > > some of those bugs were already discussed and resolved. Had it been all > > on lkml we'd all be aware of it. > > That's a rediculious argument. > > One other reason these bugs are resolved, is that the networking > developers only need to subscribe to netdev and not have to listen to > all the noise on lkml. > > People who want to manage bugs know what list to look on and > contact about problems. > > Dumping even more crap on lkml is not the answer. I agree totally with David, and this goes for SCSI too. If it's not reported on linux-scsi, there's a significant chance of us missing the bug report. The fact that some people notice bugs go past on LKML and forward them to linux-scsi is a happy accident and not necessarily something to rely on. LKML has 10-20x the traffic of linux-scsi and a much smaller signal to noise ratio. Having a specialist list where all the experts in the field hangs out actually enhances our ability to fix bugs. James - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Ingo Molnar <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 15:08:47 +0100 > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. That's a rediculious argument. One other reason these bugs are resolved, is that the networking developers only need to subscribe to netdev and not have to listen to all the noise on lkml. People who want to manage bugs know what list to look on and contact about problems. Dumping even more crap on lkml is not the answer. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 01:24:48PM +, Pavel Machek wrote: > Hi! > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > > > No response from developers > > Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz > problems. nohz=off highres=off fixes more than one suspend problem... > > ...stuff I've seen with NOHZ even without suspend (cursor blinking > irregulary) make me think that nohz perhaps should not be used in > production just yet... It appears that bug 9229 has been solved, and the reporter of that bug now says that: If I unset NO_TZ suspend/resume works. If I set it suspend/resume doesn't works. So I think this guy is now suffering from bug #9275 -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 02:07:06AM -0800, David Miller wrote: > From: Russell King <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 09:55:07 + > > > On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > > > I've created [EMAIL PROTECTED] > > > > By doing so you've just said (implicitly) that you can not tolerate > > someone having a different opinion from your own. > > I created a mailing list on a machine where I provide such services. > > People can choose to use or not use the new list, it is their choice. > > > While I accept *your* right to run *your* lists how you please, you > > are unable to accept *my* right to run *my* lists how I see fit. > > I didn't tell you to take your list down or to run it in some other > way. I didn't tell you to unsubscribe everyone and move them over > to the new list either. I didn't say that you were. > I've provided an alternative, and people can pick and choose how they > see fit. I'm letting natural selection run it's course. Are you > able to cope with the fact that people might not want to use your > list any longer? Perhaps that is what bugs you so much about my > giving people a alternative choice. Absolutely, and if you'd have read my message you'd have seen that I'd said effectively the same thing that you're saying here. Having been flamed for not reading emails properly by AKPM shall I flame you for not reading my emails properly? Oh no, it's merely human to occasionally have such misunderstandings. Unless you're rmk. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Denys Vlasenko wrote: > On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: >> You missed the following in my email: >> "we slowly scare them away due to the many bug reports without any >> reaction." >> >> The problem is that bug reports take time. If you go away from easy >> things like compile errors then even things like describing what does >> no longer work, ideally producing a scenario where you can reproduce it >> and verifying whether it was present in previous kernels can easily take >> many hours that are spent before the initial bug report. >> >> If the bug report then gets ignored we discourage the person who sent >> the bug report to do any work related to the kernel again. > > Cannot agree more. I am in a similar position right now. > My patch to aic7xxx driver was ubmitted four times > with not much reaction from scsi guys. > > Finally they replied and asked to rediff it against their > git tree. I did that and sent patches back. No reply since then. > > And mind you, the patch is not trying to do anything > complex, it mostly moves code around, removes 'inline', > adds 'const'. What should I think about it? this has nothing to do with the bugs on bugzilla. you're trying to send a janitor patch. It should be logical that the response to that is not heated or receiving a joyous reception :) If you have a problem getting your cleanup patch to the driver maintainer, send it to the subsystem maintainer instead, or even the janitors, or even Adrian Bunk who will gladly push it to everyone. Or, even to Andrew Morton who will carry it in -mm for a while and then harrasses the subsystem maintainer to merge it for you! Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > so please stop this "too busy and too noisy" nonsense already. It was > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > what? Deal with it and be intelligent about filtering your information > > influx instead of imposing a hard pre-filtering criteria that restricts > > intelligent processing of information. > > So you have a preferred method of handling email. Please don't > force it on the rest of us. I'd be curious for any pointers on tools, actually. I "read" (ok, skim) lkml but still overlook relevant bug reports occasionally. (Fortunately, between Trond and Andrew and others forwarding things it's not actually a problem, but I'm still curious). --b. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > * Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > (and this is in no way directed at the networking folks - it holds > > > for all of us. I have one main complaint about networking: the > > > separate netdev list is a bad idea - networking regressions should > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > artificial split of the lk discussion space is bad.) > > > > but here I disagree. LKML is already too busy and noisy. Major > > subsystems need their own discussion areas. > > That's a stupid argument. We lose much more by forced isolation of > discussion than what we win by having less traffic! It's _MUCH_ easier > to narrow down information (by filter by threads, by topics, by people, > etc.) than it is to gobble information together from various fractured > sources. We learned it _again and again_ that isolation of kernel > discussions causes bad things. > > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. or had been on netdev. > this is a single kernel project that is released together as one > codebase, so a central place of discussion is obvious and common-sense. Central doesn't have to mean one-and-only-one-list-for-everything. > so please stop this "too busy and too noisy" nonsense already. It was > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > grew from a 1 million lines codebase to an 8 million lines codebase, so > what? Deal with it and be intelligent about filtering your information > influx instead of imposing a hard pre-filtering criteria that restricts > intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'll plan to use lkml-list-only when you have convinced DaveM to drop all of the other mailing lists at vger.kernel.org. Yeah, sure. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Ingo Molnar wrote: > * Mark Lord <[EMAIL PROTECTED]> wrote: > >>> You're assuming that everything in linux-2.6 was downloaded; that's >>> not true. Everything in linux-2.6/.git was downloaded; but then you >>> do a checkout which happens to approximately double the size of the >>> linux-2.6 directory. >> .. >> >> Ah, I wondered why it took only half an hour to download. > > and you can get even lower than the 260MB by downloading a shallow clone > of v2.6.23 and then populating the git tree from tht point on. (see the > --depth parameter of git-clone) [because most of the time you want to > bisect back to the last stable release, not back to 2 years of git > history.] When creating additional git trees (Linville's wireless-2.6 tree, for example) for driver development, you can save a lot of download bandwidth by using the --reference parameter of git-clone. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Mark Lord <[EMAIL PROTECTED]> wrote: >> You're assuming that everything in linux-2.6 was downloaded; that's >> not true. Everything in linux-2.6/.git was downloaded; but then you >> do a checkout which happens to approximately double the size of the >> linux-2.6 directory. > .. > > Ah, I wondered why it took only half an hour to download. and you can get even lower than the 260MB by downloading a shallow clone of v2.6.23 and then populating the git tree from tht point on. (see the --depth parameter of git-clone) [because most of the time you want to bisect back to the last stable release, not back to 2 years of git history.] Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
FWIW, I see the same problem with another HP notebook, DV4378EA with radeon X700 video card. It does not happen frequently but I can say that since I disabled the tickless feature I can't reproduce the problem anymore. On Nov 14, 2007 2:24 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > > > No response from developers > > Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz > problems. nohz=off highres=off fixes more than one suspend problem... > > ...stuff I've seen with NOHZ even without suspend (cursor blinking > irregulary) make me think that nohz perhaps should not be used in > production just yet... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Randy Dunlap <[EMAIL PROTECTED]> wrote: > > (and this is in no way directed at the networking folks - it holds > > for all of us. I have one main complaint about networking: the > > separate netdev list is a bad idea - networking regressions should > > be discussed and fixed on lkml, like most other subsystems are. Any > > artificial split of the lk discussion space is bad.) > > but here I disagree. LKML is already too busy and noisy. Major > subsystems need their own discussion areas. That's a stupid argument. We lose much more by forced isolation of discussion than what we win by having less traffic! It's _MUCH_ easier to narrow down information (by filter by threads, by topics, by people, etc.) than it is to gobble information together from various fractured sources. We learned it _again and again_ that isolation of kernel discussions causes bad things. In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. this is a single kernel project that is released together as one codebase, so a central place of discussion is obvious and common-sense. so please stop this "too busy and too noisy" nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Hi! > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > Kernel: 2.6.23 > > This is HP notebook nc6320 T2400 945GM > > No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moderated list (Was: Re: [BUG] New Kernel Bugs)
At Wed, 14 Nov 2007 13:21:30 +0100,
Rene Herman wrote:
>
> On 14-11-07 09:25, Takashi Iwai wrote:
>
> > At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
> > David Miller wrote:
> >> From: David Miller <[EMAIL PROTECTED]>
> >> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
> >>
> >>> The fact that it farts at me every time I post to this thread.
> >> See? I got another one and I have received at least 10 of the
> >> following over the past 2 days.
> >>
> >> That's rediculious.
> >>
> >> And because a human adds the whitelist this is always going to
> >> happen to someone when they start posting to the alsa list for
> >> the first time.
> >
> > ... if you give too many recipients in your post. That is often
> > really annoying thing to me, together with keeping the unrelated
> > subject line ;)
> >
> > I personally don't care whether it's a moderated or open list.
> > We chose it simply due to too bad S/N ratio at that time. So, if the
> > current list annoys your or many others and the list management on
> > vger is so good, it'd be basically a good move, of course. I'll
> > appreciate it.
> >
> > The only confusion would be the change of ML address, but we can do it
> > slowly, too.
>
> I'd love the lists at vger. Amazing spam-filtering. I'd like to request the
> name [EMAIL PROTECTED] (and [EMAIL PROTECTED] if at all
> possible so we can open that one up as well) though.
I think alsa-user can stay as is. It's no place for dragging many
other addresses like alsa-devel.
BTW, I also prefer keeping the name [EMAIL PROTECTED] It's been so.
> There wouldn't need to be a forced ML address change if Jaroslov would then
> just rewrite alsa-{devel,[EMAIL PROTECTED] to vger.kernel.org same as
> he did for alsa-devel and does for alsa-user to @lists.sf.net.
If it works, then I'm for it, too.
thanks,
Takashi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Matthew Wilcox wrote: > On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: >> Finally they replied and asked to rediff it against their >> git tree. I did that and sent patches back. No reply since then. >> >> And mind you, the patch is not trying to do anything >> complex, it mostly moves code around, removes 'inline', >> adds 'const'. What should I think about it? > > I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I > do? > I haven't actually been able to test it here (too busy, sorry). If someone else confirms it does it's job then Acked-by: Hannes Reinecke <[EMAIL PROTECTED]> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: > Finally they replied and asked to rediff it against their > git tree. I did that and sent patches back. No reply since then. > > And mind you, the patch is not trying to do anything > complex, it mostly moves code around, removes 'inline', > adds 'const'. What should I think about it? I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I do? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 13:01, David Miller wrote: From: David Miller <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) The fact that it farts at me every time I post to this thread. See? I got another one and I have received at least 10 of the following over the past 2 days. Nah, in this case you are not even getting them to not being a non-subcriber but due to too many CCs. I got one as well. That just needs to be disabled, does not have anything to do with non-subscribers (and you're in the white list) but is just a retarted bit of list configuration... (no, I can't personally change it, needs Jaroslav Kysela) Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 12:56, David Miller wrote: From: Rene Herman <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 12:46:24 +0100 [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. The fact that it farts at me every time I post to this thread. That's rude and annoying. It certainly is. I only experienced that now due to the "too many recipients to message" moderation notice that I got from my own message. Jaroslav -- please disable that junk or if possible, make it a "at most once per address per month" thing or somesuch. This is complete crap. Also for alsa-devel the moderators tend to add any valid non-subcribers to a whitelist after landing in the queue the first time meaning even a delay is just a one-time thing normally. So what's the trouble? Basically, noone need even notice... That sucks for new people taking part in the conversation. There is no reason for moderation at all, it isn't necessary for spam prevention and it does nothing but annoy new posters and make work for the moderator. Yes there is. It's necessary for lists that do not have the human and other resouces behind it that vger does. alsa-devel was drowning in spam and dying as a result back when it was at sourceforge. Upon moving, my preference was to ask the lists to be hosted at vger but given that (it seems) Jaroslav wanted to keep them locally, moderation was very necessary. I moderate out quite a bit of spam every day. vger is doing an amazing job at spam filtering -- if it's an option to move to vger, than sure, no need. But otherwise, the "no need" needs a list admin with enough bandwidth and skill. As to the "new people": it's not optimal, but (upto this thread I'll admit -- I woke up to a huge number of posts in the queue) it's not been a _real_ problem. alsa-devel is not high-volume enough for it to be. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007, Andrew Morton wrote: > > HID > > > > Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc > > http://bugzilla.kernel.org/show_bug.cgi?id=9216 > > Kernel: 2.6.23.1 > > Looks like this is a regression > No response from developers Hi, it is assigned to '[EMAIL PROTECTED]', so I didn't notice, it's as simple as that. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moderated list (Was: Re: [BUG] New Kernel Bugs)
On 14-11-07 09:25, Takashi Iwai wrote:
At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
David Miller wrote:
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at least 10 of the
following over the past 2 days.
That's rediculious.
And because a human adds the whitelist this is always going to
happen to someone when they start posting to the alsa list for
the first time.
... if you give too many recipients in your post. That is often
really annoying thing to me, together with keeping the unrelated
subject line ;)
I personally don't care whether it's a moderated or open list.
We chose it simply due to too bad S/N ratio at that time. So, if the
current list annoys your or many others and the list management on
vger is so good, it'd be basically a good move, of course. I'll
appreciate it.
The only confusion would be the change of ML address, but we can do it
slowly, too.
I'd love the lists at vger. Amazing spam-filtering. I'd like to request the
name [EMAIL PROTECTED] (and [EMAIL PROTECTED] if at all
possible so we can open that one up as well) though.
There wouldn't need to be a forced ML address change if Jaroslov would then
just rewrite alsa-{devel,[EMAIL PROTECTED] to vger.kernel.org same as
he did for alsa-devel and does for alsa-user to @lists.sf.net.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Moderated list (Was: Re: [BUG] New Kernel Bugs)
At Wed, 14 Nov 2007 04:01:31 -0800 (PST), David Miller wrote: > > From: David Miller <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > > > The fact that it farts at me every time I post to this thread. > > See? I got another one and I have received at least 10 of the > following over the past 2 days. > > That's rediculious. > > And because a human adds the whitelist this is always going to > happen to someone when they start posting to the alsa list for > the first time. ... if you give too many recipients in your post. That is often really annoying thing to me, together with keeping the unrelated subject line ;) I personally don't care whether it's a moderated or open list. We chose it simply due to too bad S/N ratio at that time. So, if the current list annoys your or many others and the list management on vger is so good, it'd be basically a good move, of course. I'll appreciate it. The only confusion would be the change of ML address, but we can do it slowly, too. Takashi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
> The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at least 10 of the
following over the past 2 days.
That's rediculious.
And because a human adds the whitelist this is always going to
happen to someone when they start posting to the alsa list for
the first time.
/me gets ready for the 11th copy in response to this one...
Subject: Your message to Alsa-devel awaits moderator approval
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 12:57:06 +0100
Sender: [EMAIL PROTECTED]
Your mail to 'Alsa-devel' with the subject
Re: [alsa-devel] [BUG] New Kernel Bugs
Is being held until the list moderator can review it for approval.
The reason it is being held:
Too many recipients to the message
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
http://mailman.alsa-project.org/mailman/confirm/alsa-devel/12dd3bd077bbf9cd142f214beae6d22ae43b53aa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
From: Rene Herman <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 12:46:24 +0100 > [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, > it's _moderated_ for non-subscribers and given that I and other moderators > have been doing our best to moderate quickly (I tend to stay logged in to > the moderation interface all day for example) what specifically bugged the > crap out of you? It's not something a poster needs to concern himself with. The fact that it farts at me every time I post to this thread. That's rude and annoying. > Also for alsa-devel the moderators tend to add any valid non-subcribers to > a whitelist after landing in the queue the first time meaning even a delay > is just a one-time thing normally. So what's the trouble? Basically, noone > need even notice... That sucks for new people taking part in the conversation. There is no reason for moderation at all, it isn't necessary for spam prevention and it does nothing but annoy new posters and make work for the moderator. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 11:07, David Miller wrote: Added Jaroslav and Takashi to the already extensive CC From: Russell King <[EMAIL PROTECTED]> So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. The operative term is "alternative" rather than "replacement". Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. Also for alsa-devel the moderators tend to add any valid non-subcribers to a whitelist after landing in the queue the first time meaning even a delay is just a one-time thing normally. So what's the trouble? Basically, noone need even notice... In fact, *poof*, there it is, [EMAIL PROTECTED] is there and available for anyone who wants to use it. Not that I think that moving alsa-devel over to vger wouldn't be a good idea mind you; when the list moved from sourceforge, asking you to host it was my preferred option. I do somewhat suspect that Jaroslav would like to keep the alsa-devel@ name (and I'd like to ask you to then also host alsa-user@) and would then rewrite mail to those lists @alsa-project.org to vger. But what is the problem you speak of with the alsa-devel list? While I would not mind loosing it, moderation hasn't been overly laborious and I'm not aware of any serious problems. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Russell King <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 09:55:07 + > On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > > I've created [EMAIL PROTECTED] > > By doing so you've just said (implicitly) that you can not tolerate > someone having a different opinion from your own. I created a mailing list on a machine where I provide such services. People can choose to use or not use the new list, it is their choice. > While I accept *your* right to run *your* lists how you please, you > are unable to accept *my* right to run *my* lists how I see fit. I didn't tell you to take your list down or to run it in some other way. I didn't tell you to unsubscribe everyone and move them over to the new list either. I've provided an alternative, and people can pick and choose how they see fit. I'm letting natural selection run it's course. Are you able to cope with the fact that people might not want to use your list any longer? Perhaps that is what bugs you so much about my giving people a alternative choice. > So, when are you creating a replacement alsa-devel mailing list on > vger? That's also subscribers-only. The operative term is "alternative" rather than "replacement". Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. In fact, *poof*, there it is, [EMAIL PROTECTED] is there and available for anyone who wants to use it. Have a nice day Russell. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 14:32:01 -0800 > > > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > Russell doesn't have to worry any more, he doesn't have to > host it, and he doesn't have to be willing to run a > non-subscribers-only mailing list. > > Because I am. > > I've created [EMAIL PROTECTED] By doing so you've just said (implicitly) that you can not tolerate someone having a different opinion from your own. While I accept *your* right to run *your* lists how you please, you are unable to accept *my* right to run *my* lists how I see fit. Time will tell which lists will survive. Whatever, I suspect that by doing what you've just done, you're going to create more confusion and problems. Instead of having one focused place for discussions and bug reports, they're going to be spread more thinly, meaning less people looking at such things, meaning more bugs get ignored. Thus making the issue worse. So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 06:27:00PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <[EMAIL PROTECTED]> > wrote: > > > I've created [EMAIL PROTECTED] > > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? > > Martin's changed the owner for ARM bugs last night to the mailing list so the whole issue is now redundant. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: > You missed the following in my email: > "we slowly scare them away due to the many bug reports without any > reaction." > > The problem is that bug reports take time. If you go away from easy > things like compile errors then even things like describing what does > no longer work, ideally producing a scenario where you can reproduce it > and verifying whether it was present in previous kernels can easily take > many hours that are spent before the initial bug report. > > If the bug report then gets ignored we discourage the person who sent > the bug report to do any work related to the kernel again. Cannot agree more. I am in a similar position right now. My patch to aic7xxx driver was ubmitted four times with not much reaction from scsi guys. Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? -- vda - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 05:39:45PM -0700, Denys Vlasenko wrote: > On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > > (gentoo->ubuntu) > > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > > know this isn't a lkml problem > > > > but more a distro problem, but I would love having an ubuntu blessed > > > > repo with current dev kernel > > > > for the latest stable ubuntu release). > > > > > > There are two parts to this. One is a Ubuntu development kernel which > > > we can give to large numbers of people to expand our testing pool. > > > But if we don't do a better job of responding to bug reports that > > > would be generated by expanded testing this won't necessarily help us. > > >... > > > > The main problem aren't missing testers [1] - we already have relatively > > experienced people testing kernels and/or reporting bugs, and we slowly > > scare them away due to the many bug reports without any reaction. > > > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > > > Getting many relatively unexperienced users (who need more guidance for > > debugging issues) as additional testers is therefore IMHO not > > necessarily a good idea. > > And where experienced developrs are coming from? > They are not born with Linux kernel skills. > They grow up from within user base. > > Bigger user base -> more developers (eventually) You missed the following in my email: "we slowly scare them away due to the many bug reports without any reaction." The problem is that bug reports take time. If you go away from easy things like compile errors then even things like describing what does no longer work, ideally producing a scenario where you can reproduce it and verifying whether it was present in previous kernels can easily take many hours that are spent before the initial bug report. If the bug report then gets ignored we discourage the person who sent the bug report to do any work related to the kernel again. > vda cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 06:56:06 +0100 > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have [EMAIL PROTECTED] for zero > overhead for you. I already did, get a little deeper in your mailbox before replying :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 06:56:06AM +0100, Sam Ravnborg wrote: > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have [EMAIL PROTECTED] for zero > overhead for you. And in a later mail I saw davem already created it. Sam - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
> > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. The postmasters at vger is pretty good at running mailing lists. For linux-kbuild my effort so far has been to request it. Thats not a big deal. So if they accept it you could have [EMAIL PROTECTED] for zero overhead for you. Sam - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 18:27:00 -0800 > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? Matti gets all the credit for setting up the bayesian et al. filters we have and training it as needed. > Yes, sourceforge is a complete joke. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > I've created [EMAIL PROTECTED] Let me just say - I'm astonished at how little spam gets though the vger lists. Considering how many times those email addresses must have been added to spam databases. It must be a lot of work, and whoever is doing it does it well. I don't even know. Is it Matti? You? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:11:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Tue, 13 Nov 2007 19:52:17 -0500 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > On 11/13/2007 04:12 PM, Alan Cox wrote: > > >> Bug fixing is not about finding someone to blame, it's about getting the > > >> bug fixed. > > > > > > Partly - its also about understanding why the bug occurred and making it > > > not happen again. > > > > Very few people think about that part. > > Why does the kernel have very few useful tests? Tests would of course be nice, but they aren't very useful(!) Looking at this list which Natalie has generated I see around thirty which are dependent on the right hardware and ten which are not. This ratio is typical, I think. In fact I'd say that more than 75% of reported bugs are dependent on hardware. So the best test of all for the kernel is "run it on a different machine". This is why we are so dependent upon our volunteer testers/reporters to be able to do kernel development. > Lack of interest? resources? expertise? > Ideally each new feature would just be a small add on to an existing test. Sure. For system-call-visible features it would be good to do that. But this tends not to be where bugs get exposed. Because the original developer can 100% exercise such code. That isn't the case with driver/arch/platform changes. > Unlike developing new features which seems to grow well with more developers. > Bug fixing also seems to be a scarcity process. There often seems to be > a very few people that understand the problem well enough or have the > necessary > hardware to reproduce and fix the problem. We're 100% dead if "having the hardware" is a prerequisite to fixing a bug. The terminal state there is that the kernel runs on about 200 machines worldwide. We have to work with reporters via email to fix these sorts of things. As we of course do. > Recent changes like tickless and scheduler rework were well thought out and > caused > very little impact to 90% of the users. The problem is the 10% who do have > problems. > Worse, the developers often only hear about the a small sample of those. Yes. An unknown number of people just shrug and go back to an old kernel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Russell King <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 23:40:33 + > ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function > '__netif_rx_schedule_prep' > > caused by: [NET]: Make NAPI polling independent of struct net_device objects. > > ARM netx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': > drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this > function) > drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported > only once > drivers/net/netx-eth.c:131: error: for each function it appears in.) > drivers/net/netx-eth.c: In function 'netx_eth_receive': > drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this > function) > > caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink > code > I'll fix these up, thanks for the report. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 14:32:01 -0800 > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > Making a list subscribers-only will cause some bug reports to be lost. > > Tradeoffs are involved, against which decisions must be made. You have > made yours. Russell doesn't have to worry any more, he doesn't have to host it, and he doesn't have to be willing to run a non-subscribers-only mailing list. Because I am. I've created [EMAIL PROTECTED] Enjoy. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 19:52:17 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 11/13/2007 04:12 PM, Alan Cox wrote: > >> Bug fixing is not about finding someone to blame, it's about getting the > >> bug fixed. > > > > Partly - its also about understanding why the bug occurred and making it > > not happen again. > > Very few people think about that part. Why does the kernel have very few useful tests? Lack of interest? resources? expertise? Ideally each new feature would just be a small add on to an existing test. Unlike developing new features which seems to grow well with more developers. Bug fixing also seems to be a scarcity process. There often seems to be a very few people that understand the problem well enough or have the necessary hardware to reproduce and fix the problem. Recent changes like tickless and scheduler rework were well thought out and caused very little impact to 90% of the users. The problem is the 10% who do have problems. Worse, the developers often only hear about the a small sample of those. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 13:18:43 -0500 > Mind you, no arguing that this is effective when that poor bloke has > a day free to download the git-tree and build/reboot a dozen times. Like the internet, this time spent is beneficial because it's pushing the work out to the end nodes. In fact git bisect is an awesome example of the end node principle in action for software development and QA. For the end-user wanting their bug fixed and the developer it's a win win situation because the reporter is actually able to do something proactive which will help get the bug they want fixed faster. So I don't agree with framing this person as a "poor bloke". Our testers are more empowered than ever to lead the process towards a fix. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On 11/13/2007 04:12 PM, Alan Cox wrote: >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > > Partly - its also about understanding why the bug occurred and making it > not happen again. Very few people think about that part. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 11:57, Gabriel C wrote: > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > There are already. IMO the problem is the development model. > > There are tons new features in each new kernel release and 'tons new bugs' > which are not fixed during the release cycle nor in the .XX stable kernels. > > Maybe after XX kernel releases there should be one just with bug-fixes > _without_ any new features , eg: cleaning bugs from bugzilla , know > regressions , cleaning up code , removing broken drivers and the like. Won't work. You cannot force people to work on things they don't find interesting, long-term. -- vda - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > (gentoo->ubuntu) > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > know this isn't a lkml problem > > > but more a distro problem, but I would love having an ubuntu blessed > > > repo with current dev kernel > > > for the latest stable ubuntu release). > > > > There are two parts to this. One is a Ubuntu development kernel which > > we can give to large numbers of people to expand our testing pool. > > But if we don't do a better job of responding to bug reports that > > would be generated by expanded testing this won't necessarily help us. > >... > > The main problem aren't missing testers [1] - we already have relatively > experienced people testing kernels and/or reporting bugs, and we slowly > scare them away due to the many bug reports without any reaction. > > The main problem is finding experienced developers who spend time on > looking into bug reports. > > Getting many relatively unexperienced users (who need more guidance for > debugging issues) as additional testers is therefore IMHO not > necessarily a good idea. And where experienced developrs are coming from? They are not born with Linux kernel skills. They grow up from within user base. Bigger user base -> more developers (eventually) -- vda - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 07:08, Mark Lord wrote: > Ingo Molnar wrote: > .. > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. This is the only method that scales. Developer has only 24 hours in each day, and sometimes he needs to eat, sleep, and maybe even pay attention to e.g. his kids. But bug reporters are much more numerous and they have more hours in one day combined. BUT - it means that developers should try to increase user base, not scare users away. > And if the "developer" who broke the damn thing, or who at least > "claims" to be supporting that code, cannot "reproduce" the bug, > they drop it completely. Developer should let reporter know that reporter needs to help a bit here. Sometimes a bit of hand holding is needed, but it pays off because you breed more qualified testers/bug reporters. > Contrast that flawed approach with how Linus does things.. > he thinks through the symptoms, matches them to the code, > and figures out what the few possibilities might be, > and feeds back some trial balloon patches for the bug reporter to try. > > MUCH better. > > And remember, *I'm* an old-time Linux kernel developer.. just think about > the people reporting bugs who haven't been around here since 1992.. Yes. Developers should not grow more and more unhelpful and arrogant towards their users just because inexperienced users send incomplete/poorly written bug reports. They need to provide help, not humiliate/ignore. I think we agree here. -- vda - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 03:18:07PM -0500, Mark Lord wrote: > Russell King wrote: > > On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: > >> Ingo Molnar wrote: > >> .. > >>> This is all QA-101 that _cannot be argued against on a rational basis_, > >>> it's just that these sorts of things have been largely ignored for > >>> years, in favor of the all-too-easy "open source means many eyeballs and > >>> that is our QA" answer, which is a _good_ answer but by far not the most > >>> intelligent answer! Today "many eyeballs" is simply not good enough and > >>> nature (and other OS projects) will route us around if we dont change. > >> .. > >> > >> QA-101 and "many eyeballs" are not at all in opposition. > >> The latter is how we find out about bugs on uncommon hardware, > >> and the former is what we need to track them and overall quality. > >> > >> A HUGE problem I have with current "efforts", is that once someone > >> reports a bug, the onus seems to be 99% on the *reporter* to find > >> the exact line of code or commit. Ghad what a repressive method. > > > > 99% on the reporter? Is that why I always try to understand the > > reporters problem (*provided* it's in an area I know about) and come > > up with a patch to test a theory or fix the issue? > .. > > Same here. > > I just find it weird that something can be known broken for several -rc* > kernels before I happen to install it, discover it's broken on my own machine, > and then I track it down, fix it, and submit the patch, generally all within a > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. Same thing can be said for compile breakages as well. Looking at the latest kautobuild output: ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function '__netif_rx_schedule_prep' caused by: [NET]: Make NAPI polling independent of struct net_device objects. ARM netx defconfig has been broken since 2.6.23-git1 due to: drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this function) drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported only once drivers/net/netx-eth.c:131: error: for each function it appears in.) drivers/net/netx-eth.c: In function 'netx_eth_receive': drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this function) caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink code Haven't got a report for either of those, but Kautobuild lets people know if folk can be bothered to subscribe to its mailing list and/or look at the site occasionally. I suspect the maintainers of the above drivers aren't aware that their drivers are broken. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:29:54 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: > > >... > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > >... > > > > What about having all ARM bugs in Bugzilla by default assigned to > > [EMAIL PROTECTED] [1] > > That would also work, probably much better than setting up yet another > list. cpufreq (at least) does it this way. I don't know how well it is turning out in practice. It's useful if the initial report makes it clear (ie; to me) that the report has already gone to a mailing list so I don't go and forward a duplicate. But there are so few arm reports in bugzilla that this is all rather moot. > My experience of trying to get mbligh to do this when I stopped looking > after PCMCIA stuff was *extremely* painful. Wonder if it's become any > easier of late? He's a bad, bad man ;) But he's been turning these things around pretty rapidly lately. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <[EMAIL PROTECTED]> wrote: .. with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't boot (ARM, Timer) http://bugzilla.kernel.org/show_bug.cgi?id=9229 Kernel: 2.6.23 No response from developers .. The bug report is bogus. ARM has no CONFIG_HPET_TIMER. Note: that same bug exists/existed on i386 back when NO_HZ was introduced (2.6.21?). I still see it from time to time on my Quad core system (very rare), but not any more on my Duo notebook where it used to happen about 1 in n boots (n < 10). AFAICT no fix was ever released for it. Hmm, at which point does the boot stop ? .. Just as it prints out these messages, sometimes one of them, sometimes both (or all four on the quad core): kernel: switched to high resolution mode on cpu 1 kernel: switched to high resolution mode on cpu 0 It's completely dead afterwards ? Yeah. No magic sysrq key or anything. There's gotta be a race somewhere that's causing it, but it's not obvious where to look for it. My regular 2-core notebook no longer suffers from it, and subtle .config changes used to make it come and go back when it first appeared. The quad-core has only done it twice on me thus far. Tracking this one down looks tricky. It might require some early lockup detection code to be tailor made or something. Cheers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: > >... > > There's another issue I want to raise concerning bugzilla. We have the > > classic case of "not enough people reading bugzilla bugs" - which is one > > of the biggest problems with bugzilla. Virtually no one in the ARM > > community looks for ARM bugs in bugzilla. > > > > Let's not forget that it would be a waste of time for people to manually > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > into bugzilla that a weekly manual check by every maintainer would just > > return the same old boring results for months and months at a time. > >... > > What about having all ARM bugs in Bugzilla by default assigned to > [EMAIL PROTECTED] [1] That would also work, probably much better than setting up yet another list. My experience of trying to get mbligh to do this when I stopped looking after PCMCIA stuff was *extremely* painful. Wonder if it's become any easier of late? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:09:37 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > > > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> > > > > wrote: > > No, I don't mean that at all and this was very plainly obviously from my > > very > > clearly written email. Let me try again. > > If you screen all bugzilla reports then you'll know that bug #9356 arrived > at about 1400 GMT yesterday. It's hardly surprising then that your utterly > crappy responses to Natalie's message (which, incidentally, wasn't copied > to me) sent within 24 hours of that report cause *great* annoyance. > > > No, no subsystem developer needs to monitor new bugzilla reports. This is > > because *I do it for them*. I will actively make them aware of new reports > > which I believe are legitimate and which contain sufficient information for > > them to be able to take further action. > > On the whole you do an excellent job with feeding the bug reports to > people, and while I recognise that you're only human, things do > occasionally go wrong. For instance, sending clearly marked Samsung > S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those > platforms.) Well whatever, sorry. But this is in the noise floor. Point is: many bug reports aren't being attended to. > > > > > It would be far more productive if the ARM category was deleted from > > > > > bugzilla and the few people who use bugzilla reported their bugs on > > > > > the > > > > > mailing list. We've a couple of thousand people on the ARM kernel > > > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > > > than look at bugzilla. > > > > > > > > Is that [EMAIL PROTECTED] > > > > > > Yes. > > > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > > some bug reporters to give up and go away. > > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > So how are they lost when they're held in a moderation queue and are > either accepted, a useful response given to the original poster, or > are forwarded to someone who can deal with the issue. > > I don't think "subscribers only" describes my lists - we don't devnull > stuff just because the poster is not a subscriber. Oh, OK, as long as there really is a human paying attention to those things then that's fine. When one is on the sending end of these things one never knows how long it will take, not whether it will even happen. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > > > > There's another issue I want to raise concerning bugzilla. We have the > > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > > community looks for ARM bugs in bugzilla. > > > > > > Nor should they. > > > > So what you're saying is... > > > > > > Let's not forget that it would be a waste of time for people to manually > > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > > into bugzilla that a weekly manual check by every maintainer would just > > > > return the same old boring results for months and months at a time. > > > > > > I screen all bugzilla reports. 100% of them. > > > > > > - I'll try to establish whether it is a regression > > > > > > - I'll solicit any extra information which I believe the reveloper will > > > need > > > > > > - I'll ensure that an appropriate developer has seen the report > > > > > > And yes, the number of arm-specific reports in there is very small. > > > > that just because you do this everyone in a select clique, who you include > > me in, should be doing this as well. > > > > No. Thank. You. > > No, I don't mean that at all and this was very plainly obviously from my very > clearly written email. Let me try again. If you screen all bugzilla reports then you'll know that bug #9356 arrived at about 1400 GMT yesterday. It's hardly surprising then that your utterly crappy responses to Natalie's message (which, incidentally, wasn't copied to me) sent within 24 hours of that report cause *great* annoyance. > No, no subsystem developer needs to monitor new bugzilla reports. This is > because *I do it for them*. I will actively make them aware of new reports > which I believe are legitimate and which contain sufficient information for > them to be able to take further action. On the whole you do an excellent job with feeding the bug reports to people, and while I recognise that you're only human, things do occasionally go wrong. For instance, sending clearly marked Samsung S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those platforms.) > > > > It would be far more productive if the ARM category was deleted from > > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > > mailing list. We've a couple of thousand people on the ARM kernel > > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > > than look at bugzilla. > > > > > > Is that [EMAIL PROTECTED] > > > > Yes. > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > Making a list subscribers-only will cause some bug reports to be lost. > > Tradeoffs are involved, against which decisions must be made. You have > made yours. So how are they lost when they're held in a moderation queue and are either accepted, a useful response given to the original poster, or are forwarded to someone who can deal with the issue. I don't think "subscribers only" describes my lists - we don't devnull stuff just because the poster is not a subscriber. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007, Mark Lord wrote: > Thomas Gleixner wrote: > > On Tue, 13 Nov 2007, Mark Lord wrote: > > > > > > Andrew Morton wrote: > > > > > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" > > > > > > <[EMAIL PROTECTED]> wrote: > > > > .. > > > > > > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 > > > > > doesn't > > > > > > > > boot (ARM, Timer) > > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > > > > > > > Kernel: 2.6.23 > > > > > > > > No response from developers > > > > .. > > > > The bug report is bogus. ARM has no CONFIG_HPET_TIMER. > > > > Note: that same bug exists/existed on i386 back when NO_HZ was > > > > introduced (2.6.21?). I still see it from time to time on my Quad core > > > > system (very rare), but not any more on my Duo notebook where it used > > > > to happen about 1 in n boots (n < 10). > > > > > AFAICT no fix was ever released for it. > > > > Hmm, at which point does the boot stop ? > .. > > Just as it prints out these messages, sometimes one of them, > sometimes both (or all four on the quad core): > > kernel: switched to high resolution mode on cpu 1 > kernel: switched to high resolution mode on cpu 0 It's completely dead afterwards ? tglx - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:24:14 +0100 Jörn Engel <[EMAIL PROTECTED]> wrote: > On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote: > > > > It's relatively common that a regression in subsystem A will manifest as a > > failure in subsystem B, and the report initially lands on the desk of the > > subsystem B developers. > > > > But that's OK. The subsystem B people are the ones with the expertise to > > be able to work out where the bug resides and to help the subsystem A > > people understand what went wrong. > > > > Alas, sometimes the B people will just roll eyes and do nothing because > > they know the problem wasn't in their code. Sometimes. > > And sometimes the A people will ignore the B people after the root cause > has been worked out. Do you have a good idea how to shame A into > action? Should I put you on Cc:? Right now I'm in the eye-rolling > phase. > Well, that's the problem, isn't it? The best I can come up with is to suggest that all the info be captured in a bugzilla report so that at least it doesn't get forgotten about. I suppose that other options are a) try to fix it yourself. I'll take the patch and as long as we make a big enough mess of it, someone who knows what they're doing might fix it for real. b) If it was a regression, identify the offending commit and we'll just revert it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 06:25:16PM +, Alan Cox wrote: > > Given the wide range of ARM platforms today, it is utterly idiotic to > > expect a single person to be able to provide responses for all ARM bugs. > > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > > bugzilla, and really *WISH* I could pull out of that function. > > You can. Perhaps that bugzilla needs to point to some kind of > [EMAIL PROTECTED] list for the various ARM platform > maintainers ? That might work - though it would be hard to get all the platform maintainers to be signed up to yet another mailing list, I'm sure sufficient would do. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > Nor should they. > > So what you're saying is... > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > > > I screen all bugzilla reports. 100% of them. > > > > - I'll try to establish whether it is a regression > > > > - I'll solicit any extra information which I believe the reveloper will need > > > > - I'll ensure that an appropriate developer has seen the report > > > > And yes, the number of arm-specific reports in there is very small. > > that just because you do this everyone in a select clique, who you include > me in, should be doing this as well. > > No. Thank. You. No, I don't mean that at all and this was very plainly obviously from my very clearly written email. Let me try again. No, no subsystem developer needs to monitor new bugzilla reports. This is because *I do it for them*. I will actively make them aware of new reports which I believe are legitimate and which contain sufficient information for them to be able to take further action. > > > It would be far more productive if the ARM category was deleted from > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > mailing list. We've a couple of thousand people on the ARM kernel > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > than look at bugzilla. > > > > Is that [EMAIL PROTECTED] > > Yes. > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. Making a list subscribers-only will cause some bug reports to be lost. Tradeoffs are involved, against which decisions must be made. You have made yours. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote: > > It's relatively common that a regression in subsystem A will manifest as a > failure in subsystem B, and the report initially lands on the desk of the > subsystem B developers. > > But that's OK. The subsystem B people are the ones with the expertise to > be able to work out where the bug resides and to help the subsystem A > people understand what went wrong. > > Alas, sometimes the B people will just roll eyes and do nothing because > they know the problem wasn't in their code. Sometimes. And sometimes the A people will ignore the B people after the root cause has been worked out. Do you have a good idea how to shame A into action? Should I put you on Cc:? Right now I'm in the eye-rolling phase. Jörn -- The cost of changing business rules is much more expensive for software than for a secretaty. -- unknown - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Jörn Engel wrote: On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: I just find it weird that something can be known broken for several -rc* kernels before I happen to install it, discover it's broken on my own machine, and then I track it down, fix it, and submit the patch, generally all within a couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. And when I receive hostility from the "maintainers" of said code for fixing their bugs, well.. that really motivates me to continue reporting new ones.. Given a decent bug report, I agree that having the bug not looked at is shameful. But what can a developer do if a bug report effectively reads "there is some bug somewhere in recent kernels"? How can I know that in this particular case it is my bug that I introduced? It could just as easily be 50 other people and none of them are eager to debug it unless they suspect it to be their bug. .. Most of the regressions we have are easily identifiable and not of the type where there could "50 other people" touching the relevant code. As a developer (and former subsystem maintainer) I look hard at my own code when there's a bug reported that could have come from recent updates there. Usually there are not that many updates to consider, and tracking it down is just a matter of being willing to do so. Of late, I've given up on other developers fixing the stuff they break on my own machines, and I generally just dive into totally unfamiliar code, and find and fix it myself. Quite quickly, usually. And the bugs are often very apparent just from looking at the source code diffs (patches) from recent history in the code that's not working. This is not rocket science, and it doesn't require a log2 download/rebuild/reboot process. But yes, there are more difficult ones, like when my machine crashed yesterday with some form of corruption showing up during JBD filesystem I/O. That's one where the problem isn't going to be obvious to anyone, and I don't actually expect anyone to go looking for it right away. If more such events happen, then it will get more attention. But things like broken drivers, in almost every case those are trivial to track down and fix, even for people not familar with that specific code. This is a common problem and fairly unrelated to linux in general or the kernel in particular. Who is going to be the sucker that figures out which developer the bug belongs to? And I have yet to find a project, commercial or opensource, where volunteers flock to become such a sucker. One option is to push this role to the bug reporter. Another is to strong-arm some developers into this role, by whatever means. A third would be for $LARGE_COMPANY to hire some people. If you have a better idea or would volunteer your time, I'd be grateful. Simply blaming one side, whether bug reporter or a random developer, for not being the sucker doesn't help anyone. .. Nobody's blaming anyone here. I'm just asking that developers here do more like our Top Penguin does, and actually look at problems and try to understand them and suggest fixes to try. And not rely solely on the git-bisect crutch. It's a good crutch, provided the reporter is a kernel developer, or has a lot of time on their hands. But we debugged Linux here for a long time without it. And I already volunteer my time here, thanks, BIG TIME, since 1992 or so. Cheers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > > There's another issue I want to raise concerning bugzilla. We have the > > classic case of "not enough people reading bugzilla bugs" - which is one > > of the biggest problems with bugzilla. Virtually no one in the ARM > > community looks for ARM bugs in bugzilla. > > Nor should they. So what you're saying is... > > Let's not forget that it would be a waste of time for people to manually > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > into bugzilla that a weekly manual check by every maintainer would just > > return the same old boring results for months and months at a time. > > I screen all bugzilla reports. 100% of them. > > - I'll try to establish whether it is a regression > > - I'll solicit any extra information which I believe the reveloper will need > > - I'll ensure that an appropriate developer has seen the report > > And yes, the number of arm-specific reports in there is very small. that just because you do this everyone in a select clique, who you include me in, should be doing this as well. No. Thank. You. > > It would be far more productive if the ARM category was deleted from > > bugzilla and the few people who use bugzilla reported their bugs on the > > mailing list. We've a couple of thousand people on the ARM kernel > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > than look at bugzilla. > > Is that [EMAIL PROTECTED] Yes. > If so, MANITAINERS claims that it is subscribers-only. That would cause > some bug reporters to give up and go away. Find some other mailing list; I'm not hosting *nor* am I willing to run a non-subscribers only mailing list. Period. Not negotiable, so don't even try to change my mind. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Romano Giannetti wrote: > This was what I did in my (in the end almost successful) bisecting when > trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my > SD card"). This is true in theory, but it has some problem. The "this > commit does not compile is the easiest and in man git-bisect it's > explained how to solve it. The changes in .config options, added or > removed, are another problem when jumping back and forth from version. > > The main problem I had, and that stopped me to arrive to a definite is > this situation: [...] > (d was the series to change drivers to use sg helpers, and g was a "fix > fallout from sg helpers" patch). Now I have a series of kernels (d, e, > f) that did not work at all and so I cannot mark them good or bad. With > the number of patches added in the free-for-all week, this is a very > probable scenario. There is a way out from this using bisect? I think there are three strategies you can use in this case: - create a kernel config that is as simple as possible, but still supports your hardware and reproduces your problem; a simpler config will often avoid compilation issues in parts of the kernel that you're not using anyway and has the benefit of speeding up the compiles too - if you know/suspect in what part of the tree the bug is, first limit the bisection to that; you will have to verify that you did indeed find the correct (broken) change by doing a compile for the "last good commit + 1" - if you find a broken commit, use 'git-reset --hard' to try to jump past the bad set of commits, but of course that does not help in the case: g version-bad f unrelated bug corrected e d the broken commit that caused your problem c b unrelated bug that breaks compilation or system introduced a version-good in that case the best you can reasonably be expected to do is report that you narrowed it down to "between a and g" and leave the rest to the developers Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: > > I just find it weird that something can be known broken for several -rc* > kernels before I happen to install it, discover it's broken on my own > machine, > and then I track it down, fix it, and submit the patch, generally all > within a > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. > > And when I receive hostility from the "maintainers" of said code for fixing > their bugs, well.. that really motivates me to continue reporting new ones.. Given a decent bug report, I agree that having the bug not looked at is shameful. But what can a developer do if a bug report effectively reads "there is some bug somewhere in recent kernels"? How can I know that in this particular case it is my bug that I introduced? It could just as easily be 50 other people and none of them are eager to debug it unless they suspect it to be their bug. This is a common problem and fairly unrelated to linux in general or the kernel in particular. Who is going to be the sucker that figures out which developer the bug belongs to? And I have yet to find a project, commercial or opensource, where volunteers flock to become such a sucker. One option is to push this role to the bug reporter. Another is to strong-arm some developers into this role, by whatever means. A third would be for $LARGE_COMPANY to hire some people. If you have a better idea or would volunteer your time, I'd be grateful. Simply blaming one side, whether bug reporter or a random developer, for not being the sucker doesn't help anyone. Jörn -- Joern's library part 2: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 22:33:58 +0100 Jörn Engel <[EMAIL PROTECTED]> wrote: > On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: > > > > I just find it weird that something can be known broken for several -rc* > > kernels before I happen to install it, discover it's broken on my own > > machine, > > and then I track it down, fix it, and submit the patch, generally all > > within a > > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. > > > > And when I receive hostility from the "maintainers" of said code for fixing > > their bugs, well.. that really motivates me to continue reporting new ones.. > > Given a decent bug report, I agree that having the bug not looked at is > shameful. But what can a developer do if a bug report effectively reads > "there is some bug somewhere in recent kernels"? How can I know that in > this particular case it is my bug that I introduced? It could just as > easily be 50 other people and none of them are eager to debug it unless > they suspect it to be their bug. It's relatively common that a regression in subsystem A will manifest as a failure in subsystem B, and the report initially lands on the desk of the subsystem B developers. But that's OK. The subsystem B people are the ones with the expertise to be able to work out where the bug resides and to help the subsystem A people understand what went wrong. Alas, sometimes the B people will just roll eyes and do nothing because they know the problem wasn't in their code. Sometimes. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tuesday, 13 of November 2007, Mark Lord wrote: > Matthew Wilcox wrote: > > On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote: > > > >> mkdir t > >> cd t > >> git clone > >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > >> (wait half an hour) > >> /usr/bin/du -s linux-2.6 > >> 522732 linux-2.6 > > > > You're assuming that everything in linux-2.6 was downloaded; that's > > not true. Everything in linux-2.6/.git was downloaded; but then you do a > > checkout which happens to approximately double the size of the linux-2.6 > > directory. > .. > > Ah, I wondered why it took only half an hour to download. > > .. > > When you compare it to the 60MB tarballs that are published, it's really > > not that bad. > .. > > The tarballs I download are only 45MB. You clone the git repo once. Afterwards, you only update it and that usually doesn't take that much time and a little effort. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
I jump in this discussion hoping to have some more insight on git and to report my experience as a tester. I consider myself as half-literate in this (I am here since 1991, more or less, and I am able to compile a kernel and even hand-apply a patch, although I am in no way a kernel programmer). On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote: > The small instruction below is enough for everyone who is able to > build his own kernel to do a git bisect. > # start bisecting: > cd linux-2.6 > git bisect start > git bisect bad v2.6.21 > git bisect good v2.6.20 > cp /path/to/.config . > This was what I did in my (in the end almost successful) bisecting when trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my SD card"). This is true in theory, but it has some problem. The "this commit does not compile is the easiest and in man git-bisect it's explained how to solve it. The changes in .config options, added or removed, are another problem when jumping back and forth from version (I was bitten by the gadzillions new options added to hda-intel alsa driver, but well, that is solvable with a bit of attention). The main problem I had, and that stopped me to arrive to a definite is this situation: j version-bad i h g unrelated (but similar) bug corrected f e d unrelated (but similar) bug introduced c b a version-good (d was the series to change drivers to use sg helpers, and g was a "fix fallout from sg helpers" patch). Now I have a series of kernels (d, e, f) that did not work at all and so I cannot mark them good or bad. With the number of patches added in the free-for-all week, this is a very probable scenario. There is a way out from this using bisect? Romano PS as a suggestion, I think that added a "Reported-by", or "Tested-by", or "Debugged-by" attribution in the repository, as happened to be in the MMC case, is a nice an d welcomed reward for the effort. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 03:13:46PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > .. >>> If you've been making significant updates to a driver/subsystem, >>> and people are reporting that it is now broken for them, >> >> What are "significant updates"? >> >> Sometimes one person makes one small patch and this patch contains >> a typo. > .. > > Then that person should double check their changes against > the problems reported, and re-convince themselves that the > breakage wasn't from those. Simple. Simple? Everything you have in mind with "should double check their changes" is simply not realistic with dozens of known unfixed regressions within more than half a million changed or new lines of code written by more than 800 people - all numbers only counted since 2.6.23. >... >>> The reporters can help, >>> and many may even git-bisect or send patches. But you cannot *expect* or >>> *insist* upon them doing your job. >> >> Bullshit. >> >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > .. > > It's not about blame, it's about paying attention to breakages in code that a > person claims to be supporting, and then doing their best to resolve the > issues. Maintainers are just humans with limited time. You were the one who suggested to "distribute code maintainership", so you should explain how to find the additional maintainers. > Again, if one has the time to actively write/modify code such that something > breaks, > then that person should also make time to fix the breakages. code writer != subsystem maintainer And git-bisect is the tool that tells you who broke it. >> The bug reporter is the person who can reproduce the problem, and if it's >> a regression then bisecting is the natural way of getting nearer at >> getting it fixed. > .. > For the third time, no disagreement here. git-bsect can help in many cases, > but not in all cases. And it requires a great time commitment from somebody > who's system used to work and now doesn't work. The person who broke it has > a fair bit of responsibility there, too. git-bisect can help only for regressions, and it can help for most regressions. And you shouldn't try to make a problem out of something that isn't a problem: Bug submitters are either volunteers who test -rc or even -git or -mm kernels for finding bugs or people who want a problem they experience fixed. In both cases the submitters are usually willing to invest some time for helping to get the bug fixed. > cheers cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
> Bug fixing is not about finding someone to blame, it's about getting the > bug fixed. Partly - its also about understanding why the bug occurred and making it not happen again. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. Nor should they. > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. I screen all bugzilla reports. 100% of them. - I'll try to establish whether it is a regression - I'll solicit any extra information which I believe the reveloper will need - I'll ensure that an appropriate developer has seen the report And yes, the number of arm-specific reports in there is very small. > It would be far more productive if the ARM category was deleted from > bugzilla and the few people who use bugzilla reported their bugs on the > mailing list. We've a couple of thousand people on the ARM kernel > mailing list at the moment - that's 3 orders of magnitude more of eyes > than look at bugzilla. Is that [EMAIL PROTECTED] If so, MANITAINERS claims that it is subscribers-only. That would cause some bug reporters to give up and go away. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Russell King wrote: On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: Ingo Molnar wrote: .. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy "open source means many eyeballs and that is our QA" answer, which is a _good_ answer but by far not the most intelligent answer! Today "many eyeballs" is simply not good enough and nature (and other OS projects) will route us around if we dont change. .. QA-101 and "many eyeballs" are not at all in opposition. The latter is how we find out about bugs on uncommon hardware, and the former is what we need to track them and overall quality. A HUGE problem I have with current "efforts", is that once someone reports a bug, the onus seems to be 99% on the *reporter* to find the exact line of code or commit. Ghad what a repressive method. 99% on the reporter? Is that why I always try to understand the reporters problem (*provided* it's in an area I know about) and come up with a patch to test a theory or fix the issue? .. Same here. I just find it weird that something can be known broken for several -rc* kernels before I happen to install it, discover it's broken on my own machine, and then I track it down, fix it, and submit the patch, generally all within a couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. And when I receive hostility from the "maintainers" of said code for fixing their bugs, well.. that really motivates me to continue reporting new ones.. I'm _less_ inclined to provide such a "service" for lazy maintainers who've moved off into new and wonderfully exciting technologies, to churn out more patches for me to merge (and eventually provide a free to them bug fixing service for.) That's "less" inclined, not "won't". - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Adrian Bunk wrote: On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: .. If you've been making significant updates to a driver/subsystem, and people are reporting that it is now broken for them, What are "significant updates"? Sometimes one person makes one small patch and this patch contains a typo. .. Then that person should double check their changes against the problems reported, and re-convince themselves that the breakage wasn't from those. Simple. then it's your job to make it right. We have some open drivers/ata/ regressions. .. Yup, but they're more specific than just that entire subsystem, and the maintainers are actively pursuing the problems. Exactly what should be happening. I see some person named "Mark Lord" being responsible for 4 commits. What pubishment do you plan for him if 2.6.24 ships with any libata regressions? .. If the code I'm touching breaks, then I'll fix it ASAP, exactly what the users of that code might expect. The reporters can help, and many may even git-bisect or send patches. But you cannot *expect* or *insist* upon them doing your job. Bullshit. Bug fixing is not about finding someone to blame, it's about getting the bug fixed. .. It's not about blame, it's about paying attention to breakages in code that a person claims to be supporting, and then doing their best to resolve the issues. Again, if one has the time to actively write/modify code such that something breaks, then that person should also make time to fix the breakages. The bug reporter is the person who can reproduce the problem, and if it's a regression then bisecting is the natural way of getting nearer at getting it fixed. .. For the third time, no disagreement here. git-bsect can help in many cases, but not in all cases. And it requires a great time commitment from somebody who's system used to work and now doesn't work. The person who broke it has a fair bit of responsibility there, too. cheers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: >... > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. > > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. >... What about having all ARM bugs in Bugzilla by default assigned to [EMAIL PROTECTED] [1] > Russell King cu Adrian [1] Either directly or through a pseudo address, but that's just a technical detail. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Theodore Tso wrote: > > Heh. I hadn't enabled CONFIG_BCM43XX_DEBUG myself, but I just changed > it for my next kernel build. This is a slightly different issue, > which is that sometimes _DEBUG options shouldn't be turned on by > default (because they really trash performance and bloat log size), > and sometimes they are painless to turn on and don't cost much. > > If that is the case, I'd suggest removing the option and just making > it compiled in by default with a run-time option to enable it. I am taking your suggestion and will produce the necessary patches for ssb, b43 and b43legacy. As bcm43xx is likely to be removed from 2.6.25, which is the earliest such a non-bug fix patch would be accepted, I hope that your future distribution and testing kernels will include the debug option. Thanks, Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 07:46:49PM +, Russell King wrote: > On Tue, Nov 13, 2007 at 08:30:35PM +0100, Adrian Bunk wrote: > > There is this silly limit that noone can work more than 168 hours per > > week on the Linux kernel, and some kernel developers seem to take the > > liberty of spending even less time on kernel development... > > That limit of 168 hours applies all around the world to everyone. > Moreover, not all kernel developers are employed to hack on the > kernel for 168 hours a week. > > For me, personally, that figure is in reality about 24 hours a > week. Yes, just 24. The rest of the time (like *now*) is time I'm > volunteering because I happen to be reading my email... > > ... and happen to be wasting replying to discussions like this rather > than reading that message which has just arrived on the ARM kernel > mailing list from someone having problems using copy_from_user() > with a kernel pointer. > > So, please, stop this idea that somehow kernel developers can > somehow spend infinite amounts of time solving lots and lots of > bugs. Sorry, that happens when using irony in a non-native language... What I wanted to express: Noone has unlimited time for kernel development. > Russell King cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >>> Adrian Bunk wrote: > .. >> Another point is that it shifts the work from the few experienced >> developers to the many users. Users (and voluntary testers) we have >> many, but developer time for debugging bug reports is a quite scarce >> resource. >> >>> And when a "maintainer" is too busy to find/fix their own bugs, >>> that could be a sign that they've bitten off too big of a chunk >>> of the kernel, and it's time for them to distribute code maintainership. >> >> The problem is: Maintainers don't grow on trees. > .. > > Hey, if somebody has time to break things, then they damn well ought > to be able to make time to fix them again. And the best developers > here on LKML do just that (fix what they break). > > You broke it, you fix it. A simple rule. > > Translation for the particularly daft: > > If you've been making significant updates to a driver/subsystem, > and people are reporting that it is now broken for them, What are "significant updates"? Sometimes one person makes one small patch and this patch contains a typo. > then it's your job to make it right. We have some open drivers/ata/ regressions. I see some person named "Mark Lord" being responsible for 4 commits. What pubishment do you plan for him if 2.6.24 ships with any libata regressions? Let George W. Bush wrongly accuse him of possessing weapons of mass destructions and invade Canada? > The reporters can help, > and many may even git-bisect or send patches. > But you cannot *expect* or *insist* upon them doing your job. Bullshit. Bug fixing is not about finding someone to blame, it's about getting the bug fixed. The bug reporter is the person who can reproduce the problem, and if it's a regression then bisecting is the natural way of getting nearer at getting it fixed. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 08:30:35PM +0100, Adrian Bunk wrote: > There is this silly limit that noone can work more than 168 hours per > week on the Linux kernel, and some kernel developers seem to take the > liberty of spending even less time on kernel development... That limit of 168 hours applies all around the world to everyone. Moreover, not all kernel developers are employed to hack on the kernel for 168 hours a week. For me, personally, that figure is in reality about 24 hours a week. Yes, just 24. The rest of the time (like *now*) is time I'm volunteering because I happen to be reading my email... ... and happen to be wasting replying to discussions like this rather than reading that message which has just arrived on the ARM kernel mailing list from someone having problems using copy_from_user() with a kernel pointer. So, please, stop this idea that somehow kernel developers can somehow spend infinite amounts of time solving lots and lots of bugs. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: > Ingo Molnar wrote: > .. > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. 99% on the reporter? Is that why I always try to understand the reporters problem (*provided* it's in an area I know about) and come up with a patch to test a theory or fix the issue? I'm _less_ inclined to provide such a "service" for lazy maintainers who've moved off into new and wonderfully exciting technologies, to churn out more patches for me to merge (and eventually provide a free to them bug fixing service for.) That's "less" inclined, not "won't". -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 04:32:07AM -0800, David Miller wrote: > Luckily if the report being ignored isn't chaff, it will show up again > (and again and again) and this triggers a reprioritization because not > only is the bug no longer chaff, it also now got a lot of information > tagged to it so it's a double worthwhile investment to work on the > problem. Strongly agree. This is exactly what happened to that ARM NO_HZ bug report. The report in bugzilla was rather lacking (and wrong) in ways that have already been described. HPET on ARM? 8) Then on the morning of 6th November, someone reported on the mailing list that "pxa270 doesn't work with oneshot timer" and that was the trigger to getting the bug resolved - because it was a narrowly defined bug report. Since it was a narrowly defined bug report, it became very easy to investigate and resolve. About half an hour of time for an initial patch. There's another issue I want to raise concerning bugzilla. We have the classic case of "not enough people reading bugzilla bugs" - which is one of the biggest problems with bugzilla. Virtually no one in the ARM community looks for ARM bugs in bugzilla. Let's not forget that it would be a waste of time for people to manually check bugzilla for ARM bugs. There's soo few people reporting ARM bugs into bugzilla that a weekly manual check by every maintainer would just return the same old boring results for months and months at a time. It would be far more productive if the ARM category was deleted from bugzilla and the few people who use bugzilla reported their bugs on the mailing list. We've a couple of thousand people on the ARM kernel mailing list at the moment - that's 3 orders of magnitude more of eyes than look at bugzilla. (I'm not saying that if the ARM NO_HZ bug as reported in bugzilla had been reported on the correct mailing list would've been solved earlier; I doubt there'd be much difference. However, the probability of a question being asked of the reporter would've been much higher, and _that_ might have led to an earlier resolution.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
