Excellent Eren! On Fri, Apr 6, 2018 at 12:52 AM Eren Avsarogullari < erenavsarogull...@gmail.com> wrote:
> 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 > > > > > >
