> Another factor that I think we should consider when taking on big > features, and I've heard a version of this from you Nicolas, is > whether the feature contributor will be around post commit to fix bugs > that pop up post-commit.
We've been burned by that a few times that I can recall but isn't that par for the course for open source? I'm not sure there is much that we can do there. How would this be determined? Circumstances change. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) >________________________________ >From: Stack <st...@duboce.net> >To: dev@hbase.apache.org >Sent: Wednesday, November 2, 2011 8:17 PM >Subject: Re: patch maturity and HBase release Was: HBASE-4120 table level >priority > >On Wed, Nov 2, 2011 at 5:12 PM, Nicolas Spiegelberg <nspiegelb...@fb.com> >wrote: >> I agree with Todd's sentiments on unnecessarily coupling feature priority >> with the availability of a patch. There's patches that we've developed >> internally, then threw away because we couldn't tie it to a production use >> case or thought a better design might be necessary. There's also patches >> that we've had simmering out for a couple weeks so we could think about it >> and cross-talk. Every new feature adds to the complexity of an >> already-complex system. We should make sure the feature has demand. >> > >Another factor that I think we should consider when taking on big >features, and I've heard a version of this from you Nicolas, is >whether the feature contributor will be around post commit to fix bugs >that pop up post-commit. > >St.Ack > > >
