On Tue, May 26, 2020 at 10:16 AM spudaneco <spudan...@gmail.com> wrote: > > Don't forget, you are not a user anymore. You are a maintainer and you are > responsible for keeping a stable environment for all users.Sent from Samsung > tablet.
yes. i guess we share the goal. just having different opinions. > -------- Original message --------From: Takashi Yamamoto > <yamam...@midokura.com.INVALID> Date: 5/25/20 6:41 PM (GMT-06:00) To: > dev@nuttx.apache.org Subject: Re: kconfig (Re: mbedtls) On Tue, May 26, 2020 > at 12:48 AM Gregory Nutt <spudan...@gmail.com> wrote:>> We should all be > using a consistent, common version of> kconfig-frontends. A snapshot was > taken and has never disappeared from> internet contrary to other statements > it is always been here and will> always be here: > https://bitbucket.org/nuttx/tools/src/master/>> We do not accept any > Python-based tools in the critical build path.> There are some secondary > Python scripts under tools/ but we cannot> permit the introduction of any new > user tool requirements in the basic> build. That is simply off-limits.>> > Think of the NuttX user first! Technologies and tools are much further> down > the list.i can understand you don't like to have python dependency.but i > don't think the "user first" argument is not a good reason.for some users > (like me) python is definitely easier to deal withthan the current state of > kconfig-frontends.>> Greg>> On 5/25/2020 9:38 AM, Nathan Hartman wrote:> > On > Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto> > > <yamam...@midokura.com.invalid> wrote:> >> On Mon, May 25, 2020 at 1:00 AM > Nathan Hartman <hartman.nat...@gmail.com> wrote:> >>> We do have to solve the > issue of Kconfig. That has disappeared from> >>> the Internet and we depend > on it. We were told, before we joined> >> do we have some reasons not to > switch to kconfiglib?> > Does kconfiglib depend on Python? Currently we do > not have a> > dependency on Python. That would introduce Python as a pretty > big> > dependency, which I would rather avoid.> >> > Also, that project could > disappear from the Internet, just like> > Kconfig, and we'd be back at square > one.> >> > I think we should solve the kconfig licensing / hosting question.> > > Early in our ASF efforts we were told that exceptions are sometimes> > made > so that a project can host "well-known" third party tools that it> > depends > on. We depend on kconfig as a central piece of our build> > system, just as > we depend on 3rd party compiler toolchains etc. It> > runs on the developer's > host machine. It does NOT get compiled into> > the user's NuttX build. > Kconfig as a project has come and gone from> > the Internet so for the time > being Greg is hosting a mirror at his> > BitBucket along with other build > tools.> >> > We need some guidance from our mentors on how to ensure the > longevity> > of the tools, like Kconfig, that are needed for NuttX, at > Apache> > NuttX, not at some third party location that can disappear > suddenly.> >> > Thanks,> > Nathan>>
