I agree, I certainly don't want to implement something only to have the community do the same later(and in an incompatible manner). It behooves consumers of the project to work with the project. I just wanted clarification because I read this to mean essentially "hey guys, don't just drop patches on us for new features", when I actually have a few things in the pipeline that I intend to do that with. As I mentioned, if I don't get much response from the list I'll just push ahead and offer up a patch if the community wants to take it. In the future I'll be more explicit that we are moving forward and invite anyone to be involved if they'd like.
I'm glad the issues are being addressed. And really, I don't want it to sound like we've had a huge problem because the list is generally responsive. But I can see how some people may have felt a bit lost on how to go forward with a new feature so I thought I'd offer up these experiences. On Dec 14, 2012 4:07 PM, "Joe Brockmeier" <j...@zonker.net> wrote: > On Fri, Dec 14, 2012 at 02:16:58PM -0700, Marcus Sorensen wrote: > > 3. If it's generic enough that it makes sense for upstream CloudStack > (and > > believe me anything we can push back we want to), we post to the list to > > see if anyone else is working on it or interested in it. > > > > 4. We get feedback, but whether or not the community is interested in it, > > we're going to develop it. > > > > 5. If it seems the community is interested in the feature, we post our > > patches for review. Small fixes to existing things are simply committed, > > but new features need review. Even if the community didn't respond, we > post > > it for others to look at in an attempt to get it upstream. > > > > 6. If there's sufficient feedback the change is committed, otherwise it's > > abandoned. > > Others can correct me if I'm wrong but I'd tweak this slightly: > > If you work within the community to develop a feature by proposing it, > making it available for community review, etc. - and do not have any > opposition to the feature - then it should be committed rather than > requiring someone to maintain a feature separate from ACS. > > We need to be sure we're reviewing and accepting patches/features in a > timely fashion and addressing all the requests. > > > The key here is that we're leveraging CloudStack, but we can't be > beholden > > to what the community deems are good features, so we can (and should be > > able to) develop things independently. Then we say to the community > "here's > > this patch we've developed that implements feature X, if you're > > interested", which we may have attempted to start a discussion about > > previously, with mixed results. Obviously we in particular haven't had > more > > than 2 or 3 things total, so don't read too much into my example, but I > > could see how it could become a huge problem. > > Sure - the ASL ensures you can develop independently as necessary and I > don't think anybody would gainsay that. I just hope it's largely > unnecessary for folks to do & maintain things outside CloudStack. I'm > sure there will be instances of features that others want that don't > seem like they fit for the overall project, but I hope we keep that kind > of thing to a minimum. > > Best, > > jzb > -- > Joe Brockmeier > http://dissociatedpress.net/ > Twitter: @jzb >
