Re: Regarding package renaming PR#2840
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 wrote: > > > +1 - sounds good! > > > > On Thu, Apr 5, 2018 at 5:36 PM, Josh Fischer > 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 > > 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 > > > 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 > > > > > 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 > > > > > 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 > > > > > wrote: > > > > >>> > > > > Make sense to me. > > > > > > > > > > > > > > > > On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A > > 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 > > > > > >
Re: Regarding package renaming PR#2840
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 wrote: > +1 - sounds good! > > On Thu, Apr 5, 2018 at 5:36 PM, Josh Fischer 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 > 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 > > 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 > > > 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 > > > 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 > > > wrote: > > > >>> > > > Make sense to me. > > > > > > > > > > > > On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A > 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 > > >
Re: Regarding package renaming PR#2840
+1 - sounds good! On Thu, Apr 5, 2018 at 5:36 PM, Josh Fischer 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 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 > 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 > > 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 > > 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 > > wrote: > > >>> > > Make sense to me. > > > > > > > > On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 >
Re: Regarding package renaming PR#2840
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 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 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 > 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 > 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 > wrote: > >>> > Make sense to me. > > > > On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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
Re: Regarding package renaming PR#2840
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 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 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 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 wrote: >>> Make sense to me. On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 > >> >>
Re: Regarding package renaming PR#2840
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 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 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 wrote: > > > >> Make sense to me. > >> > >> > >> > >> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 > >>> > >> > >
Re: Regarding package renaming PR#2840
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 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 wrote: > >> Make sense to me. >> >> >> >> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 >>> >>
Re: Regarding package renaming PR#2840
Hi Karthik, If the purpose of “owners” is to make this change that is fine. Otherwise having official owners of code is not really the Apache Way. Identifying people who know a portion best is fine, but the whole project and Apache “own” the code now for the public good. A lot of the time projects actually remove Author tags … Perhaps Reviewers would be better than Owners. Regards, Dave > On Apr 5, 2018, at 3:02 PM, Karthik Ramasamy 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 wrote: > >> Make sense to me. >> >> >> >> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 >>> >> signature.asc Description: Message signed with OpenPGP
Re: Regarding package renaming PR#2840
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 wrote: > Make sense to me. > > > > On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 > > >
Re: Regarding package renaming PR#2840
Make sense to me. On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A 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 >
