Re: kconfig/menu.c: Fixup to "kconfig: fix undesirable side effect of adding "visible" menu attribute" ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
--
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




[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux