lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Use of JIRA fixVersion
Date Wed, 19 Jun 2019 16:22:39 GMT
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