On Monday, February 04, 2013 09:18:37 PM you wrote: > On 2/2/13 4:47 AM, Igor Galić wrote: > > Hey folks, > > > > just a heads-up: I put --enable-experimental-plugins in all our builds > > and I'm expecting some massive failures all over the place. > > > > This code needs more exposure, and I thought I'd start by building it. > > I'm not sure this is a great idea. Several of the plugins in experimental > simply don't compile, and won't compile (on any platform) without an owner. > The idea behind "experimental" was that it'd be a safe playground, where we > don't have to be picky. --enable-experimental is a great way for someone to > fix some of these plugins.
I think experimental makes for a *good* staging area, but as it is, the plugins are not getting enough exposure. A first step in getting more exposure is to build them by default on our buildbots. If we know that a certain plugin won't ever possibly build on a certain platform (for example: a DTrace plugin won't build well on Linux), then we need a way to fix this at configure time. (Is there a simple and sane way to do this our plugins[/experimental]/Makefile.am ?) > A few options would be > > a) Move these plugins to another directory, and another configure option. This sounds like creating hierachies of buerocracies. > b) Move the plugins that have been used to some extent, and has at least one > active developer, out to the main build area. > > c) Do nothing ;). > > d) enable experimental on all builds, and exclude all plugins that don't > build (but then, how will someone test / fix / build those plugins?). > > > b) would be my preference. Mine too ;) I think the move towards --enable-experimental-plugins on the buildbots might give you exactly that: People owning up to (their?) code, fixing broken builds or at the very least filing tickets. > -- Leif
