On May 13, 2014, at 7:36 PM, Tom Browder wrote: > On Tue, May 13, 2014 at 11:31 AM, Tom Browder <tom.brow...@gmail.com> wrote: >> On Tue, May 13, 2014 at 11:09 AM, Christopher Sean Morrison >>> I'm leery of features getting implemented without a >>> specific known use case (i.e., "if you build it, they will come"), but > > The use case is a set of D bindings to add to the existing D collection at: > > https://github.com/D-Programming-Deimos
Sounds like a great place to put it, but that's a rather cyclic use-case reasoning. :) It's like saying we need to build an XYZ car because some parking lot has parking spots for XYZ cars. That doesn't say anything about anyone actually using the car, just that it's available. Even better house analogy -- building a mobile home because there's a trailer park where we can park it is not a use case -- finding someone to live in there (i.e, use it), however, is. A specific use-case would be implementing D/Go/Rust bindings because someone is working on a GUI or some other development in that language, for example. Any new/major project in-house or any 3rd party "customer" become use-case possibilities. That's great if you have a desire to work on a D interface -- awesome -- but without identifying a use, it is an "if you build it, they will/might/can come". My assertion for adopting into trunk is that we have such a use-case planned/promised/committed, not just a hypothetical, before we accept the maintenance cost. Put it on a branch and the maintenance costs are minimized (and can even help accelerate development). >> Maybe it would be better to do such a project in a like umbrella group such >> as: >> >> https://github.com/D-Programming-Deimos > > Hm, those projects seem to point back to the upstream repos. Maybe > the binding code should be here until it is working. > > I guess a branch would work, but working on the trunk shouldn't > interfere with "normal" builds if the appropriate option (default > "NO") is not turned on. It would be easier to avoid doing constant > merges to keep up with the trunk. Shouldn't and in the past we've gone that route, but the costs do slowly add up. Especially given enough time. We have a number of experimental efforts started on trunk with appropriate options added to the build, but they still incur a maintenance cost simply because they exist. We have acquired too many incomplete projects on trunk -- that's why most new efforts (e.g., OpenCL) are now being started on a branch where they arguably should have been in the first place. Examples include the simulation interface (Bullet), the old parametric constraint library (Boost/Spirit), the html help web browser (hv3, sqlite), object-oriented bounding boxes (libgdiam), level-of-detail mesh wireframes (libvds), path tracer (OSL, llvm), ... probably others. The interfaces using Bullet and OSL are probably the best comparison where they really shouldn't interfere and most of the time they don't, but eventually they do. Some of those are incredibly close to completion and all of them have a GREAT reason for existing. Most even have/had a specific use-case or user identified. But until they reach some level of completion, they are predominantly dead weight to anyone but the original author. Most of them should have started on a branch until they reached some level of end-user maturity. Cheers! Sean ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
