Re: [PROPOSAL] re-cut support/1.15
Sounds great, Robert. Once your fix is on develop, no further approval is needed to backport. Use your best judgement (or feel free to discuss on the dev list if you are unsure). If backporting will take some while, add the blocks-1.15.0 label to be sure this doesn’t slip through the cracks. On May 6, 2022 at 11:17:14 AM PDT, Robert Houghton wrote: I would like GEODE-1028 [1] to be considered for support/1.15. It is a significant change to the build logic, and I think would be a benefit to inclusion in the release branch. PR to develop is available[2] Thank you, -Robert Houghton [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10283&data=05%7C01%7Conichols%40vmware.com%7C5382a71cb8c24e3c712c08da2f8ca423%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637874578340537043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XM4pI60cfPKki2BqhAZPQLdiXAhRy9bv1hghc3NFqho%3D&reserved=0 [2 ]https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7600&data=05%7C01%7Conichols%40vmware.com%7C5382a71cb8c24e3c712c08da2f8ca423%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637874578340537043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wf8pEaN3wHtpI4WoRpE%2FKrkZpoT8a7GqZgXRzu7kZl4%3D&reserved=0 From: Anthony Baker Date: Friday, May 6, 2022 at 10:19 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] annul support/1.15 Owen, with all the recent work I think we are in an excellent position to resume work on the 1.15 release. While there are a few thing still outstanding, let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you be willing to resume release manager duties? @Everyone - please chime in if you have in-progress work that you want to ship with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”). Thanks, Anthony > On Mar 16, 2022, at 2:12 PM, Owen Nichols wrote: > > Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 > a few weeks ago. I wonder if perhaps we cut the release branch prematurely? > I propose that we abandon this branch and focus on getting develop closer to > what we want to ship, then discuss re-cutting the branch. > > If this proposal is approved, I will archive support/1.15 as > support/1.15.old, revert develop's numbering to 1.15.0, and bulk-update all > Jira tickets fixed in 1.16.0 to fixed in 1.15.0 instead. Build numbering > would start from 1.15.0-build.1000 to easily distinguish pre- and post- recut. > > Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar > 21. > > Thanks, > -Geode 1.15.0 Release Manager > >
Re: [PROPOSAL] annul support/1.15
I would like GEODE-1028 [1] to be considered for support/1.15. It is a significant change to the build logic, and I think would be a benefit to inclusion in the release branch. PR to develop is available[2] Thank you, -Robert Houghton [1] https://issues.apache.org/jira/browse/GEODE-10283 [2 ]https://github.com/apache/geode/pull/7600 From: Anthony Baker Date: Friday, May 6, 2022 at 10:19 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] annul support/1.15 Owen, with all the recent work I think we are in an excellent position to resume work on the 1.15 release. While there are a few thing still outstanding, let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you be willing to resume release manager duties? @Everyone - please chime in if you have in-progress work that you want to ship with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”). Thanks, Anthony > On Mar 16, 2022, at 2:12 PM, Owen Nichols wrote: > > Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 > a few weeks ago. I wonder if perhaps we cut the release branch prematurely? > I propose that we abandon this branch and focus on getting develop closer to > what we want to ship, then discuss re-cutting the branch. > > If this proposal is approved, I will archive support/1.15 as > support/1.15.old, revert develop's numbering to 1.15.0, and bulk-update all > Jira tickets fixed in 1.16.0 to fixed in 1.15.0 instead. Build numbering > would start from 1.15.0-build.1000 to easily distinguish pre- and post- recut. > > Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar > 21. > > Thanks, > -Geode 1.15.0 Release Manager > >
Re: [PROPOSAL] re-cut support/1.15
Great news! I would be delighted to continue as Release Manager for 1.15.0. To track progress toward code-complete, I will monitor the "needsTriage" and "blocks-1.15.0" labels (for Affects Version = 1.15.0). Currently I see 1 needsTriage [1] and 2 blocks-1.15.0 [2]. [1] https://tinyurl.com/5h58766f [2] https://tinyurl.com/2p8bje4n From: Anthony Baker Date: Friday, May 6, 2022 at 10:19 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] annul support/1.15 Owen, with all the recent work I think we are in an excellent position to resume work on the 1.15 release. While there are a few thing still outstanding, let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you be willing to resume release manager duties? @Everyone - please chime in if you have in-progress work that you want to ship with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”). Thanks, Anthony > On Mar 16, 2022, at 2:12 PM, Owen Nichols wrote: > > Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 > a few weeks ago. I wonder if perhaps we cut the release branch prematurely? > I propose that we abandon this branch and focus on getting develop closer to > what we want to ship, then discuss re-cutting the branch. > > If this proposal is approved, I will archive support/1.15 as > support/1.15.old, revert develop's numbering to 1.15.0, and bulk-update all > Jira tickets fixed in 1.16.0 to fixed in 1.15.0 instead. Build numbering > would start from 1.15.0-build.1000 to easily distinguish pre- and post- recut. > > Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar > 21. > > Thanks, > -Geode 1.15.0 Release Manager > >
Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to resume work on the 1.15 release. While there are a few thing still outstanding, let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you be willing to resume release manager duties? @Everyone - please chime in if you have in-progress work that you want to ship with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”). Thanks, Anthony > On Mar 16, 2022, at 2:12 PM, Owen Nichols wrote: > > Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 > a few weeks ago. I wonder if perhaps we cut the release branch prematurely? > I propose that we abandon this branch and focus on getting develop closer to > what we want to ship, then discuss re-cutting the branch. > > If this proposal is approved, I will archive support/1.15 as > support/1.15.old, revert develop's numbering to 1.15.0, and bulk-update all > Jira tickets fixed in 1.16.0 to fixed in 1.15.0 instead. Build numbering > would start from 1.15.0-build.1000 to easily distinguish pre- and post- recut. > > Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar > 21. > > Thanks, > -Geode 1.15.0 Release Manager > >
Re: [PROPOSAL] RFC for migrating from springfox to springdoc
Spring Data for Apache Geode (and the upcoming Spring Data for VMware Tanzu GemFire) very much depends on and uses the Management REST API. From: Jinmei Liao Date: Thursday, May 5, 2022 at 5:40 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc >Does this inactivity demonstrate maturity (i.e. maybe we should remove the >@Experimental annotation) or does it indicate a failed or abandoned experiment Neither, I believe k8s is using the feature, but the inactivity simply means we haven’t allocated people to work on it. From: Owen Nichols Date: Thursday, May 5, 2022 at 5:12 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc It would be great to make the switch to springdoc. If you are willing, go for it! Slightly outside the scope of this RFC: Swagger was added as part of the @Experimental manageability REST API [1] and is used to generate API docs for each minor [2]. It looks like the API hasn’t changed much between the last few minors. Does this inactivity demonstrate maturity (i.e. maybe we should remove the @Experimental annotation) or does it indicate a failed or abandoned experiment (i.e. should we consider entirely removing all code for this feature, following the same reasoning cited for removing @Experimental protobuf [3] and @Experimental redis [4])? [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCluster%2BManagement%2BService&data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6wJx8xiZxyRJc%2B0HbOzUPn8R5b8ENNWGkpaxxXEPO9I%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCluster%2BManagement%2BService%2BRest%2BAPI&data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wtybzPIBgRo7cf4g4vqZPtGZWsmzNXQu%2BfdxnEjHEv8%3D&reserved=0 [3] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fzt7jphfjqqgkgjn010clq2wqo9vv2z6n&data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JJWpKdG8JTnhy8cBz0hY5UHXLXO6IgdjAkoR5wHky2k%3D&reserved=0 [4] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7m23h9r0tf536g414bwjsplqh1qv2ct0&data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0ZS1ASrd2ajzbl%2BKlQv6ZN3VZxVSNLGlKH1PTpmPZwA%3D&reserved=0 From: Alexander Murmann Date: Thursday, May 5, 2022 at 4:09 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc Thanks for your proposal, Patrick! I wonder if this even warrants a proposal over a PR. There seems to be neither a downside nor a realistic alternative. From: Patrick Johnson Sent: Thursday, May 5, 2022 13:39 To: dev@geode.apache.org Subject: [PROPOSAL] RFC for migrating from springfox to springdoc Hello devs! Please review this RFC: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMigration%2Bfrom%2Bspringfox%2Bto%2Bspringdoc&data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zYIOaB9SCVLjKtK9QPBJosP1XK82zazcCo7f17Sq%2FcA%3D&reserved=0 on migrating from springfox to springdoc for our swagger needs and provide any feedback you have. Review period until Friday, May 13th. —Patrick Johnson
