lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <david.w.smi...@gmail.com>
Subject Re: Use of JIRA fixVersion
Date Mon, 03 Jun 2019 13:41:28 GMT
Thanks for raising this thread Jan.  I agree with Jan's proposal -- *it is
what I already do*.  And based on some responses here, what some others do
as well.  And as some others here have stated, I agree that we should try
to only populate the fixVersion when resolving the issue (what I already
do, usually.  This isn't a big deal though; I review this on every issue
resolution that I do.

An example where fixVersion=master that led to user confusion is here:
https://issues.apache.org/jira/browse/LUCENE-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806254#comment-16806254

If someone wants to know what *branches* an issue was committed to, then
review the bot comments to find out.  This is what I do -- I trust those
comments more than I trust people to fill out JIRA metadata
accurately/meaningfully :-)

Mike Sokolov said:
> The main use I've had for this field: as a user, I want to know whether
this bug or feature has been fixed or is available in the version I am
using, and if not, which version I would need to upgrade to in order to get
it. For this use case I think it's important to list versions on each
branch it has been ported to, up to the first major version release that
included it.

Naturally this use case is important but I fail to see how our proposed
approach fails to address it.  Maybe your point is about your
intuition/assumptions on what fixVersion=7.2 (for example) *means *(to
you)?  Some will get that, and some won't... yet would be confused by also
fixVersion=master so I suppose it's impossible to satisfy everyone's
intuitions about what the semantics mean.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Jun 2, 2019 at 1:35 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> I put in the fix version after commit as well.
>
> In fact, in SOLR-11876, someone had put in a fix version involving a
> backport before I committed (which I didn't notice) and I resolved it
> without actually backporting. It caused a confusion, and resulted in a
> backport release to go out without the fix. ☹️
>
> On Sun, 2 Jun, 2019, 8:29 PM Erick Erickson, <erickerickson@gmail.com>
> wrote:
>
>> bq. Currently we tag issues with fixVersion before commit, to indicate
>> what BRANCHES we intend to commit to
>>
>> I don’t ;). In fact, I’d favor requiring this to be blank until a fix is
>> committed. There are, as you’ve found, far too many instances where it’s
>> filled in and completely inaccurate.
>>
>> What I prefer to put in the fixVersion is the version numbers of all the
>> branches I ported the fix to. There are things we put in, say, 8x that
>> never get into the next major version. How would we know which ones those
>> are?
>>
>> Can the build tool get clever with a query about requiring the JIRA to be
>> closed before using fixVersion at all?
>>
>> Erick
>>
>> > On Jun 1, 2019, at 11:58 AM, Jan Høydahl <jan.asf@cominvent.com> wrote:
>> >
>> > Currently we tag issues with fixVersion before commit, to indicate what
>> BRANCHES we intend to commit to
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Mime
View raw message