cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Emneina <aemne...@gmail.com>
Subject Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)
Date Fri, 18 Mar 2016 00:44:32 GMT
+BCC: David Nalley for possible guidance.

Apache infra stated that 'The VP' dictated the policy to not allow
'repo:status' across the board for projects. Has anyone tried to engage the
VP, in order to get them to have a closer look at this policy? It appears
to be no way to exploit that function maliciously... so hopefully they
could allow for this to be enabled.

$0.02

On Thu, Mar 17, 2016 at 4:46 PM, Erik Weber <terbolous@gmail.com> wrote:

> On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann <mattmann@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message