Hi all, Each one of you have been mentioned as a Peer to one or more components I am a maintainer of [1] and is relatively new to the component. So, we need to come up with ways where effective knowledge transfer is done to enable you to take independent decisions for issues concerned. Some of the ways I can think of are:
>From me, * giving a high level architectural overview * giving a code walk-through explaining idiosyncrasies >From you, * scourging through bugzilla/mailing lists for issues on individual components and finding RCA and fixes. I can help you to prioritize and with discussions to the best of my capacity. * reading/changing/thinking about code and architecture. If the component is active, code reviewing is definitely a good way to start and to keep informed about component. * identifying weak points and suggesting improvements to the component. IOW, charting roadmap. I would like to hear from you on how to go about this exercise. Suggestions and help with logistics of organizing talks/sessions (if necessary) are welcome. [1] https://review.gluster.org/17583 regards, Raghavendra _______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
