Re: [DISCUSS] Geode 1.14
Apologies if this detracts from the conversation of folks who have much more in depth knowledge of the codebase than I do- please feel free to ignore if this seems off base. As a non-committing contributor who works mostly on code outside of core Geode, it seems like an always shippable develop would go a long way towards keeping the overall process feeling healthy. It is, however, frustrating to think of Redis work (with relies only on minor changes to geode core, along with other core in another module) being hung up while unrelated bugs are worked on. Not to complicate the conversation (and please feel free to ignore if this has been considered and thrown out before), but I wonder if it would be feasible (or desirable ) to try get to a place where we could ship parts of the code base separately, as “plugins, ” while continuing to work on the overall health of the core application? From: Alexander Murmann Date: Monday, November 30, 2020 at 2:57 PM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi all, Thanks, Owen for reminding us all of this topic! I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well. Thoughts? From: Jens Deppe Sent: Wednesday, November 25, 2020 20:11 To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi Owen, Thanks for starting this conversation and especially for volunteering as Release Manager! Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical). --Jens On 11/25/20, 6:05 PM, "Owen Nichols" wrote: The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13). It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager. Below are all release dates since Geode adopted a time-based release cadence. Minor releases: 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020 1.12 branch cut Feb 4 20201.12.0 shipped Mar 31 2020 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019 1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018 Patch releases: 1.13.1shipped Nov 18 2020 1.9.2 shipped Nov 14 2019 1.9.1 shipped Sep 6 2019 I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021. -Owen From: Alexander Murmann Date: Tuesday, July 28, 2020 at 4:34 PM To: dev@geode.apache.org Subject: [PROPOSAL] Postpone Geode 1.14 Hi all, As mentioned on the previous discuss thread, I propose to hold off cutting 1.14 until we have shipped 1.13. Once we have shipped 1.13, we should discuss when we want to cut the 1.14 release. The actual ship date for Geode 1.13 is important information for that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try? Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date). To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on? From: Alexander Murmann Date: Monday, November 30, 2020 at 11:57 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi all, Thanks, Owen for reminding us all of this topic! I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well. Thoughts? From: Jens Deppe Sent: Wednesday, November 25, 2020 20:11 To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi Owen, Thanks for starting this conversation and especially for volunteering as Release Manager! Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical). --Jens On 11/25/20, 6:05 PM, "Owen Nichols" wrote: The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13). It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager. Below are all release dates since Geode adopted a time-based release cadence. Minor releases: 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020 1.12 branch cut Feb 4 20201.12.0 shipped Mar 31 2020 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019 1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018 Patch releases: 1.13.1shipped Nov 18 2020 1.9.2 shipped Nov 14 2019 1.9.1 shipped Sep 6 2019 I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021. -Owen From: Alexander Murmann Date: Tuesday, July 28, 2020 at 4:34 PM To: dev@geode.apache.org Subject: [PROPOSAL] Postpone Geode 1.14 Hi all, As mentioned on the previous discuss thread, I propose to hold off cutting 1.14 until we have shipped 1.13. Once we have shipped 1.13, we should discuss when we want to cut the 1.14 release. The actual ship date for Geode 1.13 is important information for that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
It looks like the discussion period ended Nov 25 with all comments in support, so next phase is populating the proposed codeowners file. @Robert how long do we have to populate this before you plan to formally propose activating it on develop? As prescribed I’ve submitted a PR[1] against the feature/introduce-codeowners branch to nominate myself as a code owner for areas I feel qualified to own. [1] https://github.com/apache/geode/pull/5802 From: Xiaojian Zhou Date: Friday, November 20, 2020 at 11:06 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode +1 I saw the template of splitting the geode code. Can someone nominate a few codeowners in the file as examples? On 11/20/20, 7:32 AM, "Alexander Murmann" wrote: +1 I agree with Owen's point that this will improve the experience for new contributors. It also helps people new to the community to have confidence that they got the type of review they need to feel confident to merge. I might get to reviews that are both from great committers who can review for things like coding style, test coverage etc. However, I might be unaware that neither of them know the area I am modifying particularly well. This solves this problem. I can merge with more confidence, once I got the review from the owner. From: Anthony Baker Sent: Thursday, November 19, 2020 17:55 To: dev@geode.apache.org Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode +1 I think we as a project will need to iterator on the code owners as well as the process for code owners. But this is a model that has been adopted by a number of OSS projects both within and outside of Apache. I like that it provides visibility to PR authors and associates motivated experts to review and merge changes. Anthony > On Nov 19, 2020, at 10:46 AM, Ernie Burghardt wrote: > > Perfect, then let's give this a try. > +1 > > On 11/19/20, 10:45 AM, "Robert Houghton" wrote: > >Hi Ernie, > >DRAFT PRs do not get reviewers by default, but when the draft transitions to ‘ready’, then the owners are requested to review. > > >From: Ernie Burghardt >Date: Thursday, November 19, 2020 at 9:56 AM >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode >Does GitHub allow us to limit this automated action to non-DRAFT PRs? > >On 11/18/20, 8:28 PM, "Owen Nichols" wrote: > >+1 This will greatly improve the experience for contributors. Instead of an intimidating empty list of reviewers when you submit a PR (and no ability to add reviewers, if you’re not a committer), it will be great to already have at least two reviewers automagically assigned. > >I have a small concern that initially populating this file via a flurry of PRs may result in a lot of merge conflicts with anyone else that volunteers on the same or an adjacent line. Also, since you _must_ be a committer to be a code owner, is a PR even necessary…would directly committing changes to the feature/introduce-codeowners branch be acceptable? If not, who needs to review and who can merge the PRs against the ‘introduce’ branch? > >What happens if you are the only owner for an area, can you approve your own PR? Even if the goal is two owners per area, does that mean PRs by either owner cannot be merged if the only other owner is on vacation or otherwise unavailable? > >Can we submit PRs against the ‘introduce’ branch now and they just won’t be merged before Nov 26, or do we all just need to be patient until this review period has concluded? > >From: Robert Houghton >Date: Wednesday, November 18, 2020 at 2:07 PM >To: dev@geode.apache.org >Subject: [DISCUSS] Adding CODEOWNERS to Apache Geode >Hello Devs. > >I would like to improve the quality of the pull-request reviews we see for >critical parts of the Apache Geode project. In discussions with other >committers, a (not the) big hurdle to that is getting the right eyes to >look at a given PR. To that end, I propose the adoption of GitHub's >CODEOWNERS functionality for the Apache Geode code repository. > >A discussion-document of this issue has been written up >by @upthewaterspout. Thanks Dan! > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduce%2BCodeowners%2Bfile&data=04%7C01%7Conichols%40vmware.com%7Cf74d4a3739a14482488b08d88d876687%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414959977298893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mqXRuPIVOXxjflHD2Hat0WBej%2FSlxlhOnTZ
