On Dec 15, 2012, at 12:42 AM, Marcus Sorensen <shadow...@gmail.com> wrote:
> 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. I will just pick up on Marcus's last point. This is still a very new project with lots of people learning the "Apache Way" and even the open source way, the main reason for incubation. It takes time and patience. I for one have to learn the way it's done. One of the main tenant of the Apache way is that everything happens on the mailing list. While great, this is also difficult to get used to. Face to face is still a very effective interaction media :), public emails can be tough and solving issues via email can often lead to more issues rather than a solution. To keep things brief I would like to make two (maybe naive) suggestions: -Can we have an official roadmap ? We discussed a plan for release, but I don't know where we discussed what was going to be in the release. Maybe we don't need a roadmap, but for instance I don't know when the api_refactoring is going to be merged in master, or the javelin branch ? If we have a roadmap even a coarse one, we could also have a process (a light one) to include new features in the roadmap. -We have IRC meetings, and we understand that we cannot make decisions in the meeting. But IRC is still a text interface. In order to build up the community I think we need to build up relationships. The conference did that (even though I was not there :( and we need to have other conferences/meetups/workshops/beers ). How about a voice meeting, or even a video one. I don't know if it's done in other Apache projects, maybe it's a big no-no. But seeing folks in Skype or google video might help communication/trust and build a healthy community. Cheers, and Merry Christmas :) -Sebastien > 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 >>
