On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann <mattm...@apache.org> wrote:
> > >> The other thing is - is the new Cloudstack GitHub organization the > >> result of a subset of the PMC going off and doing this - > > > >I am not sure why you say subset. Let’s try to avoid polemics. > > I’m not trying to attack. > > This is not the result of people getting together and saying 'hey, we should fork and work somewhere else, that'd be fun!', but rather 'hey, we are currently unable to do what we need to do, and none of our attempts of getting assistance have resulted in anything. what can we do?'. On January 27th 2016, Schuberg Philis (SBP), a company with many CloudStack contributors/committers/pmcs, announced that they are 'jumping ship, forking the code and going their own way'. (that's my wording, not theirs) Take a look at our git commit history before and after that date. Notice anything? Most, if not all, are trivial commits to fix typos, simple mistakes etc. and not code changes. This may be rude to everyone else, but the fact is that after 4.5 SBP (there are a few exceptions) has done more or less everything when it comes to testing code and gatekeeping the code base. And they did a very good job at it. Frankly I am surprised they even coped with it that long. Apache CloudStack now has a fork (Cosmic), that's not bound by ASF policies and it's lack of progress when it comes to providing the tools necessary. When (or if -- with their own governing they don't have to call it a specific version) SBP release an official version of Cosmic, it would surprise me if not a lot of CloudStack users would atleast try it out. I am pretty sure that I am going to. And wha-bang, there (potentially) goes your community, because there already is a better option out there. > I asked a simple question - how many/who in the Apache CloudStack PMC > is intent on using this new Cloudstack GitHub organization? Not an > attack, a question that I still don’t have an answer to. > > The answer would most likely be 'anyone and everyone'. Contrary to what you might believe, this is being done to /help/ CloudStack, not hurt it. Atleast that is my intention by participating. In case you are unfamiliar with Apache CloudStack, it is a beast. Unlike many typical ASF projects you cannot just unpack the tarball, run 'make test', wait a few minutes and have it properly tested. Testing Apache CloudStack requires a broad variety of physical hardware, network appliances, storage solutions and least but most importantly pretty much every hypervisor that is being used out there. A subset of the test tasks we have take multiple hours to run and only tests a small fraction of the total codebase. Pre 4.6, the Apache CloudStack community had a little to loose discipline on committing to the codebase. Testing was optional, and hardly done. We had multiple versions that had major flaws in them, discovered right after release as people tried to use it -- even for the most basic operations. For the 4.6 release we decided that from now on, every commit would have to be looked through by two different persons, saying they approve it, and tested by a minimum of one. And it worked, the voting process improved, we released rapidly and with far less issues than previously (no software is bug free after all). As mentioned, we require that code changes (be it improvements, fixes or new features) are tested before they are allowed to be committed. Which means that anyone wanting to interact (with code) have to do it theirselves at the moment, and that is _NOT_ an easy task. Which again means that no matter how good your intention is, your PR is not going be merged. What kind of Community treatment is that? The way I see it there is only one solution to this -- we need better testing, and to automate that we need more access to GitHub. There are two ways to do that; 1) By being granted certain permissions to the apache/cloudstack repository. 2) By doing it somewhere else where we have those permissions. Will Stevens asked infra [1] for a small subset of permissions -- none of which should be any real risk for disasters, and got rejected. That rules out option #1. This turned out to be a long, and emotional email, please don't take any grunts personally -- they are not meant to be. [1] https://issues.apache.org/jira/browse/INFRA-11429 -- Erik
