Process for New DISTRO_FEATURES (was: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2012-01-16 at 17:58 +0000, Paul Eggleton wrote:
> On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote:
> > On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:
> > > On Wed, 2011-11-23 at 16:48 +0000, Phil Blundell wrote:
> > > > b) introduce some sort of concept of "feature epochs", where the
> > > > DISTRO
> > > > gets to declare what epoch it is expecting and the compatibility
> > > > code
> > > > then backfills DISTRO_FEATURES to take account of things that were
> > > > enabled by default in past epochs but have since been removed.  This
> > > > introduces a certain extra maintenance burden but it means that
> > > > DISTROs
> > > > will no longer get unpleasant surprises
> > > 
> > > I'm wondering if we can do something in the core like:
> > > 
> > > DISTRO_FEATURES_BACKFILLOPTS = "pulseaudio"
> > > 
> > > and have the distro set:
> > > 
> > > DISTRO_FEATURES_BACKFILLCONSIDERED = ""
> > > 
> > > and then add some code which looks for anything in
> > > DISTRO_FEATURES_BACKFILLOPTS but not in
> > > DISTRO_FEATURES_BACKFILLCONSIDERED and adds it to DISTRO_FEATURES.
> > > 
> > > Distros can then opt out of a given feature by adding it to
> > > DISTRO_FEATURES_BACKFILLCONSIDERED.
> > > 
> > > This would let us maintain compatibility but also move forward and
> > > create new settings with names that make sense.
> > 
> > I'd like to try to move forward with this fix (although I prefer an
> > alternative term to "backfill", perhaps "introduce" instead?) If this is
> > what we want to do, should it be implemented by:
> > 
> > (a) modifying DISTRO_FEATURES directly (as I think Richard is suggesting),
> > or
> > 
> > (b) a simple python call that the distro needs to add to their own
> > DISTRO_FEATURES (i.e. "${@distro_features_introduce(d)}" ?
> > 
> > Option (a) is a little tidier but (b) makes it obvious where any introduced
> > items in DISTRO_FEATURES are coming from.
> 
> This was brought up at the last TSC meeting, but we agreed to leave the 
> discussion on the mailing list for the moment.
> 
> So, any thoughts?

In the intervening time I haven't come up with anything better. I would
like to move forward on this issue. I think the main thing is to
document the variables clearly. The names aren't brilliant but with
reasonable comments we should be ok...

Cheers,

Richard