From mboxrd@z Thu Jan  1 00:00:00 1970
From: arigead@gmail.com (John Whitmore)
Date: Tue, 19 Jan 2016 11:27:16 +0000
Subject: Found a problem so what next?
In-Reply-To: <87mvs1lwyf.fsf@nemi.mork.no>
References: <20160118173431.GA2427@bamboo.electronicsoup>
	<87mvs1lwyf.fsf@nemi.mork.no>
Message-ID: <20160119112715.GB6915@bamboo.electronicsoup>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On Tue, Jan 19, 2016 at 10:50:32AM +0100, Bj?rn Mork wrote:
> John Whitmore <arigead@gmail.com> 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