Glad we are all on the same page. A robot is one possibility, but I also claim that it would not be much work for a release manager to resolve all fixVersion issues before making the release. Yes there are 16 issues in Avatica, but most of these are several releases old, and if we deal with them once they won’t recur.
The example cited by Francis, https://issues.apache.org/jira/browse/CALCITE-5136 <https://issues.apache.org/jira/browse/CALCITE-5136>, is a good counter-example. I created it two days ago, intentionally set the fixVersion, and justified in the comments why I set fixVersion. I don’t want fixVersion to be cleared by a robot. I want the next release manager to make a hard decision — get someone to fix the bug, hold the release, or release without fixing the issue. I expect that each RM will have to deal with a small number of such issues each release, and that’s good. Most companies keep quality high by having daily or weekly meetings where they assign those important-but-not-urgent bugs. As an open source project we don’t have those meetings as a forcing function, so we need another forcing function. Julian > On May 9, 2022, at 6:09 AM, Benchao Li <[email protected]> wrote: > > Agree with Julian. > > I would like to share how we handle this situation in Flink. We added a > robot, which will > periodically reduce priority for stale issues, and also remove the "fix > version" field too. > If the owner of the issue is still actively working on it, he should reset > the corresponding > field to be correct. > > In Calcite, we don't have such things yet. Maybe we can do it manually when > releasing. > What I am worried about is that there are too many stale issues which will > overwhelm the Release Manager. > Then I collected some statistic, here is the number: > - There are 20 open issues targeting 1.31.0 [1] > - There are 16 open issues targeting avatica-1.22.0 [2] > So, it's not much of a burden to talk to the owner whether the issue should > still be targeted > next version or not, if we do not clearly know it. > > [1] > https://issues.apache.org/jira/browse/CALCITE-4908?jql=project%20%3D%20Calcite%20%20%20%20%20%20%20AND%20%20fixVersion%20%3D%201.31.0%20and%20status%20not%20in%20(Done%2C%20Resolved%2C%20Closed)%20%20%20%20ORDER%20BY%20updated%20DESC > [2] > https://issues.apache.org/jira/browse/CALCITE-839?jql=project%20%3D%20Calcite%20%20%20%20%20%20%20%20AND%20%20fixVersion%20%3D%20avatica-1.22.0%20%20%20and%20status%20not%20in%20(Done%2C%20Resolved%2C%20Closed)%20%20%20ORDER%20BY%20updated%20DESC > > Ruben Q L <[email protected]> 于2022年5月9日周一 18:47写道： > >> In my opinion, before starting the release process for version X, the >> release manager should take a look at Jira and find any tickets with >> fixVersion=X which are not resolved, and then act on a case by case basis, >> I guess starting a discussion on each ticket comments (so that everything >> is logged) with the reporter or any other contributor which may have done >> some work on it: >> - If the ticket is considered as a "Blocker", the release process shall >> wait until it is done. >> - If the ticket is not a blocker: >> -- If it is reasonable to assume that it can be part of the next (X+1) >> release (e.g. because work has started already, just some elements are left >> to be done etc.), the fixVersion can be changed into X+1. >> -- Otherwise its fixVersion shall be cleared ("unassigned"). >> >> Similarly, to avoid reaching that point, when creating a new ticket we >> should only assign a fixVersion if it is either a blocking issue or if we >> are reasonably confident that the work will be done for said release. >> >> Best regards, >> Ruben >> >> >> >> On Mon, May 9, 2022 at 9:40 AM Alessandro Solimando < >> [email protected]> wrote: >> >>> Hello everyone, >>> to keep the process lightweight, I'd unset the fixVersion field if it did >>> not get included into the released version (and provide a comment only if >>> there was a reason/blocker other than the lack of time). >>> >>> If the ticket is really "in progress", the owner will most likely be >>> watching the ticket, be notified of the event, and they can set it back. >>> >>> If the ticket is abandoned (at least for the moment), it will be set if >> and >>> when it will be resumed. >>> >>> If we don't do that, we will turn information into noise, and this useful >>> field will start to be ignored. >>> >>> Best regards, >>> Alessandro >>> >>> On Mon, 9 May 2022 at 04:06, Chunwei Lei <[email protected]> wrote: >>> >>>> Totally agree with Julian. >>>> >>>> Maybe we can also change the status of the issue to 'IN PROGRESS' if >>>> someone is working on it. >>>> >>>> >>>> Best, >>>> Chunwei >>>> >>>> >>>> On Mon, May 9, 2022 at 7:27 AM Francis Chuang < >> [email protected]> >>>> wrote: >>>> >>>>> When releasing a version in jira, there's an option to transition >>> issues >>>>> that were not resolved for the release. >>>>> >>>>> Perhaps we need to document what we should do for this step, for >>> example >>>>> whether to set them to the next version or to unset the fixVersion >>> field. >>>>> >>>>> Looking at the list of issues for 1.22, the majority are a few years >>> old >>>>> ( >>>>> >>>> >>> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%20avatica-1.22.0 >>>> ) >>>>> >>>>> and I don't think they would make it into the next release, so >> perhaps >>>>> we can remove the fixVersion from those ones. >>>>> >>>>> I think the difficult part is to determine what to do with recently >>>>> opened issues. For example, CALCITE-5136 [1] is pretty new and it >> looks >>>>> like there will be some work on it, but at the same time we don't >>>>> exactly know if it will make it into the next release as it could >> also >>>>> fall off the radar. >>>>> >>>>> Francis >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CALCITE-5136 >>>>> >>>>> On 9/05/2022 8:48 am, Julian Hyde wrote: >>>>>> Yesterday Francis (who was release manager for the just-released >>>> Avatica >>>>> 1.21) updated the fix version of several Avatica bugs from 1.21 to >>> 1.22. >>>> I >>>>> checked a few of them[1][2][3] and saw that they have been updated >>>> several >>>>> times. Can we stop doing this? >>>>>> >>>>>> I suggest that a change in our process. Anyone updating the >>> fixVersion >>>>> field must provide a meaningful comment. >>>>>> >>>>>> In particular, if we believed that it was going to be fixed in >> 1.21, >>>> and >>>>> 1.21 was just released, then we need to justify why we believe it >> will >>> be >>>>> fixed in 1.22. Conversely, if the bug was critically important for >>> 1.21, >>>> we >>>>> need to justify why we went ahead and released 1.21 without fixing >> it. >>>>>> >>>>>> I believe that the fixVersion field is a useful tool, but it must >> be >>>>> part of a bigger conversation such as ‘I’m working on this, and I’ll >>> have >>>>> it fixed soon, so please hold the release’ or ‘this is a critical >> bug’. >>>> So >>>>> let’s have that conversation, rather than updating the field like >>> robots. >>>>>> >>>>>> Julian >>>>>> >>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-1242 < >>>>> https://issues.apache.org/jira/browse/CALCITE-1242> >>>>>> [2] https://issues.apache.org/jira/browse/CALCITE-1308 < >>>>> https://issues.apache.org/jira/browse/CALCITE-1308> >>>>>> [3] https://issues.apache.org/jira/browse/CALCITE-839 < >>>>> https://issues.apache.org/jira/browse/CALCITE-839> >>>>> >>>> >>> >> > > > -- > > Best, > Benchao Li
