You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <jh...@gmail.com> on 2022/05/08 22:48:41 UTC
fixVersion
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>
Re: fixVersion
Posted by Julian Hyde <jh...@gmail.com>.
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 <li...@apache.org> 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 <ru...@gmail.com> 于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 <
>> alessandro.solimando@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 <ch...@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 <
>> francischuang@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>
>>>>>
>>>>
>>>
>>
>
>
> --
>
> Best,
> Benchao Li
Re: fixVersion
Posted by Benchao Li <li...@apache.org>.
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 <ru...@gmail.com> 于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 <
> alessandro.solimando@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 <ch...@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 <
> francischuang@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>
> > > >
> > >
> >
>
--
Best,
Benchao Li
Re: fixVersion
Posted by Ruben Q L <ru...@gmail.com>.
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.solimando@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 <ch...@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 <fr...@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>
> > >
> >
>
Re: fixVersion
Posted by Alessandro Solimando <al...@gmail.com>.
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 <ch...@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 <fr...@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>
> >
>
Re: fixVersion
Posted by Chunwei Lei <ch...@gmail.com>.
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 <fr...@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>
>
Re: fixVersion
Posted by Francis Chuang <fr...@apache.org>.
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>