On Thu, Aug 1, 2013 at 8:21 AM, Dirk Gouders <dirk@xxxxxxxxxxx> wrote: > Sedat Dilek <sedat.dilek@xxxxxxxxx> writes: > >> On Wed, Jul 31, 2013 at 6:53 PM, Yann E. MORIN <yann.morin.1998@xxxxxxx> wrote: >>> Sedat, Dirk, All, >>> >>> On 2013-07-31 16:22 +0200, Sedat Dilek spake thusly: >>>> On Wed, Jul 31, 2013 at 4:16 PM, Dirk Gouders <dirk@xxxxxxxxxxx> wrote: >>>> > Sedat Dilek <sedat.dilek@xxxxxxxxx> writes: >>>> >> The Freetz router project has 370 [1] as a revert-patch of [2] to its >>>> >> kconfig-v3.8. >>>> >> >>>> >> commit 7ad1227818f09242cfe9bf1845fd24211f5f99bd >>>> >> "kconfig: fix undesirable side effect of adding "visible" menu attribute" >>>> >> >>>> >> I am not a kconfig-expert, but [3] looks like a fixup/folowup to it. >>>> >> >>>> >> commit/?id=e983b7b17ad1a978e954e6aaa62cf12bfc747883 >>>> >> "kconfig/menu.c: fix multiple references to expressions in menu_add_prop()" >>>> >> >>>> >> I contacted Yann in private, but I think this is worth to ask on the >>>> >> linux-kbuild ML. >>> >>> Yes, there was no reason to write such a question in private. >>> >>>> > you are right, [3] fixes a problem that was introduced by [2]. >>>> > (I should have noted that in the commit message -- I'm not sure if we >>>> > can fix that afterwards.) >>> >>> No, it's been pushed to a public tree, it's too late. >>> It's even in Linus' tree, so it is really too late! >>> >>>> thanks for the clarification and fixing this up. >>>> I told Yann in my private email to always add a reference to the >>>> "culprit" commit (root-cause). >>> >>> Since I was not the author of that patch, I have no way to know if it is >>> "a fix for a previous commit", or "just a fix", if the original author >>> does not provide this information. >>> >>> Except for the patches I write, I "just" collect (and test/review) the >>> patches to kconfig in my tree, to make it a bit easier for Michal. I >>> just pass the patches' commit logs as-is (or do trivial edits if >>> needed), so what gets in the tree is the responsibility of the author. >>> Hey, Dirk! ;-) >>> >>> But on the principle, I do agree: if the patch fixes a regression >>> introduced by a previous changeset, it should be referenced in the >>> commit log of that new patch, indeed. >>> >> >> Next time we all do it better before! >> If you fail, you'll get no chocolate, >> >> Good news: >> The Freetz router project accepted my kconfig-v3.11-rc3 version-bump >> [1] and got rid of two patches. >> >> Again, thanks to all involved people. >> >> - Sedat - >> >> [1] http://freetz.org/changeset/10915/trunk > > Hi Sedat, > > I tried to see if I can find some more detail about the Freetz revert > patch [1] -- mainly, because I was wondering if the Freetz people hit > the same problem that [3] fixes. > > Do you have detailed information about the origins of [1], maybe a > pointer to some discussion? All that I could find so far is > http://freetz.org/ticket/1982#comment:7 but I have to confess that I > don't know the Project and it's documentation style very well. > Hi Dirk, I have put a comment into Freetz ticket #1982. Regards, - Sedat - [1] http://freetz.org/ticket/1982#comment:36 > Dirk > > [1] http://freetz.org/browser/trunk/tools/make/patches/370-save-hidden-prompts-to-file.kconfig.patch > [2] kconfig: fix undesirable side effect of adding "visible" menu attribute > [3] kconfig/menu.c: fix multiple references to expressions in menu_add_prop() -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
