build time options

[Nicolas Williams]

On Fri, Jan 30, 2009 at 04:14:58PM -0500, Sam Hartman wrote:
>     Nicolas> I also object unless the default is a build-time option.
>     Nicolas> We would like to eventually get to where we do code drops
>     Nicolas> from MIT, but we might need to make changes that can be
>     Nicolas> seen as incompatible at potentially different times than
>     Nicolas> MIT.
> 
> I agree that MIT's recent tendency to introduce vendor-specific code
> with a bunch of build-time defines would be compatible with this.
> 
> I'd like to start a discussion of that practice.  I understand the
> desire to minimize patches.  However I think it would be a good idea
> to get some guidelines for when we accept build-time options and for
> when we tell people to go maintain a patch.

I agree.

The need for this stems from the fact that each vendor/distributor has
different release schedules from MIT and different rules for when
incompatible changes can be made.  Sometimes we can simply make the
change if it's minor enough.  Other times we must resort to patching/
forking.  We should all aim to limit patching/forking due to
incompatible changes.

A good rule is that any change which is or may be either an incompatible
change to what should be a stable interface or to a semantic that rises
to the level of an interface (i.e., users/apps expect a given behavior
and depend on it) should trigger a discussion of whether the change
should be controlled by a build option, and how long that option should
last.

Some changes will be very difficult to make build-selectable.  If this
can't be avoided then vendors/distros might have to live with the
change, or we might all conclude that the new feature should be designed
differently, etcetera.

Nico
--