On Jul 30, 2014, at 9:47 PM, Jeff Law <l...@redhat.com> wrote: > So my biggest concern here is long term maintenance -- who's going to own > care and feeding of these bits over time. > > My inclination is to go ahead and approve, but explicitly note that if the > bits do start to rot that we'll be fairly aggressive at disabling/removing > them.
So the normal way to do this would be to make the plugin front-end non-default and then never gate any release decisions upon the state of the that front-end. If it works, ship it, if it doesn’t ship it. If people want it to build, the contribute patches, if they don’t care, oh well… That said, changes that ripple across front-ends generally need to be built with all (really all) built and are generally rejected if they break the build. Given my experience with lessor front-ends (Objective-C and Objective-C++), I think we do a good job and the maintenance is fairly low. Others can disabuse me of this opinion if they want. My expectation is that this frontend will be easy to maintain and will be a non-issue. Everyone and then someone won’t test with it, they will break it, someone will notice, someone will contribute the 2 line patch that also makes it work, and life goes on. This is my experience with Objective-C++ (a non-default language).
