I like, thanks for starting this discussion. Please ignore the rest of this mail as it is not of any consequence.
As a folowup, I would like ti propose to move any peace of code to branches if it meets the qualifications you mention; not (full) functional, not production ready. And i would like to add not fully tested an not fully tested. Ofcourse we can only migrate in that dirrection, unfortunately. As a newbee on this codebase it would help a lot knowing that any code on master is actually functional. Meaning that coveragetests could help. This is me@devchair talking, i will probably be countered by collegues having real user issues. This is also an incentive to document and test, for those rhat want to guard their niche functionality and an incentive to isolate code for easy cherrypicking whilst not done. Hi all, So we've run into a couple of features that have turned out to have never really been "production grade", perhaps due to their creation as prototypes during the cloud.com startup period. Swift, Bare metal provisioning and OVM are examples. Bare metal is obviously resolved now, but Swift is an open discussion and OVM remains open for someone to decide to fix it. I'd like to propose that those devs that have been around this code-base from before it's entry into Apache take some time to review things from the past. What else is lurking in the repo that some of us might *think* are functional, but that haven't been tested in years? What code was a prototype that never got fully implemented / supported? If we can get all this out in the open, perhaps we can have a solid foundation to move forward. On the other hand, if nobody has any examples beyond the ones listed below, then I think that those of us that are relatively new to the code will have to work under the assumption that everything is expected to be functional. After we establish our foundation, we will need to be very consistent about our support of the features. We'll need to be clear about intentions to deprecate something, and perhaps even provide a full feature release cycle worth of warning about a pending deprecation. As a user, I not been stung by a feature that was yanked... but I was certainly surprised when I found out that OVM and Bare Metal weren't being kept up to date (again, bare metal is resolved now). Those features were part of our evaluation of the software, and me $dayjob has plans to at least use bare metal. So why did I share that little story? Well, it's because features coming and going are actually significant events to users of the software. Just because we don't know of someone using a feature doesn't mean that it isn't in use. I'd like us to have that solid foundation as a start, and then be very clear when we need/want to make a decision that removes a feature from the software. -chip
