Re: [DISCUS] Plan the next Hive release
Just a few known issues in master: https://issues.apache.org/jira/issues/?jql=labels%20%3D%20hive-4.1.0-must%20and%20resolution%20%3D%20Unresolved To get a better view of things, we need to execute TPC-DS workload against branch-4.0.1 and master.
Re: [DISCUS] Plan the next Hive release
Hi folks, Hive-4.0 branch is a relative stable branch, so backport some fix and releasing a stable minor version based on Hive-4.0 is more reasonable to me. But as Stamatis said, `It's been already 4 months since the release of Hive 4.0.0`, I also think 4 months is a little long for waiting a minor release. The reason for not releasing the version for a long time, is mainly what Denys said `many major bug fixes are simply not being reviewed on time.` IMHO, we need to encourage more committers/contributors to take part in Hive project, including code review, doc/conf supplement, performance test and so on. Meanwhile, the minor release cycle should be less 3 months, and then we can attract more people to test the version and report issues as soon as possible, and i think the real users test are more important. Thanks, Butao Zhang Replied Message | From | Zhihua Deng | | Date | 8/1/2024 11:47 | | To | | | Subject | Re: [DISCUS] Plan the next Hive release | Hi All, Hive 4.0.1 Overview: Now there are six Hive issues that tagged with hive-4.0.1-must left un-merged to branch-4.0, most of them are resolved on the master. Regarding to TEZ-4557, a workaround in Hive is to add the missing jars to the hive.aux.jars.path, which is acceptable, from my perspective, I would like to skip including the TEZ-4557 in this release. I like the idea of cherry-picking only critical bugs and important improvements based on one major release, it can introduce less surprises, stable updates and learning cost savings. To reduce maintenance burden for the community, I think we can take some rules. For instance, Any release branch would be freeze after some time or some minors released(like the branch-4.x could be expired two years latter or after three minor releases). Regards, Zhihua On 2024/07/31 11:30:25 Denys Kuzmenko wrote: Hi Stamatis, `It's been already 4 months since the release of Hive 4.0.0`. That's true, Zhihua can give a more detailed view of things, however, the main reason is that it took a while to resolve the identified bugs. ATM the only blocking item is TEZ-4557, which might not be available until September, so we might decide to skip it or try to workaround in Hive if possible. Hive-4.0 branch was well-tested by the community and is in a much better shape than the master. For Hive-4.1 release plan was to migrate to JDK-17+ which might take more time. `Commit and release always from master.` I don't think that's a good idea as it won't solve the mentioned here reason for the change: increase release cadence I feel the current problem is the lack of support from committers, as many major bug fixes are simply not being reviewed on time. Regards, Denys
Re: [DISCUS] Plan the next Hive release
Hi All, Hive 4.0.1 Overview: Now there are six Hive issues that tagged with hive-4.0.1-must left un-merged to branch-4.0, most of them are resolved on the master. Regarding to TEZ-4557, a workaround in Hive is to add the missing jars to the hive.aux.jars.path, which is acceptable, from my perspective, I would like to skip including the TEZ-4557 in this release. I like the idea of cherry-picking only critical bugs and important improvements based on one major release, it can introduce less surprises, stable updates and learning cost savings. To reduce maintenance burden for the community, I think we can take some rules. For instance, Any release branch would be freeze after some time or some minors released(like the branch-4.x could be expired two years latter or after three minor releases). Regards, Zhihua On 2024/07/31 11:30:25 Denys Kuzmenko wrote: > Hi Stamatis, > > `It's been already 4 months since the release of Hive 4.0.0`. That's true, > Zhihua can give a more detailed view of things, however, the main reason is > that it took a while to resolve the identified bugs. > ATM the only blocking item is TEZ-4557, which might not be available until > September, so we might decide to skip it or try to workaround in Hive if > possible. > > Hive-4.0 branch was well-tested by the community and is in a much better > shape than the master. > For Hive-4.1 release plan was to migrate to JDK-17+ which might take more > time. > > `Commit and release always from master.` I don't think that's a good idea as > it won't solve the mentioned here reason for the change: increase release > cadence > > I feel the current problem is the lack of support from committers, as many > major bug fixes are simply not being reviewed on time. > > Regards, > Denys > >
Re: [DISCUS] Plan the next Hive release
Hi Stamatis, `It's been already 4 months since the release of Hive 4.0.0`. That's true, Zhihua can give a more detailed view of things, however, the main reason is that it took a while to resolve the identified bugs. ATM the only blocking item is TEZ-4557, which might not be available until September, so we might decide to skip it or try to workaround in Hive if possible. Hive-4.0 branch was well-tested by the community and is in a much better shape than the master. For Hive-4.1 release plan was to migrate to JDK-17+ which might take more time. `Commit and release always from master.` I don't think that's a good idea as it won't solve the mentioned here reason for the change: increase release cadence I feel the current problem is the lack of support from committers, as many major bug fixes are simply not being reviewed on time. Regards, Denys
Re: [DISCUS] Plan the next Hive release
Hi all, It's been already 4 months since the release of Hive 4.0.0 and master is already 163 ahead. Based on the initial discussion we would like to cut a release from master every 3-4 months and it seems that we are already behind schedule. Instead of focusing on releasing from master we opted to do a smaller release from branch-4.0 (4.0.1) which so far has accumulated 28 commits. The original idea was this to be a quick release but as it turns out things keep accumulating so the argument of having few and small fixes that are easy to test fades away. I will resurface the suggestion that I brought up in the past about cutting releases only from the master branch and I would like to propose the following high-level model. * Commit and release always from master. * Release regularly (every ~3months). * Follow semantic versioning (major.minor.patch); by default we bump minor digit. * Finalize version digit bump based on the content when preparing the release candidate. * Strive to minimize major version bumps by guarding risky/breaking changes using configuration flags (we are already doing this more or less). * Stop maintenance releases; every new release subsumes the previous one. The above are not set in stone and we can iterate on it till we have something that makes everyone happy. I am proposing this model mainly for two reasons: * increase release cadence; * reduce maintenance burden for the community. Looking forward to your thoughts. Best, Stamatis On 2024/04/18 12:33:48 Denys Kuzmenko wrote: > The idea is to cherry-pick individual bug fixes/improvements that could be > easily tested to avoid a complete release test cycle (TPC-DS performance > suite, multi-db tests, etc) > > On 2024/04/18 11:22:09 Stamatis Zampetakis wrote: > > There are also many projects that never create minor version releases; > > it's up to each project to decide what fits best on each occasion. > > > > I am not against minor releases nor suggest that this should be the > > way to go for every release from now onwards. I am just saying that at > > this point in time I don't see a big benefit to release from side > > branches. > > > > Again the motivation for releasing early and often from master is that > > it has less maintenance overhead for the community and the end-users > > can benefit from all improvements as soon as possible. Certainly if we > > introduce breaking changes and big risky features this approach cannot > > work. > > > > Anyways, I am glad that we are having this discussion and it's also > > very positive that we are talking about a new release in less than a > > month since 4.0.0 came out. No matter if it is 4.0.1 or 4.1.0 I am > > fully onboard and happy to help as much as I can :) > > > > Best, > > Stamatis > > > > On Thu, Apr 18, 2024 at 11:53 AM Denys Kuzmenko > > wrote: > > > > > > Hi Stamatis, > > > > > > That is the standard practice to create minor version release for > > > bugfixes. Many upstream projects follow that same strategy, check Iceberg > > > for example. > > > > > > Regards, > > > Denys > > > > > > On 2024/04/18 07:49:59 Stamatis Zampetakis wrote: > > > > The 4.0.0 release was quite recent so I assume we don't have major > > > > breaking changes in there at the moment so we could cut the release > > > > directly from master as soon as we want. HIVE-28166 is already merged > > > > so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in. > > > > > > > > The experience shows that we are not very good at maintaining multiple > > > > release branches so in general I would prefer to focus on releasing > > > > only from master for the time being. Hive is a quite mature project so > > > > in principle breaking changes should be rather rare which gives us a > > > > bit of margin. I think a scheme where we backport less and release > > > > more is preferable. > > > > > > > > Best, > > > > Stamatis > > > > > > > > On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena wrote: > > > > > > > > > > Hi Stamatis, > > > > > The plan is to have a release line cut from the branch-4.0, So, we > > > > > plan to pull in some critical bug fixes & improvements into the 4.0.1 > > > > > release and have a quicker release. > > > > > As of now we are just putting the label "hive-4.0.1-must" on the > > > > > tickets and we plan to make sure those get c-picked to the release > > > > > line. AFAIK we haven't started committing to any branch yet, was > > > > > waiting if anyone feels differently, so we can hold back if you have > > > > > concerns or take a different approach as well. > > > > > > > > > > From CI you mean to say the daily builds? else if you create a PR > > > > > targeting to branch-4.0, it will run the entire test suite I believe? > > > > > In the meantime I will update the instructions regarding the target > > > > > branch & the label if anyone wants that a particular ticket to be > > > > > part of the 4.0.1 release. > > > > > > > > > > -Ayush > > > > > > > > > > On
Re: [DISCUS] Plan the next Hive release
The idea is to cherry-pick individual bug fixes/improvements that could be easily tested to avoid a complete release test cycle (TPC-DS performance suite, multi-db tests, etc) On 2024/04/18 11:22:09 Stamatis Zampetakis wrote: > There are also many projects that never create minor version releases; > it's up to each project to decide what fits best on each occasion. > > I am not against minor releases nor suggest that this should be the > way to go for every release from now onwards. I am just saying that at > this point in time I don't see a big benefit to release from side > branches. > > Again the motivation for releasing early and often from master is that > it has less maintenance overhead for the community and the end-users > can benefit from all improvements as soon as possible. Certainly if we > introduce breaking changes and big risky features this approach cannot > work. > > Anyways, I am glad that we are having this discussion and it's also > very positive that we are talking about a new release in less than a > month since 4.0.0 came out. No matter if it is 4.0.1 or 4.1.0 I am > fully onboard and happy to help as much as I can :) > > Best, > Stamatis > > On Thu, Apr 18, 2024 at 11:53 AM Denys Kuzmenko wrote: > > > > Hi Stamatis, > > > > That is the standard practice to create minor version release for bugfixes. > > Many upstream projects follow that same strategy, check Iceberg for example. > > > > Regards, > > Denys > > > > On 2024/04/18 07:49:59 Stamatis Zampetakis wrote: > > > The 4.0.0 release was quite recent so I assume we don't have major > > > breaking changes in there at the moment so we could cut the release > > > directly from master as soon as we want. HIVE-28166 is already merged > > > so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in. > > > > > > The experience shows that we are not very good at maintaining multiple > > > release branches so in general I would prefer to focus on releasing > > > only from master for the time being. Hive is a quite mature project so > > > in principle breaking changes should be rather rare which gives us a > > > bit of margin. I think a scheme where we backport less and release > > > more is preferable. > > > > > > Best, > > > Stamatis > > > > > > On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena wrote: > > > > > > > > Hi Stamatis, > > > > The plan is to have a release line cut from the branch-4.0, So, we plan > > > > to pull in some critical bug fixes & improvements into the 4.0.1 > > > > release and have a quicker release. > > > > As of now we are just putting the label "hive-4.0.1-must" on the > > > > tickets and we plan to make sure those get c-picked to the release > > > > line. AFAIK we haven't started committing to any branch yet, was > > > > waiting if anyone feels differently, so we can hold back if you have > > > > concerns or take a different approach as well. > > > > > > > > From CI you mean to say the daily builds? else if you create a PR > > > > targeting to branch-4.0, it will run the entire test suite I believe? > > > > In the meantime I will update the instructions regarding the target > > > > branch & the label if anyone wants that a particular ticket to be part > > > > of the 4.0.1 release. > > > > > > > > -Ayush > > > > > > > > On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis > > > > wrote: > > > >> > > > >> Thanks for starting the discussion Ayush. > > > >> > > > >> Having frequent releases is definitely needed so we should keep the > > > >> momentum going. > > > >> > > > >> I had the impression from other threads that the next Hive release > > > >> would be 4.1.0 and that it would be cut from master. I would like to > > > >> understand how 4.0.1 is different and if it is, what is the > > > >> contribution pattern that contributors and committers should follow? > > > >> If the idea is to maintain and commit in two (or more) branches the > > > >> steps should be documented and CI should be running on those branches. > > > >> > > > >> Best, > > > >> Stamatis > > > >> > > > >> On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko > > > >> wrote: > > > >> > > > > >> > We might need it sooner as identified some critical issues in the > > > >> > recent code: > > > >> > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name > > > >> > and operates on a main; > > > >> > 2. HIVE-28190: Materialized view rebuild lock heart-beating is > > > >> > broken; > > > >
Re: [DISCUS] Plan the next Hive release
There are also many projects that never create minor version releases; it's up to each project to decide what fits best on each occasion. I am not against minor releases nor suggest that this should be the way to go for every release from now onwards. I am just saying that at this point in time I don't see a big benefit to release from side branches. Again the motivation for releasing early and often from master is that it has less maintenance overhead for the community and the end-users can benefit from all improvements as soon as possible. Certainly if we introduce breaking changes and big risky features this approach cannot work. Anyways, I am glad that we are having this discussion and it's also very positive that we are talking about a new release in less than a month since 4.0.0 came out. No matter if it is 4.0.1 or 4.1.0 I am fully onboard and happy to help as much as I can :) Best, Stamatis On Thu, Apr 18, 2024 at 11:53 AM Denys Kuzmenko wrote: > > Hi Stamatis, > > That is the standard practice to create minor version release for bugfixes. > Many upstream projects follow that same strategy, check Iceberg for example. > > Regards, > Denys > > On 2024/04/18 07:49:59 Stamatis Zampetakis wrote: > > The 4.0.0 release was quite recent so I assume we don't have major > > breaking changes in there at the moment so we could cut the release > > directly from master as soon as we want. HIVE-28166 is already merged > > so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in. > > > > The experience shows that we are not very good at maintaining multiple > > release branches so in general I would prefer to focus on releasing > > only from master for the time being. Hive is a quite mature project so > > in principle breaking changes should be rather rare which gives us a > > bit of margin. I think a scheme where we backport less and release > > more is preferable. > > > > Best, > > Stamatis > > > > On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena wrote: > > > > > > Hi Stamatis, > > > The plan is to have a release line cut from the branch-4.0, So, we plan > > > to pull in some critical bug fixes & improvements into the 4.0.1 release > > > and have a quicker release. > > > As of now we are just putting the label "hive-4.0.1-must" on the tickets > > > and we plan to make sure those get c-picked to the release line. AFAIK we > > > haven't started committing to any branch yet, was waiting if anyone feels > > > differently, so we can hold back if you have concerns or take a different > > > approach as well. > > > > > > From CI you mean to say the daily builds? else if you create a PR > > > targeting to branch-4.0, it will run the entire test suite I believe? In > > > the meantime I will update the instructions regarding the target branch & > > > the label if anyone wants that a particular ticket to be part of the > > > 4.0.1 release. > > > > > > -Ayush > > > > > > On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis > > > wrote: > > >> > > >> Thanks for starting the discussion Ayush. > > >> > > >> Having frequent releases is definitely needed so we should keep the > > >> momentum going. > > >> > > >> I had the impression from other threads that the next Hive release > > >> would be 4.1.0 and that it would be cut from master. I would like to > > >> understand how 4.0.1 is different and if it is, what is the > > >> contribution pattern that contributors and committers should follow? > > >> If the idea is to maintain and commit in two (or more) branches the > > >> steps should be documented and CI should be running on those branches. > > >> > > >> Best, > > >> Stamatis > > >> > > >> On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko > > >> wrote: > > >> > > > >> > We might need it sooner as identified some critical issues in the > > >> > recent code: > > >> > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name > > >> > and operates on a main; > > >> > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken; > >
Re: [DISCUS] Plan the next Hive release
Hi Stamatis, That is the standard practice to create minor version release for bugfixes. Many upstream projects follow that same strategy, check Iceberg for example. Regards, Denys On 2024/04/18 07:49:59 Stamatis Zampetakis wrote: > The 4.0.0 release was quite recent so I assume we don't have major > breaking changes in there at the moment so we could cut the release > directly from master as soon as we want. HIVE-28166 is already merged > so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in. > > The experience shows that we are not very good at maintaining multiple > release branches so in general I would prefer to focus on releasing > only from master for the time being. Hive is a quite mature project so > in principle breaking changes should be rather rare which gives us a > bit of margin. I think a scheme where we backport less and release > more is preferable. > > Best, > Stamatis > > On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena wrote: > > > > Hi Stamatis, > > The plan is to have a release line cut from the branch-4.0, So, we plan to > > pull in some critical bug fixes & improvements into the 4.0.1 release and > > have a quicker release. > > As of now we are just putting the label "hive-4.0.1-must" on the tickets > > and we plan to make sure those get c-picked to the release line. AFAIK we > > haven't started committing to any branch yet, was waiting if anyone feels > > differently, so we can hold back if you have concerns or take a different > > approach as well. > > > > From CI you mean to say the daily builds? else if you create a PR targeting > > to branch-4.0, it will run the entire test suite I believe? In the meantime > > I will update the instructions regarding the target branch & the label if > > anyone wants that a particular ticket to be part of the 4.0.1 release. > > > > -Ayush > > > > On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis wrote: > >> > >> Thanks for starting the discussion Ayush. > >> > >> Having frequent releases is definitely needed so we should keep the > >> momentum going. > >> > >> I had the impression from other threads that the next Hive release > >> would be 4.1.0 and that it would be cut from master. I would like to > >> understand how 4.0.1 is different and if it is, what is the > >> contribution pattern that contributors and committers should follow? > >> If the idea is to maintain and commit in two (or more) branches the > >> steps should be documented and CI should be running on those branches. > >> > >> Best, > >> Stamatis > >> > >> On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko > >> wrote: > >> > > >> > We might need it sooner as identified some critical issues in the recent > >> > code: > >> > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and > >> > operates on a main; > >> > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken; >
Re: [DISCUS] Plan the next Hive release
The 4.0.0 release was quite recent so I assume we don't have major breaking changes in there at the moment so we could cut the release directly from master as soon as we want. HIVE-28166 is already merged so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in. The experience shows that we are not very good at maintaining multiple release branches so in general I would prefer to focus on releasing only from master for the time being. Hive is a quite mature project so in principle breaking changes should be rather rare which gives us a bit of margin. I think a scheme where we backport less and release more is preferable. Best, Stamatis On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena wrote: > > Hi Stamatis, > The plan is to have a release line cut from the branch-4.0, So, we plan to > pull in some critical bug fixes & improvements into the 4.0.1 release and > have a quicker release. > As of now we are just putting the label "hive-4.0.1-must" on the tickets and > we plan to make sure those get c-picked to the release line. AFAIK we haven't > started committing to any branch yet, was waiting if anyone feels > differently, so we can hold back if you have concerns or take a different > approach as well. > > From CI you mean to say the daily builds? else if you create a PR targeting > to branch-4.0, it will run the entire test suite I believe? In the meantime I > will update the instructions regarding the target branch & the label if > anyone wants that a particular ticket to be part of the 4.0.1 release. > > -Ayush > > On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis wrote: >> >> Thanks for starting the discussion Ayush. >> >> Having frequent releases is definitely needed so we should keep the >> momentum going. >> >> I had the impression from other threads that the next Hive release >> would be 4.1.0 and that it would be cut from master. I would like to >> understand how 4.0.1 is different and if it is, what is the >> contribution pattern that contributors and committers should follow? >> If the idea is to maintain and commit in two (or more) branches the >> steps should be documented and CI should be running on those branches. >> >> Best, >> Stamatis >> >> On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko wrote: >> > >> > We might need it sooner as identified some critical issues in the recent >> > code: >> > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and >> > operates on a main; >> > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken;
Re: [DISCUS] Plan the next Hive release
Hi Stamatis, The plan is to have a release line cut from the branch-4.0, So, we plan to pull in some critical bug fixes & improvements into the 4.0.1 release and have a quicker release. As of now we are just putting the label "hive-4.0.1-must" on the tickets and we plan to make sure those get c-picked to the release line. AFAIK we haven't started committing to any branch yet, was waiting if anyone feels differently, so we can hold back if you have concerns or take a different approach as well. >From CI you mean to say the daily builds? else if you create a PR targeting to branch-4.0, it will run the entire test suite I believe? In the meantime I will update the instructions regarding the target branch & the label if anyone wants that a particular ticket to be part of the 4.0.1 release. -Ayush On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis wrote: > Thanks for starting the discussion Ayush. > > Having frequent releases is definitely needed so we should keep the > momentum going. > > I had the impression from other threads that the next Hive release > would be 4.1.0 and that it would be cut from master. I would like to > understand how 4.0.1 is different and if it is, what is the > contribution pattern that contributors and committers should follow? > If the idea is to maintain and commit in two (or more) branches the > steps should be documented and CI should be running on those branches. > > Best, > Stamatis > > On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko > wrote: > > > > We might need it sooner as identified some critical issues in the recent > code: > > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and > operates on a main; > > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken; >
Re: [DISCUS] Plan the next Hive release
Thanks for starting the discussion Ayush. Having frequent releases is definitely needed so we should keep the momentum going. I had the impression from other threads that the next Hive release would be 4.1.0 and that it would be cut from master. I would like to understand how 4.0.1 is different and if it is, what is the contribution pattern that contributors and committers should follow? If the idea is to maintain and commit in two (or more) branches the steps should be documented and CI should be running on those branches. Best, Stamatis On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko wrote: > > We might need it sooner as identified some critical issues in the recent code: > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and > operates on a main; > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken;
Re: [DISCUS] Plan the next Hive release
We might need it sooner as identified some critical issues in the recent code: 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and operates on a main; 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken;
Re: [DISCUS] Plan the next Hive release
+1. Thank you Ayush, for pushing things forward! I would like to volunteer for the 4.0.1 release. Thanks, Zhihua On 2024/04/09 22:30:55 Ayush Saxena wrote: > Hi All, > As we all know Hive-4.0 is released. I think we should try to maintain a > regular cadence for the 4.x release line. > So, I propose having a 4.0.1 release in the next 3 months or so, with some > critical bug fixes and improvements on top of our last 4.0.0 release. > > We would need someone to volunteer as the Release Manager as well, if folks > agree. > > Thoughts? > > -Ayush >
[DISCUS] Plan the next Hive release
Hi All, As we all know Hive-4.0 is released. I think we should try to maintain a regular cadence for the 4.x release line. So, I propose having a 4.0.1 release in the next 3 months or so, with some critical bug fixes and improvements on top of our last 4.0.0 release. We would need someone to volunteer as the Release Manager as well, if folks agree. Thoughts? -Ayush
