Thanks Dave and Taylor for the advice. Owners is not probably what I meant. Instead, I could call them Reviewers - for this PR.
Long term since there are so many different modules and each committer develop different area of expertise, what is the recommended way to review the code and merge them into master? cheers /karthik On Thu, Apr 5, 2018 at 3:56 PM, P. Taylor Goetz <[email protected]> wrote: > As a mentor, I would recommend you avoid any concept of “ownership” like > the plague. It implies a project hierarchy that ASF projects do not have. > > In ASF projects committer bits are boolean. Bob’s committer bit is no > different from Alice’s. Their project expertise may lie in different areas > of the codebase, but they are inherently *trusted* not to make reckless > changes without collaboration/review with other committers. > > If you feel you must go down this path, I would suggest different language > than “owner”. At best it should be an informal designation (not a role) by > a volunteer who is willing to help shepherd that section of the codebase > (e.g. help with/perform PR reviews, groom issues, revive discussions, > etc.). I would also recommend documenting the concept, specifically how > others can get involved. > > -Taylor > > > On Apr 5, 2018, at 6:02 PM, Karthik Ramasamy <[email protected]> wrote: > > > > Ashvin - > > > > It could be good to designate owners for different areas - let me come up > > with a list by the end of the today tonight. > > > > cheers > > /karthik > > > > > > On Thu, Apr 5, 2018 at 11:42 AM, Ning Wang <[email protected]> wrote: > > > >> Make sense to me. > >> > >> > >> > >> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A <[email protected]> wrote: > >> > >>> Hi Devs, > >>> > >>> PR 2840 renames com.twitter package to org.apache. This change touches > >> more > >>> than *2,127* files. Is there a test strategy for this change which > >> updates > >>> everything? I believe just depending on unit and integration tests may > be > >>> insufficient. > >>> > >>> Also I am hoping git history will be preserved. > >>> > >>> Should we create a coarse checklist and take ownership of manual > >>> verification of individual components? > >>> > >>> 1. Examples > >>> 2. Heron UI > >>> 1. Metrics > >>> 2. Logs > >>> 3. API server > >>> 4. Heron client > >>> 5. Docker > >>> 6. Schedulers > >>> 1. Aurora > >>> 2. Kubernetes > >>> 3. Yarn > >>> 4. .. > >>> 7. Python > >>> 8. Heron Tracker > >>> 9. Heron metrics cache > >>> 10. Heron Health manager > >>> 11. ... > >>> > >>> > >>> Thanks, > >>> Ashvin > >>> > >> > >
