On Tue, Jan 19, 2016 at 10:50:32AM +0100, Bjørn Mork wrote: > John Whitmore <arigead@xxxxxxxxx> writes: > > I'm sure that this problem has been found and a patch submitted by now as it > > seems to have been from months ago. But assuming neither had occured and this > > was a new discovery how do you check for a reported bug? Do you search mailing > > list for that commit number, or a part of that commit number? > > I cannot tell you what the best practice is, but at least that's what I > do. > > Googling for a fix is usually pretty accurate once the problematic > commit has been found. Both the short title and the 12 digit commit ID > should work, because they are included in the "Fixes" tag of the fix. > Thanks a million I just did a search for the 12 digit commit ID and found the discussion on the mailing list. Most of it over my head but thanks for the information. > Unfortunately Googling isn't as accurate before you know the buggy > commit. In an ideal world, you should be able to find the fix based on > the symptoms described in the commit message. But this doesn't work well > for symptoms which occur frequently and with varying causes. "suspend > failing" is definitely one of those... > > And yes, it is common to discover what you did: The bug is already found > and fixed, but the fix hasn't propagated yet. That can be a bit > demotivating until you realize the beauty of a system where someone else > already fixed your problem and documented the fix in a public "bug > database" :) > > > Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
