Hello Willy, On Tue, Jun 18, 2013 at 11:54 PM, Willy Tarreau <w@xxxxxx> wrote: > Hi Be, > > On Tue, Jun 18, 2013 at 09:44:42PM +0100, Ben Hutchings wrote: >> Currently there are 3 different formats used for backports of a single >> commit, which are: >> >> gregkh: commit $HASH upstream. >> davem: [ Upstream commit $HASH ] >> git-cherry-pick: (cherry-picked from commit $HASH) > > plus one : what results of the commit messages we have to adjust an > in which we sometimes do mistakes (eg I found some missing "." after > upstream in some of mine). > >> For backports that correspond to multiple upstream commits, the format >> varies a bit. I haven't attempted to parse those messages >> automatically. > > I did. that resulted in soem people complaining in 2.6.32.60 that some > commit IDs were missing and others incorrect, just because my scripts > failed to catch all the relevant cases and I could not notice this with > my eyes. > > Francis, the most reliable I could propose to you is to look for a > string of 40 consecutive hex digits. But even then there is a risk : > older kernels tend to pick from newer ones and sometimes double IDs > slip through. Revert commits can as well induce you in error. Hmm, hash in the log message is something that is not rare, I wouldn't assume that a single hash value is a link to an upstream commit, or am I missing your point ? > >> > > Don't you think that this link to the upstream commit is an important >> > > information ? >> > >> > I do, which is why I have been putting it in the commits for the past 8 >> > years. >> > >> > You are asking me to guarantee a specific pattern of words will always >> > be used in the future, which is an impossible request, as I'm sure you >> > will agree, as no one can predict the future. >> >> I think we should specify a format that everyone should use. I did >> draft some new wording for stable_kernel_rules.txt which I should send >> out... > > I'm not convinced it will be *that* useful, because there will always be > a small number of backporting issues causing us not to have an exact > upstream commit ID anyway. So if the process is not 100% reliable, I'm > not sure that trying to make it more rigid to get close to 100% success > without ever reaching it is worth the effort. For backports I think the pattern could specify a set of upstream commit, no ? Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html