Source tree restructuring » History » Revision 2
Revision 1 (Jessica Mack, 06/07/2015 01:43 AM) → Revision 2/3 (Jos Collin, 12/20/2016 01:15 AM)
h1. Source tree restructuring h3. Summary During the makefile cleanup, there was some mention on the mailing list about a possible 'phase 2' - the cleanup of the source tree. I've got a scratchbook file with an idea of how the source tree could look like. I thought it might be good to share that and use it as a basis for discussion. I invite people to add comments to the 'detailed description' below. h3. Owners * Roald van Loon (roaldvanloon@gmail.com) * Name (Affiliation) * Name h3. Interested Parties * Jos Collin (jcollin@redhat.com) Name (Affiliation) * Name (Affiliation) * Name h3. Current Status h3. Detailed Description <pre> /Makefile.am /configure.ac /autogen.sh /AUTHORS, /COPYING, /README, etc /SubmittingPatches /Doxyfile /ChangeLog /CodingStyle /PendingReleaseNotes /contrib -- scripts and extras (/admin, /keys, /share, /src/script, /src/bash_completion) /contrib/dist -- distro stuff for rpm/debian/etc (including /udev, /src/upstart) /contrib/m4 -- autotools scripts /contrib/qa /contrib/wireshark /contrib/gtest /contrib/libs3 /contrib/pybind /examples /doc /rados -- librados (installed as librados.so) /rados/include -- exports will become "#include <ceph/rados/XYZ>" /rados/src /rados/test /rbd -- librbd (installed as librbd.so) /rbd/include -- exports will become "#include <ceph/rbd/XYZ>" /rbd/src /rbd/fuse /rbd/test # Uses msgr, messages, osdc, and osdmap/mdsmap/monmap # Maybe better to also put MonClient in here? /client -- libclient (install as libcephclient.so, or only use as convenience lib?) /client/include -- exports will become "#include <ceph/client/XYZ>" /client/src /client/test # Or is this nicer in /client/cephfs, /client/hadoop, /client/cephfs_jni or something? /cephfs -- libcephfs (installed as libcephfs.so) /cephfs/include -- exports will become "#include <ceph/cephfs/XYZ>" /cephfs/src /cephfs/jni /cephfs/hadoop /cephfs/test /rgw -- librgw (future, install as librgw.so) /rgw/include -- exports will become "#include <ceph/rgw/XYZ>" /rgw/src /rgw/test # Do we want this standalone? It's also used by cephfs, rgw, /auth -- libauth (install as libcephauth.so, or only use as convenience lib?) /auth/src /auth/test # Do we want os + backends standalone, or shall we put it in /ceph/os ? /os -- libos (install as libcephos.so, or only use as convenience lib?) /os/include -- exports will become "#include <ceph/os/XYZ>" /os/test # This can be completely standalone /crush -- libcrush (installed as libcrush.so) /crush/include -- exports will become "#include <ceph/crush/XYZ>" /crush/src /crush/tools -- like crushtool /crush/test /ceph /ceph/include -- exports will become "#include <ceph/XYZ>" /ceph/common /ceph/src -- main daemons like ceph_mon.cc etc /ceph/mon -- current /src/mon/* /ceph/mds /ceph/osd /ceph/osdc /ceph/msg -- should this be here? /ceph/test /ceph/tools # What about msg/messages? And events? </pre> h3. Work items h3. Coding tasks # Task 1 # Task 2 # Task 3 h3. Build / release tasks # Task 1 # Task 2 # Task 3 h3. Documentation tasks # Task 1 # Task 2 # Task 3 h3. Deprecation tasks # Task 1 # Task 2 # Task 3