cmda-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (3980)" <>
Subject Re: CMDA Community Issues
Date Wed, 06 Jul 2016 18:14:01 GMT
This is great advice I recommend folks read it carefully.

Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

On 7/6/16, 9:38 AM, "Greg Reddin" <> wrote:

>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
>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
>Please let me know if any clarification of these points is needed.
View raw message