lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@gmail.com>
Subject Re: Strange Solr JIRA versions (Lucene too!)
Date Fri, 26 May 2017 07:04:42 GMT
Also, this is entirely up to you guys, I can adjust to not using 6.x
-- like I said, I've had those type of discussions before and am used
to multiple ways of managing version tickets.

Dawid

On Thu, May 25, 2017 at 8:08 PM, Cassandra Targett
<casstargett@gmail.com> wrote:
> There is an API in JIRA to create and update versions. Here are the
> docs for it for the current version we're using:
> https://docs.atlassian.com/jira/REST/6.3.15/#d2e3054.
>
> Scroll down for other endpoints that might be helpful - one of them is
> to get the list of unreleased issues for a particular version.
>
> I've been able to use other issue-related API endpoints with my ASF
> JIRA login and I assume that would be true here also, but not sure
> about it.
>
>
> On Thu, May 25, 2017 at 11:43 AM, Dawid Weiss <dawid.weiss@gmail.com> wrote:
>> I don't think it can be automated -- it'd require those few manual
>> clicks in Jira. I am not a Jira expert though, perhaps it has an API
>> that does make it scriptable.
>>
>> Dawid
>>
>> On Thu, May 25, 2017 at 6:23 PM, Erick Erickson <erickerickson@gmail.com> wrote:
>>> Dawid:
>>>
>>> So can we automate this somehow? It's still extra work for the RM and
>>> if it could become a one-liner addition to the release process maybe
>>> we can make it easier.
>>>
>>> On Thu, May 25, 2017 at 8:42 AM, Dawid Weiss <dawid.weiss@gmail.com> wrote:
>>>> It's not really about wanting to tag it 6.x... It's something I got
>>>> used to very much and something that helps (me) manage which
>>>> branch(es) a given issue has been applied to. When 6.x tag is much
>>>> like "next release cut from 6.x". When doing a release 6.[next] I'd
>>>> grep for 6.x and bulk-add 6.[next] to all issues currently having 6.x,
>>>> then remove 6.x from them (so that they have a constant fix-for, no
>>>> branch included anymore).
>>>>
>>>> This process isn't the only one possible and I've had some discussions
>>>> about alternative workflows. I didn't manage to convince my
>>>> conversation partners and they failed to convince me, so I think it's
>>>> a matter of personal preference.
>>>>
>>>> The ultimate reference is the changes.txt file anyway (?).
>>>>
>>>> Dawid
>>>>
>>>> On Thu, May 25, 2017 at 5:24 PM, Mike Drob <mdrob@apache.org> wrote:
>>>>> Christine,
>>>>>
>>>>> Wow, that's fantastic. You can also pass a --grep argument to git directly.
>>>>>
>>>>> Another problem that just occurred to me though, is that we might need
to
>>>>> make updates to CHANGES files too. I'm not sure how to automate the check
>>>>> for that, since the format can be pretty messy.
>>>>>
>>>>> Mike
>>>>>
>>>>> On Thu, May 25, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/ LONDON)
>>>>> <cpoerschke@bloomberg.net> wrote:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Perhaps a little more context would help get us all on the same page
re:
>>>>>> the "to 6.x or to not 6.x" tag question.
>>>>>>
>>>>>> === "to 6.x" tag ===
>>>>>>
>>>>>> So, some of us (myself included) for SOLR issues used to tag FixVersion
>>>>>> 6.x since the commit was to branch_6x and (at least myself) assumed
that
>>>>>> when branch_6_7 is cut from branch_6x then the process would somehow
>>>>>> magically turn 6.x tags into 6.7 tags, and any subsequently added
6.x tags
>>>>>> become 6.8 in future etc.
>>>>>>
>>>>>> The 6.x to 6.7 transition would be an extra part of the release process
>>>>>> and if/since it isn't actually a part of the process then it's
>>>>>> retrospectively really really tedious to resolve 6.x to the correct
>>>>>> 6.something tag.
>>>>>>
>>>>>> === "to not 6.x" tag ===
>>>>>>
>>>>>> An alternative is always tag to a specific (future) version i.e.
to _not_
>>>>>> 6.x tag anything and to let the released/unreleased categorisation
take care
>>>>>> of the already-released vs. scheduled-to-be-released difference.
>>>>>>
>>>>>> === where we are now ===
>>>>>>
>>>>>> There are still some tickets tagged to 6.x and people looking at
the
>>>>>> version dropdown choices will see 6.x as an existing choice. If/When
no
>>>>>> tickets are tagged to 6.x anymore then the 6.x choice could be removed
from
>>>>>> the dropdown choices leaving only specific versions to choose from.
>>>>>>
>>>>>> Having said all that, turning existing 6.x tagging into specific
versions
>>>>>> is tedious but not totally impossible, I did a few yesterday using
simple
>>>>>> git grep lookups:
>>>>>>
>>>>>> what=LUCENE-NNNN
>>>>>> for version in 0 1 2 3 4 5 6 ; do
>>>>>> echo branch_6_$version
>>>>>> git log --decorate --oneline --graph origin/branch_6_$version | grep
$what
>>>>>> done
>>>>>>
>>>>>> Hope that helps? What do people think?
>>>>>>
>>>>>> Christine
>>>>>>
>>>>>> From: dev@lucene.apache.org At: 05/25/17 14:08:37
>>>>>> To: dev@lucene.apache.org, dawid.weiss@gmail.com, jpountz@apache.org,
>>>>>> lucene@mikemccandless.com, kwright@apache.org, uwe@thetaphi.de
>>>>>> Subject: Re: Strange Solr JIRA versions (Lucene too!)
>>>>>>
>>>>>> Lucene devs, lets get on the same page about this issue.
>>>>>>
>>>>>> Dawid seems to _want_ to use 6.x
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/LUCENE-7841?focusedCommentId=16024639&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16024639
>>>>>> Christine and I are the only ones to have commented about this pertaining
>>>>>> to LUCENE JIRA issues.  Lets have this conversation here, not on
>>>>>> LUCENE-7841.
>>>>>>
>>>>>> ~ David
>>>>>>
>>>>>> On Thu, May 25, 2017 at 1:28 AM David Smiley <david.w.smiley@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Aha; this problem is a little more than a nuisance... it seems
to be why
>>>>>>> most of these issues are marked Resolved and not Closed as well.
 The RM's
