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 < alessandro.solima...@gmail.com> 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 <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> > > > > > >
