All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Boris Kolpackov <boris@codesynthesis.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Felix Fietkau <nbd@openwrt.org>,
	Patrick Franz <patfra71@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Junio C Hamano <gitster@pobox.com>,
	linux-kernel@vger.kernel.org
Subject: Re: kconfig as a git subtree on Linux
Date: Thu, 26 Nov 2020 15:38:38 +0000	[thread overview]
Message-ID: <20201126153838.GL4332@42.do-not-panic.com> (raw)
In-Reply-To: <boris.20201126122203@codesynthesis.com>

On Thu, Nov 26, 2020 at 12:38:41PM +0200, Boris Kolpackov wrote:
> Luis Chamberlain <mcgrof@kernel.org> writes:
> 
> > I'd like to propose we discuss the possibility of taking kconfig and
> > making it a git subtree under the Linux kernel. This would allow
> > other projects outside of the Linux kernel to be able to update their
> > own copy / fork of kconfig in a jiffie *very* easily.
> 
> I am maintaining one such copy/fork[1] and for me the effort to pull
> in the new version of upstream (which I currently do by just copying
> scripts/kconfig/*) is nothing compared to the effort of maintaining
> a set of patches[2] on top of that which are necessary to make kconfig
> buildable on other platforms and usable with other build systems.
> 
> So unless there is also an agreement that such portability patches
> are now welcome, this is not going to be a major improvement for me.

Unless you have tried git subtrees, I doubt you really mean this. How
is a 'make refresh' command as comparable as manually pulling in
changes from a project to your project?

> And right now such patches are clearly not welcome[3] (but no hard
> feelings; I wouldn't touch Windows with a ten-foot pole if I could
> help it).

Portability of kconfig to other platorm is a topic of its own. If that
sort of conversation can exist, I think it would have to be *secondary*
to deciding whether or not kconfig lives on its own to allow other
Linux projects to benefit from it.

  Luis

  reply	other threads:[~2020-11-26 15:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 17:25 kconfig as a git subtree on Linux Luis Chamberlain
2020-11-26  9:13 ` Christoph Hellwig
2020-11-26 15:33   ` Luis Chamberlain
2020-11-26 10:38 ` Boris Kolpackov
2020-11-26 15:38   ` Luis Chamberlain [this message]
2020-11-28  8:39 ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201126153838.GL4332@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=acme@redhat.com \
    --cc=boris@codesynthesis.com \
    --cc=gitster@pobox.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mingo@kernel.org \
    --cc=nbd@openwrt.org \
    --cc=patfra71@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.