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 <chunwei.l...@gmail.com> 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 <francischu...@apache.org> > 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> > > >
