Thanks Chip for starting this thread. I can at least think of the netapp plugin integration as something that was tried before ASF but no longer tested and used.
I'm all for coming up with this list but I don't see how this list can be conclusive. The problem that Edison dealt with in swift support is very real. I'm not trying to make an excuse for making a unilateral decision to drop support without getting community feedback first. That is wrong and I'm glad it's being resolved. However, without automated testing backing functionality, we can have different set of these problems pop up every release. Should we start with only functionalities tested in automated testing to be the supported feature set and add features back in as more testing is added back in? To that end, how much of 4.0/4.1/4.2 features are actually added to automated testing? Or else we can face the same problem with those features too. I still support gathering this list, even if it might be inconclusive. --Alex > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Wednesday, July 10, 2013 6:23 AM > To: dev@cloudstack.apache.org > Subject: [DISCUSS] What other "features" or code is sitting around that might > be suffering from bit rot? > > 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
