On Tue, 28 Jul 2015, Loic Dachary wrote: > On 28/07/2015 10:44, Gregory Farnum wrote: > > On Tue, Jul 28, 2015 at 7:38 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > >> Hi Ceph, > >> > >> The title sounds a little strange (Citerias to become a Ceph project) because I'm not aware of projects initiated by someone external to Ceph that later became part of the Ceph nebula of projects (as found at http://tracker.ceph.com/projects/ or http://github.com/ceph/). I can however imagine that a piece of software developed with no interaction with the Ceph development community could be contributed and become a valuable addition (port to non GNU/Linux Operating Systems, monitoring applications for mobile devices etc.). > >> > >> Although publishing the code of such a component under a Free Software license is a natural first step, there is more to do before it becomes part of what we (the community of Ceph developers) care for on a regular basis. Borrowing the OpenStack requirements ( at http://governance.openstack.org/reference/new-projects-requirements.html ), it could be expressed as: > >> > >> Free Software: > >> The proposed project uses a Free Software license as published at http://www.gnu.org/licenses/license-list.html#SoftwareLicenses > >> Project must have no library dependencies which effectively restrict how the project may be distributed or deployed > >> Open Community: > >> The leadership is chosen by the contributors to the project > >> The project has regular public meetings on IRC and those meetings are logged and published > >> Open Development: > >> The project uses public code reviews > >> The project has core reviewers and adopts a test-driven gate > >> The project provides liaisons that serve as contacts for the work of cross-project teams in Ceph > >> Where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel > >> Where appropriate, the project adopts technology and patterns used by existing Ceph projects > >> Open Design: > >> The project direction is discussed at the Ceph Design Summit and/or on public forums > >> The project uses the ceph-devel ML to discuss issues > >> > >> These requirements are formal in the case of OpenStack but they could also be used in the context of Ceph, not as requirements but as a guideline. > >> > >> What do you think ? > > > > Several small projects have been added to the Ceph constellation > > despite being initially implemented outside of our systems. Mostly > > things like rados-java and phprados. > > > > Obviously those are small and related to Ceph, and the process was > > "let's add this to the Ceph Github?" "Okay." I think if we need more > > formal rules we can invent them as we go; Ceph is not OpenStack and > > isn't going to be supervising the same volume nor breadth of > > individual groups. > > Maybe these could be "Guidelines to become a Ceph project" ? It seems to me that there is a big gap between the dynamic of phprados and say, radosgw-agent. By reading the guidelines, someone willing to contribute code to Ceph understands it's not just about pushing code to a publicly available repository. > > Does that make sense ? Sounds okay to me, although the guidelines above should be modified to match Ceph (for example, we don't have regular IRC meetings with published logs). And some projects (e.g., calamari) have their own development list. This would go on ceph.com somewhere? Under /docs? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