>>>>>>> release process is to search for JIRA issues with a fix version
of the
>>>>>>> release version (i.e. 6.6 NOT 6.x).  Issues that do not have
a real version
>>>>>>> then fall through the cracks and remain in a "Resolved" limbo/ambiguity:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved)%20AND%20fixVersion%20%3D%206.x%20ORDER%20BY%20fixVersion%20ASC%2C%20assignee%20ASC
>>>>>>> And thus it's unclear to users browsing these issues in JIRA
for which
>>>>>>> version the issue was released in.
>>>>>>>
>>>>>>> ~ David
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 24, 2017 at 11:16 AM David Smiley <david.w.smiley@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It seems this issue applies to Lucene too, and it's more
widespread (79
>>>>>>>> issues):
>>>>>>>>
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%20branch_6x)
>>>>>>>>
>>>>>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>>>>>> <casstargett@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I noticed these the other day also, and had an email
half-wrote that I
>>>>>>>>> intended to finish up today.
>>>>>>>>>
>>>>>>>>> To start, JIRA unfortunately makes this really easy to
make a mess of
>>>>>>>>> - if you can create or edit an issue, you can just pop
in a new value
>>>>>>>>> that gets added to the list of open versions. Editing
an issue is open
>>>>>>>>> to lots of folks - committers, contributors, the reporter
of an issue.
>>>>>>>>> So, we have high potential for this to be an ongoing
problem.
>>>>>>>>>
>>>>>>>>> But, since only committers can commit patches and are
thus the usual
>>>>>>>>> resolvers of an issue, committers either aren't paying
enough
>>>>>>>>> attention to that field when they resolve an issue or
there is
>>>>>>>>> confusion/difference of understanding about what that
field is
>>>>>>>>> supposed to mean.
>>>>>>>>>
>>>>>>>>> There are currently 49 issues for Solr that have these
"non-standard"
>>>>>>>>> versions [1]. Some date back before the most recent 6.5.0
release,
>>>>>>>>> which means there are issues fixed in 6.4 and 6.5 (at
least) which
>>>>>>>>> don't say so in JIRA.
>>>>>>>>>
>>>>>>>>> This could be really problematic going forward. We need
to agree that
>>>>>>>>> when issues are resolved, the fixVersion field is reliable
and means
>>>>>>>>> the same thing to everyone.
>>>>>>>>>
>>>>>>>>> IMO we should always use the *next* version that makes
sense at that
>>>>>>>>> time. So, an issue resolved today would be "6.6" and
"master (7.0)".
>>>>>>>>> Others may have different points of view on how we should
do this, but
>>>>>>>>> I think traditionally it's been the way I suggest, so
if there is
>>>>>>>>> change desired there, we should discuss it.
>>>>>>>>>
>>>>>>>>> Side note: I know there is some doubt today that 6.6
will ever exist.
>>>>>>>>> However, it will be a lot easier to go through JIRA to
remove "6.6"
>>>>>>>>> from issues that aren't in 6.x than it will be to review
>>>>>>>>> issue-by-issue everything that says "6x" or "6.x" or
"branch_6x",
>>>>>>>>> etc., and figure out when it was actually released.
>>>>>>>>>
>>>>>>>>> Cassandra
>>>>>>>>>
>>>>>>>>> [1] Query for JIRA issues:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x)
>>>>>>>>>
>>>>>>>>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller <markrmiller@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Who keeps adding strange JIRA release versions?
I've cleaned up
>>>>>>>>> > strange ones
>>>>>>>>> > in the past and they keep coming back.
>>>>>>>>> >
>>>>>>>>> > Why do we have branch6x, 6x and 6.x and trunk?
>>>>>>>>> >
>>>>>>>>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and
master (7.0), and I
>>>>>>>>> > don't
>>>>>>>>> > think we do, who keeps adding these duplicates?
Let's come to some
>>>>>>>>> > sanity
>>>>>>>>> > here.
>>>>>>>>> >
>>>>>>>>> > - Mark
>>>>>>>>> > --
>>>>>>>>> > - Mark
>>>>>>>>> > about.me/markrmiller
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author,
Speaker
>>>>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>>>>> http://www.solrenterprisesearchserver.com
>>>>>>>
>>>>>>> --
>>>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author,
Speaker
>>>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>>>> http://www.solrenterprisesearchserver.com
>>>>>>
>>>>>> --
>>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>>> http://www.solrenterprisesearchserver.com
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message