That’s up to the project to decide. ;) Mentors are here to help you make sure what you decide upon is consistent with the Apache Way.
-Taylor > On Apr 5, 2018, at 7:50 PM, Karthik Ramasamy <[email protected]> wrote: > > 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 >>>>> >>>> >> >>
