Hi All, I would also be happy to review and verify package changes for all *Scala & Java Streamlet API* tiers as follows: - Implementation - UT Cases - IT Cases (PR #2826) - Examples
Thanks, Eren On 6 April 2018 at 07:37, Karthik Ramasamy <kart...@streaml.io> wrote: > +1 - sounds good! > > On Thu, Apr 5, 2018 at 5:36 PM, Josh Fischer <j...@joshfischer.io> wrote: > > > I would be happy to review all of the ECO codebase and examples to verify > > that the package change has not caused any issues. > > > > -Josh > > > > On Thu, Apr 5, 2018 at 6:54 PM P. Taylor Goetz <ptgo...@gmail.com> > wrote: > > > > > 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 <kart...@streaml.io> > > 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 <ptgo...@gmail.com> > > > 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 <kart...@streaml.io> > > > 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 <wangnin...@gmail.com> > > > wrote: > > > >>> > > > >>>> Make sense to me. > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A <ash...@apache.org> > 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 > > > >>>>> > > > >>>> > > > >> > > > >> > > > > > > -- > > Sent from A Mobile Device > > >