cmda-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jia Zhang <>
Subject Re: CMDA Community Issues
Date Wed, 06 Jul 2016 17:50:01 GMT
Dear Greg,

Thanks a lot for your detailed instructions on Apache requirements. Very clear. The CMDA community
is going to have meeting and figure out ways to adjust our operations to match Apache requirements.

Best regards,

> On Jul 6, 2016, at 9:38 AM, Greg Reddin <> wrote:
> Hi CMDA,
> It is my goal for this project to succeed at Apache, but I think there
> is a disconnect that needs to be addressed. I want to raise some of
> the specific issues that I have seen that need to be addressed and
> give some practical tips on how to address them. Please understand
> that I don't mean to offend anyone by this message. My goal is to help
> you understand what is needed to get on the right path. Please let me
> know if any clarity is needed.
> First, the project seems to be too dependent on school projects. It
> appears that much of the project's work and direction are decided by a
> few people who are preparing for the next semester of school. The CMDA
> community on the dev list do not have any visibility into these
> decisions until after the fact. This may be something that makes the
> project incompatible with Apache. If the project revolves around the
> agenda of a few people driven by their teaching needs, it is by
> definition, not a community led project. For us to succeed at Apache,
> the school projects must become ancillary to the core of the project.
> CMDA should be able to continue on in its own direction without
> dependencies on student work that has specific requirements and
> timeframes. I'll offer below some advice on how to incorporate student
> projects.
> Second, code is not developed in Apache repositories. Instead it is
> imported in bulk. For CMDA to be a community-driven project code must
> be committed directly to the Apache repo first. If some folks need to
> maintain a fork for their own uses elsewhere, including for student
> projects, that's fine. But individual commits, not bulk commits need
> to be taking place in Apache repos, not external ones.
> Third, decisions are not made by the community. They appear to be made
> by a few people separate from the dev list and presented here after
> the fact. We see meeting minutes where things have been decided and
> assignments made. If I want to contribute to the Docker container, how
> can I do that? If I want to contribute to improving the HTML front
> ends how would I go about that? How can someone from the outside of
> your core group help decide what the next step will be and contribute
> code? That's the essence of the Apache Way.
> Now, here are some specific things I need to see before I can say the
> project is making progress in the right direction.
> 1. Code from school projects should be submitted to Apache by the
> author and committed to the Apache repo by a CMDA committer. It can be
> submitted through a Jira attachment, GitHub pull request, etc.
> 2. Discussion regarding school projects should take place on the CMDA dev list.
> 3. We must see commits of code to the Apache CMDA repository. These
> are not imports of large blocks of code worked on for a long time, but
> individual changes submitted one at a time directly to the Apache
> project. The Apache repo must be the primary source code repository.
> 4. Make decisions regarding code and project direction on the CMDA dev
> list. Offlist face-to-face meetings are ok, but no decisions can be
> made, only recommendations. If someone on list offers an alternative
> solution to any of those recommendations it must receive equal weight
> and the community decides collectively how to proceed.
> Discussions regarding project direction, features, releases, who's
> working on what, etc. must take place on the CMDA dev list.
> Finally, please understand that if the project is not compatible with
> the Apache style of development, it's not a failure. It would not be a
> bad mark on your "resume'." It would simply mean that the project
> relies on some tenets of development that are not driven by the
> community. Perhaps it is better for this project to be presented to
> the community after work is done, as opposed to allowing the community
> broad input as to its direction. If so that's fine. But if you want to
> be at Apache that broad input from the community is an absolute
> requirement.
> Please let me know if any clarification of these points is needed.
> Thanks,
> Greg

View raw message