On 06/10/2015 01:08 PM, Krishnan Parthasarathi wrote:
I am also not a major fan of a single component being managed by
multiple folks. Given that respective component maintainers will be
managing their parts of glusterd & CLI going forward, I think we are
positioned reasonably well to manage patches in glusterd.
What problems do you see with multiple maintainers? We have that working
well in glusterd for over a year. In fact, we are adding one more to glusterd.
We are proposing multiple maintainers for erasure-coding, libglusterfs and bit-rot
to name a few.
More than few maintainers per component will primarily have the drawback
of more co-ordination which can come in the way of operational
efficiency. There are good reasons to have multiple maintainers for
glusterd & CLI, some being:
- the scope of these components is vast
- Maintainers of glusterd will be heavily involved in the 4.0 effort.
Additional maintainer has been proposed to make the task of managing 3.x
easier while we move towards 4.0
We need to reduce the burden on a single maintainer and have better
availability if the sole maintainer is away for a temporary period. With
this intent we have added maintainers to components that warrant
additional help and can benefit from higher availability. In addition to
usual component maintainers, we have broader maintainers who will work
across the stack and can help those components that do not have multiple
maintainers yet.
Regards,
Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
