Re: [DISCUSS] EOL branch-1.3
+1, the less, the better. Best Regards Allan Yang Sean Busbey 于2018年12月8日周六 上午10:09写道： > correct, branch-1.2 was the stable release line prior to 1.4 becoming > it in August. > > at the time I said I'd keep making monthly 1.2.z releases for ~6 months: > > https://s.apache.org/EYkB > > I wanted to give folks who heed our "this is the stable line" advice a > cushion for planning migration once we updated it to a different > release line. > On Fri, Dec 7, 2018 at 7:57 PM Guanghao Zhang wrote: > > > > +1. But branch-1.2 is not EOL now? > > > > 张铎(Duo Zhang) 于2018年12月8日周六 上午9:28写道： > > > > > +1. > > > > > > Andrew Purtell 于2018年12月8日周六 上午5:45写道： > > > > > > > I'm good with doing one more 1.3 release. It would be my pleasure to > > > offer > > > > that service to the community. I like RM-ing. > > > > > > > > > > > > On Fri, Dec 7, 2018 at 12:29 PM Stack wrote: > > > > > > > > > +1 > > > > > > > > > > (Pity you have to make a release to EOL it). > > > > > > > > > > S > > > > > > > > > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell < > apurt...@apache.org> > > > > > wrote: > > > > > > > > > > > We haven't had a release from branch-1.3 for a long time and do > not > > > > > appear > > > > > > to have an active RM for it. Unless a RM for 1.3 steps forward > and > > > > > promises > > > > > > to make a release in the very near future, I propose we make one > more > > > > > > release of 1.3, from the head of branch-1.3, and then retire the > > > > branch. > > > > > If > > > > > > this is acceptable I can RM the final 1.3 release. > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Andrew > > > > > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > > > truth's > > > > > > decrepit hands > > > > > >- A23, Crosstalk > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Andrew > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > truth's > > > > decrepit hands > > > >- A23, Crosstalk > > > > > > > >
Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly
I think Andrew's way makes sense for branch-1, we can release 1.6,1.7 and so on directly on branch-1. Since in branch-1, we will only have bug fixes. If we want to apply this policy to branch-2, we'd be careful when new functions check in, because all feature releases will include this function if we only have a branch-2. But good news is that we only need to commit our code to one branch, for now, sometimes I need to commit to four branches(branch-2.0, branch-2.1, branch-2 and master). And for users, they don't have to make difficult chose about which release line they need to use. And they don't have to consider about compatibility when upgrading a minor version. We make sure all the Incompatible changes are only commit to master branch(for releasing 3.x). Best Regards Allan Yang Stack 于2018年12月9日周日 上午7:35写道： > On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell wrote: > > > We could do that. Or we could simply renumber branch-1 to 1.6.x at that > > time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a > tag > > in rel/. It is possible at any time to check out from a release tag and > > make a branch for an additional patch release for an old minor line. If > we > > need to do it, we can at that time, otherwise why proliferate branches > and > > make more work for committers? I think for branch-1 after moving from > > 1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely, > and > > going forward for 1.6, and so on. This same policy could work for > branch-2. > > We shouldn't be afraid to make new minors. Prior to 1.0.0 every release > was > > a minor release and patch releases were rare. I think we want to get back > > to something more like that. > > > > It also makes sense to have a long term stable branch. That is currently > > branch-1.2. If in the future we want it to be 1.5, then at that time it > > makes sense to have a separate branch-1.5 for the LTS. > > > > > Let's try it. > > Should be easy to do on branch-1 what with a single 'owner'. > > branch-2 would prove a more interesting experiment. Let branch-2 be where > we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2) > > S > > > > > > > > On Fri, Dec 7, 2018 at 5:54 PM 张铎(Duo Zhang) > > wrote: > > > > > If 1.5 is not the last minor release line, then how do we release 1.6? > > Make > > > a branch-1.5 and then start to release 1.6 from branch-1? > > > > > > Andrew Purtell 于2018年12月8日周六 上午9:36写道： > > > > > > > Yeah, for branch-1 it is no longer a development branch. Every change > > is > > > > going to be maintenance related. No, I don't expect 1.5 to be the > last > > > > minor release line for 1.x. Maybe? Maybe not. In theory we could > treat > > > > branch-2 the same. Master is the only development branch. That is not > > my > > > > proposal, though. I'm only concerned with RM activities related to > > > > branch-1. > > > > > > > > On Fri, Dec 7, 2018 at 5:33 PM 张铎(Duo Zhang) > > > > wrote: > > > > > > > > > So the idea is that, if we have a newer major release line, we can > > > > release > > > > > the previous major releases directly from the 'developing' branch? > > > > > > > > > > I think for branch-1 it is fine, as we are not likely to backport > any > > > big > > > > > new feature to 1.x any more. And does this mean that 1.5 is the > last > > > > minor > > > > > release line for 1.x? > > > > > > > > > > Stack 于2018年12月8日周六 上午4:15写道： > > > > > > > > > > > On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell < > > apurt...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Please be advised I plan to RM the next minor release from > > > branch-1, > > > > > > 1.5.0, > > > > > > > in January of 2019. Once this is done we can continue making > > > > > maintenance > > > > > > > releases from branch-1.4 as needed but expect that not to be > > > > necessary > > > > > > > after a couple of months (or perhaps even immediately). > > > > > > > > > > > > > > I see no need to make a branch-1.5. As community resources > > continue > > > > to > > > > > > > shift away from branch-1 we need to conserve available > > attention. I > > > > > don't > > > > > > > see why we cannot release directly from branch-1. Certainly in > > the > > > > > > > beginning any branch-1.5 would be lock step with branch-1. No > > > > > distinction > > > > > > > in branch curation means no need for a new branch, at least > > > > initially. > > > > > > > Also, should a commit land in branch-1 that requires a new > minor > > > per > > > > > our > > > > > > > compatibility guidelines then I don't see why the next release > > from > > > > > > > branch-1 cannot a new minor (1.6.0, etc.) right there and then. > > We > > > > have > > > > > > > expressed intent to make more frequent minor releases anyhow. > > > > > > > > > > > > > > Related, I started a DISCUSS thread about EOL of branch-1.3. > > > > > > > > > > > > > > In my opinion the optimal future for branch-1, until all > > attention > > > > > moves > > > > > > > away from it, is
Re: [DISCUSS] move to gitbox
Sounds good to me except squash merge at commit of PR shouldn’t be an option it should be required except for good reason (and I don’t know what that would be ) > On Dec 8, 2018, at 3:28 PM, Stack wrote: > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote: >> >> The move to gitbox doesn't require us to only accept github PRs. Given >> the current rate of contributions via patches on JIRA vs GitHub PRs, I >> wouldn't want to push for that now. >> >> The change does make it easier for us to start encouraging PR >> submissions, because committers will be able to directly merge from >> the GitHub UI. >> >> I'd recommend we try to keep this as a small incremental change. That >> would mean: >> >> * committers ensure there's an associated JIRA for release note and >> precommit checks (that can be just by pinging the contributor to go >> make one) >> * backports are still handled by the committer if they're simple and >> the contributor if there's a problem. I think saying "open a new PR to >> backport to branch FOO" is perfectly reasonable since it's analogous >> to when we ask contributors to attach a branch specific patch. >> * committers ensure the pushed commit has a message that follows our >> current practice (which would mean looking out for the "helpful" >> subject wrapping) >> * Squash merge is an option when the committer goes to accept the PR. >> the contributor is free to either push additional commits or squash on >> their branch when working through reviews, I don't think we need to >> weigh in on how contributors choose which of those works best for >> them. >> >> That way we can also incrementally improve how well we handle PR >> submissions by better documenting expectations and building up >> additional tooling (e.g. having our precommit feedback go directly to >> the PR instead of being tied to a JIRA) >> > > This seems reasonable to me. Andrew's strawman would be too radical a > change. > Thanks, > S > > >>> On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: >>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey wrote: Hi folks! Per the email from infra "[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) >> it looks like the future of interacting directly with PRs is coming sooner rather than later. I think we should move to gitbox ASAP rather than wait for the crunch. >> If we hit a rough spot we're more likely to get some help when things >> aren't busy. Maybe we wait until our open RCs close so that folks that need >> to tag those releases don't need to update their workflow first? Presuming everyone still agrees that we get value out of JIRA, I think >> we need update our committer guidelines to expressly remind folks to >> check on things like commit messages before merging PRs, as well as to ensure >> folks use the "squash and merge" option to keep the git history less >> complicated. Probably a good time to add text about the importance of backporting, >> since there isn't a github UI for doing that. >>> >>> >>> Sounds good. >>> >>> Use this thread to list what needs documentation? (Agree with the "Need >> to >>> sort all of this out and provide clarity now before a switch over." from >>> Andrew). >>> >>> What should the commit be like? Should be like now? What about that ugly >>> bleed that happens when the first line is too long and gets dumped into >> the >>> textbox below ... which then becomes the log IIRC. >>> >>> When do we do the squash merge? Is that the committer who does this after >>> rounds of review? >>> >>> I like Andrew's list. >>> >>> On the 'You can't fix a branch-1 issue where the code is different in >>> branch-2 and up by opening a PR against master', this is a prob. at least >>> with our current 'process'. We don't do a JIRA per push because it is >> just >>> a bunch of busy work. Do we have to do this now (any alternatives?) >>> >>> Thanks for starting this up Sean, >>> S >>
Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly
On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell wrote: > We could do that. Or we could simply renumber branch-1 to 1.6.x at that > time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag > in rel/. It is possible at any time to check out from a release tag and > make a branch for an additional patch release for an old minor line. If we > need to do it, we can at that time, otherwise why proliferate branches and > make more work for committers? I think for branch-1 after moving from > 1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely, and > going forward for 1.6, and so on. This same policy could work for branch-2. > We shouldn't be afraid to make new minors. Prior to 1.0.0 every release was > a minor release and patch releases were rare. I think we want to get back > to something more like that. > > It also makes sense to have a long term stable branch. That is currently > branch-1.2. If in the future we want it to be 1.5, then at that time it > makes sense to have a separate branch-1.5 for the LTS. > > Let's try it. Should be easy to do on branch-1 what with a single 'owner'. branch-2 would prove a more interesting experiment. Let branch-2 be where we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2) S > > > On Fri, Dec 7, 2018 at 5:54 PM 张铎(Duo Zhang) > wrote: > > > If 1.5 is not the last minor release line, then how do we release 1.6? > Make > > a branch-1.5 and then start to release 1.6 from branch-1? > > > > Andrew Purtell 于2018年12月8日周六 上午9:36写道： > > > > > Yeah, for branch-1 it is no longer a development branch. Every change > is > > > going to be maintenance related. No, I don't expect 1.5 to be the last > > > minor release line for 1.x. Maybe? Maybe not. In theory we could treat > > > branch-2 the same. Master is the only development branch. That is not > my > > > proposal, though. I'm only concerned with RM activities related to > > > branch-1. > > > > > > On Fri, Dec 7, 2018 at 5:33 PM 张铎(Duo Zhang) > > > wrote: > > > > > > > So the idea is that, if we have a newer major release line, we can > > > release > > > > the previous major releases directly from the 'developing' branch? > > > > > > > > I think for branch-1 it is fine, as we are not likely to backport any > > big > > > > new feature to 1.x any more. And does this mean that 1.5 is the last > > > minor > > > > release line for 1.x? > > > > > > > > Stack 于2018年12月8日周六 上午4:15写道： > > > > > > > > > On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell < > apurt...@apache.org> > > > > > wrote: > > > > > > > > > > > Please be advised I plan to RM the next minor release from > > branch-1, > > > > > 1.5.0, > > > > > > in January of 2019. Once this is done we can continue making > > > > maintenance > > > > > > releases from branch-1.4 as needed but expect that not to be > > > necessary > > > > > > after a couple of months (or perhaps even immediately). > > > > > > > > > > > > I see no need to make a branch-1.5. As community resources > continue > > > to > > > > > > shift away from branch-1 we need to conserve available > attention. I > > > > don't > > > > > > see why we cannot release directly from branch-1. Certainly in > the > > > > > > beginning any branch-1.5 would be lock step with branch-1. No > > > > distinction > > > > > > in branch curation means no need for a new branch, at least > > > initially. > > > > > > Also, should a commit land in branch-1 that requires a new minor > > per > > > > our > > > > > > compatibility guidelines then I don't see why the next release > from > > > > > > branch-1 cannot a new minor (1.6.0, etc.) right there and then. > We > > > have > > > > > > expressed intent to make more frequent minor releases anyhow. > > > > > > > > > > > > Related, I started a DISCUSS thread about EOL of branch-1.3. > > > > > > > > > > > > In my opinion the optimal future for branch-1, until all > attention > > > > moves > > > > > > away from it, is continuing releases directly from branch-1 and > > > perhaps > > > > > > branch-1.2 (depends on Busbey's plans for it). > > > > > > > > > > > > If you would prefer we continue to make new branches for minor > code > > > > > lines, > > > > > > I can do that for 1.5, no problem, but perhaps you will agree it > is > > > no > > > > > > longer necessary. > > > > > > > > > > > > > > > > > > Agree. > > > > > > > > > > I also like the idea of doing same thing for branch-2. > > > > > > > > > > S > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Andrew > > > > > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > > > truth's > > > > > > decrepit hands > > > > > >- A23, Crosstalk > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning
Re: [DISCUSS] move to gitbox
On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote: > The move to gitbox doesn't require us to only accept github PRs. Given > the current rate of contributions via patches on JIRA vs GitHub PRs, I > wouldn't want to push for that now. > > The change does make it easier for us to start encouraging PR > submissions, because committers will be able to directly merge from > the GitHub UI. > > I'd recommend we try to keep this as a small incremental change. That > would mean: > > * committers ensure there's an associated JIRA for release note and > precommit checks (that can be just by pinging the contributor to go > make one) > * backports are still handled by the committer if they're simple and > the contributor if there's a problem. I think saying "open a new PR to > backport to branch FOO" is perfectly reasonable since it's analogous > to when we ask contributors to attach a branch specific patch. > * committers ensure the pushed commit has a message that follows our > current practice (which would mean looking out for the "helpful" > subject wrapping) > * Squash merge is an option when the committer goes to accept the PR. > the contributor is free to either push additional commits or squash on > their branch when working through reviews, I don't think we need to > weigh in on how contributors choose which of those works best for > them. > > That way we can also incrementally improve how well we handle PR > submissions by better documenting expectations and building up > additional tooling (e.g. having our precommit feedback go directly to > the PR instead of being tied to a JIRA) > This seems reasonable to me. Andrew's strawman would be too radical a change. Thanks, S > On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: > > > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey wrote: > > > > > Hi folks! > > > > > > Per the email from infra "[NOTICE] Mandatory relocation of Apache git > > > repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) > it > > > looks like the future of interacting directly with PRs is coming sooner > > > rather than later. > > > > > > I think we should move to gitbox ASAP rather than wait for the crunch. > If > > > we hit a rough spot we're more likely to get some help when things > aren't > > > busy. Maybe we wait until our open RCs close so that folks that need > to tag > > > those releases don't need to update their workflow first? > > > > > > Presuming everyone still agrees that we get value out of JIRA, I think > we > > > need update our committer guidelines to expressly remind folks to > check on > > > things like commit messages before merging PRs, as well as to ensure > folks > > > use the "squash and merge" option to keep the git history less > complicated. > > > Probably a good time to add text about the importance of backporting, > since > > > there isn't a github UI for doing that. > > > > > > > > > Sounds good. > > > > Use this thread to list what needs documentation? (Agree with the "Need > to > > sort all of this out and provide clarity now before a switch over." from > > Andrew). > > > > What should the commit be like? Should be like now? What about that ugly > > bleed that happens when the first line is too long and gets dumped into > the > > textbox below ... which then becomes the log IIRC. > > > > When do we do the squash merge? Is that the committer who does this after > > rounds of review? > > > > I like Andrew's list. > > > > On the 'You can't fix a branch-1 issue where the code is different in > > branch-2 and up by opening a PR against master', this is a prob. at least > > with our current 'process'. We don't do a JIRA per push because it is > just > > a bunch of busy work. Do we have to do this now (any alternatives?) > > > > Thanks for starting this up Sean, > > S >
[jira] [Created] (HBASE-21569) Incorrect validation in check-website-links.sh
Peter Somogyi created HBASE-21569: - Summary: Incorrect validation in check-website-links.sh Key: HBASE-21569 URL: https://issues.apache.org/jira/browse/HBASE-21569 Project: HBase Issue Type: Bug Reporter: Peter Somogyi HBase Website Link Checker job [failed recently|https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179]. The if statement is incorrect to validate the generated html file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Failure: hbase.apache.org HTML Checker
This issue is with the content of index.html file. check-website-links.sh script checks for ERROR in the generated index.html and at this time the content of this html is empty. I think this is the root cause: Checking /0.94/apidocs/src-html/org/apache/hadoop/hbase/thrift/generate ... Warning: hbase.apache.org 95.216.24.32 Error: timed out reading data checking server 40.79.78.1 Processing ... writing files to link_report wrote 24 txt files wrote 22 html files wrote index file index.html The final if statement in check-website-links.sh is incorrect. Actually it should have passed at this time and failed on previous executions. On Sat, Dec 8, 2018 at 3:35 PM Sean Busbey wrote: > Hurm. No obvious why this failed. It reports a ton of bad links, but all of > the successful runs before also report a ton of them if you look at the > console output. > > On Fri, Dec 7, 2018, 23:25 Apache Jenkins Server < > jenk...@builds.apache.org > wrote: > > > Failure > > > > Either the Jenkins job failed, or (more likely) HTML errors were found. > > > > Unless the Jenkins job itself failed, the HTML and link-checking report > > for http://hbase.apache.org is available at > > > https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/artifact/link_report/index.html > > . > > > > Otherwise, see > > > https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/console > > . >
Re: Failure: hbase.apache.org HTML Checker
Hurm. No obvious why this failed. It reports a ton of bad links, but all of the successful runs before also report a ton of them if you look at the console output. On Fri, Dec 7, 2018, 23:25 Apache Jenkins Server Failure > > Either the Jenkins job failed, or (more likely) HTML errors were found. > > Unless the Jenkins job itself failed, the HTML and link-checking report > for http://hbase.apache.org is available at > https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/artifact/link_report/index.html > . > > Otherwise, see > https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/console > .
Re: [DISCUSS] move to gitbox
Today if you add a link to a PR on the main repo to a JIRA ticket and put it in patch available status, yetus should properly recognize and use it for testing. The results should go to JIRA like normal. I don't think it's gotten much testing in our setup. (And it wouldn't work on the operator tools or connectors repos because our precommit currently only knows about the main repo.) On Sat, Dec 8, 2018, 01:44 Peter Somogyi How should we verify pull requests in the new workflow? I wouldn't like to > force contributors to create a PR and also attach the same patch file to > Jira to have it tested. In case the plan is to create PR-based precommit > I'd recommend to test run it on hbase-connectors or hbase-operator tools > gitbox repositories. > > > On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey wrote: > > > Yes I definitely agree. I think that'll take some committer practice > > and I'll want to have a decent section in the ref guide to point folks > > to. On the plus side, there's a step committers have to go through to > > link their ASF ID to their GitHub profile before they can start > > merging through the GitHub UI. So if we tell folks about how to do > > that step at the same time as show them how to make sure they're > > squash merging maybe we'll avoid some mistakes. > > On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell > wrote: > > > > > > However you want to best phrase it, squash merging for commit is a > must, > > I > > > think. Depending on the contributor's style there could be 1 or 10 > > commits > > > comprising the PR. Even more than one commit for a change encompassed > by > > a > > > JIRA would make cherry picking between the branches unnecessarily > > onerous. > > > This is really the only thing I'd like to establish as very important. > > > > > > > > > On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote: > > > > > > > The move to gitbox doesn't require us to only accept github PRs. > Given > > > > the current rate of contributions via patches on JIRA vs GitHub PRs, > I > > > > wouldn't want to push for that now. > > > > > > > > The change does make it easier for us to start encouraging PR > > > > submissions, because committers will be able to directly merge from > > > > the GitHub UI. > > > > > > > > I'd recommend we try to keep this as a small incremental change. That > > > > would mean: > > > > > > > > * committers ensure there's an associated JIRA for release note and > > > > precommit checks (that can be just by pinging the contributor to go > > > > make one) > > > > * backports are still handled by the committer if they're simple and > > > > the contributor if there's a problem. I think saying "open a new PR > to > > > > backport to branch FOO" is perfectly reasonable since it's analogous > > > > to when we ask contributors to attach a branch specific patch. > > > > * committers ensure the pushed commit has a message that follows our > > > > current practice (which would mean looking out for the "helpful" > > > > subject wrapping) > > > > * Squash merge is an option when the committer goes to accept the PR. > > > > the contributor is free to either push additional commits or squash > on > > > > their branch when working through reviews, I don't think we need to > > > > weigh in on how contributors choose which of those works best for > > > > them. > > > > > > > > That way we can also incrementally improve how well we handle PR > > > > submissions by better documenting expectations and building up > > > > additional tooling (e.g. having our precommit feedback go directly to > > > > the PR instead of being tied to a JIRA) > > > > On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: > > > > > > > > > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey > > wrote: > > > > > > > > > > > Hi folks! > > > > > > > > > > > > Per the email from infra "[NOTICE] Mandatory relocation of Apache > > git > > > > > > repositories on git-wip-us.apache.org" ( > https://s.apache.org/0sfe > > ) > > > > it > > > > > > looks like the future of interacting directly with PRs is coming > > sooner > > > > > > rather than later. > > > > > > > > > > > > I think we should move to gitbox ASAP rather than wait for the > > crunch. > > > > If > > > > > > we hit a rough spot we're more likely to get some help when > things > > > > aren't > > > > > > busy. Maybe we wait until our open RCs close so that folks that > > need > > > > to tag > > > > > > those releases don't need to update their workflow first? > > > > > > > > > > > > Presuming everyone still agrees that we get value out of JIRA, I > > think > > > > we > > > > > > need update our committer guidelines to expressly remind folks to > > > > check on > > > > > > things like commit messages before merging PRs, as well as to > > ensure > > > > folks > > > > > > use the "squash and merge" option to keep the git history less > > > > complicated. > > > > > > Probably a good time to add text about the importance of > > backporting, > > > > since > > > > > > there isn't a github UI for
