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 Wed, 19 Jun 2019 17:28:50 GMT
"I'm less sure about requiring that the fix version is not set before
resolving the issue"   Yeah, this aspect I don't think is particularly
important either way.  We can establish a preference to leave blank until
release time, but say Blocker issues are a good exception.

It'd be nice to have internal dev docs for us to write these down in so we
can refer to them, particularly to share with new committers as well.  Were
you planning to do this Jan?

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


On Wed, Jun 19, 2019 at 12:22 PM Mark Miller <markrmiller@gmail.com> wrote:

> Can we address this in JIRA? In the past I've seen this handled in JIRA by
> also having a 'target' version field - this is the intended version you
> want to land in and you set it right away. Things were configured so you
> could only set the fix version when you resolved I think. Then you would
> use target for release blockers and such. Fix would just tell you what it's
> actually in.
>
> On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand <jpountz@gmail.com> wrote:
>
>> +1 to Jan's proposal about not adding master when changes are also pushed
>> to the previous major, I like the additional consistency with our
>> CHANGES.txt.
>>
>> I'm less sure about requiring that the fix version is not set before
>> resolving the issue, I have used this in combination with the blocker label
>> to mean that an issue needs to be addressed before releasing, sometimes it
>> will be the next minor, sometimes the next major. For the record, the
>> ReleaseTodo[1] recommends to check for blockers by filtering by priority
>> and fixVersion.
>>
>> [1] https://wiki.apache.org/lucene-java/ReleaseTodo
>>
>> On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <gus.heck@gmail.com> wrote:
>>
>>> FWIW I tend to agree with Erick here on both his points, but the second
>>> one more strongly than the first. The first I can live with either way
>>> really so long as it's clearly documented somewhere (besides this thread).
>>>
>>> If we don't update the changes in master for bug fixes when we're
>>> committing, who's going to go collect and add them later? I'm not sure I'm
>>> that big a fan of generating changes... I haven't looked at Yetus
>>> specifically but I suspect that this will just leave us with the title from
>>> the Jira, and often some additional detail for changes is worthwhile beyond
>>> what the title says. So if we create a field in Jira that is the Changes
>>> text, and make it required in the resolution screen fine to generate from
>>> that, but I think there's real value in the current system because you wind
>>> up writing a final short 1-4 line summary focused on "what the user needs
>>> to know"
>>>
>>> Also line 3, the feature only in 8x (but not master) is a very odd case
>>> in that table, I'm not sure when that would happen? could happen for a bug
>>> that is fixed by other changes in master, but for a feature?
>>>
>>> Also if we aren't marking branches explicitly maybe the 9.0 (master) tag
>>> should say 9.0 (unreleased)? Sure most developers know master is typically
>>> unreleased, but why add that mental leap. It's possible that someone less
>>> technical, or who is a student will stumble in from a link on SO...
>>>
>>> -Gus
>>>
>>> On Thu, Jun 13, 2019 at 3:23 PM David Smiley <david.w.smiley@gmail.com>
>>> wrote:
>>>
>>>> +1 to your plan Jan.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <jan.asf@cominvent.com>
>>>> wrote:
>>>>
>>>>> Trying to reach a conclusion (or perhaps a vote) on this.
>>>>>
>>>>> Here is a table that sums up my proposal. Basically it means in most
>>>>> cases stop adding master as fixVersion.
>>>>>
>>>>> Type Committed to fixVersion CHANGES.txt section
>>>>> Feature master master (9.0) 9.0
>>>>> Feature master, branch_8x 8.2 8.2
>>>>> Feature branch_8x 8.2 8.2
>>>>> Bugfix master master (9.0) none (unreleased bug)
>>>>> Bugfix master, branch_8x 8.2 8.2
>>>>> Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2
>>>>> Bugfix branch_8x 8.2 8.2
>>>>> Bugfix branch_8_1 8.1.2 8.1.2
>>>>> Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2
>>>>>
>>>>> In addition to this, we should all wait until commit time with setting
>>>>> fixVersion.
>>>>>
>>>>> To find branches for a JIRA, you just translate fixVersion to branch,
>>>>> e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x.
>>>>> For features, if it is unclear whether master has the commit, check
>>>>> gitbot log or git log
>>>>> For bugfixes, there are cases where the bug does not exist in master
>>>>> at all, and that can be reflected in affectsVersion field.
>>>>>
>>>>> --
>>>>> Jan Høydahl, search solution architect
>>>>> Cominvent AS - www.cominvent.com
>>>>>
>>>>> 3. jun. 2019 kl. 19:56 skrev David Smiley <david.w.smiley@gmail.com>:
>>>>>
>>>>> Right.... JIRA fixVersion has its use, and that would satisfy this
>>>>> use-case?  It's what Jan proposes to do this very thing as part of
>>>>> generating release notes in a semi-automated way.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <
>>>>> erickerickson@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> > On Jun 3, 2019, at 6:41 AM, David Smiley <david.w.smiley@gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > If someone wants to know what branches an issue was committed
to,
>>>>>> then review the bot comments to find out.
>>>>>>
>>>>>> What if I want to form a query that shows me all JIRAs fixed in
>>>>>> version X.Y.Z?
>>>>>>
>>>>>> A bot comments with “branch_5x” doesn’t tell me which minor
version
>>>>>> it’s in, 5.1? 5.5?
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
>>
>> --
>> Adrien
>>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>

Mime
View raw message