On Wed, Nov 05, 2014 at 10:20:58PM +0100, Johannes Berg wrote:
> On Wed, 2014-11-05 at 21:29 +0100, Luis R. Rodriguez wrote:
>
> > > What difference does this make? It'll break some scripting that we have
> > > for sure (assuming the BACKPORTED_ prefix), so naturally I'd like to see
> > > why it i
On Wed, 2014-11-05 at 21:29 +0100, Luis R. Rodriguez wrote:
> > What difference does this make? It'll break some scripting that we have
> > for sure (assuming the BACKPORTED_ prefix), so naturally I'd like to see
> > why it is necessary.
>
> Sure, let me explain. So if we don't unify we will have
On Wed, Nov 05, 2014 at 08:57:25AM +0100, Johannes Berg wrote:
> On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > In order to help unify the naming scheme for shared
> > backports versioning information rely on the CPTCFG_
> > prefix, when integrat
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> In order to help unify the naming scheme for shared
> backports versioning information rely on the CPTCFG_
> prefix, when integration support gets added that will
> translate to the respective CONFIG_BACKP
From: "Luis R. Rodriguez"
In order to help unify the naming scheme for shared
backports versioning information rely on the CPTCFG_
prefix, when integration support gets added that will
translate to the respective CONFIG_BACKPORT_ prefix.
Kconfig opt env entries don't get propagated out, so
we nee
5 matches
Mail list logo
