25 Jun
2019
25 Jun
'19
6:46 p.m.
On 6/25/19 9:08 AM, Lenz Grimmer wrote:
Hi Mark,
On 6/25/19 2:31 PM, Mark Nelson wrote:
Some kind of formal process for sub-projects probably makes sense!
Very much agreed! The ceph repo is already far
bigger than I'd prefer.
My current ceph working directory is 34GB! (granted most of that is
build). Compile times have ballooned over the years too. Personally
I'd rather go the other way and start removing things that aren't
explicitly required.
Of course that's something that should be
considered/evaluated and I
actually share your pains and concerns regarding the overall size. In
the case of ceph-iscsi, I think the benefits of adding it would outweigh
the additional overhead, but I'm aware it's a fine balance and we don't
seem to have a formalized way in which sub-projects could be evaluated
for promotion/inclusion into the main git repo (or the other way around).
It probably makes sense to check the code base for unnecessary things on
a regular basis. Do you have any specific components in mind? How do you
define "explicitly required"? And by "removing", do you mean
deleting
them for good or moving then out of the ceph git repo into a separate one?
I'd rather not single anything out, but I think having a formal process
for determining inclusion is a very good idea. No need to delete
anything, but I would very much like to see a smaller ceph git repo in
the future by moving/splitting things that aren't especially tightly
coupled. Other folks are more tolerant of large git repos though, so my
opinion may be in the minority.
Mark
>
> Lenz
>
>
> _______________________________________________
> Dev mailing list -- dev(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io