OK. I'm not sure you're missing anything. But, I think we'll all know
for sure pretty quickly once we're doing it.

Do you want help with this? Seems like you have it under control, but
if you want to split it somehow, I can help a bit this afternoon.

On Fri, Apr 29, 2016 at 2:47 PM, Chris Hostetter
<hossman_luc...@fucit.org> wrote:
>
> : Yeah, good point, I forgot about the permutations with backported issues.
> :
> : But it's not just master + 6.1,  it's also master + 6.0. That's why
> : the query I sent out looked for issues that had "master", but not
> : either of those versions. If it's marked for 6.0 and also master, then
> : it's meant for 7.0 (eventually).
>
> Not neccessarily -- we have no way of nowing when "master" was put in
> fixVersion, so "6.0, master" might mean "commited to master=7.0 and
> branch_6x=6.0" or it might mean "commited to master which was then later
> forked to branch_6x but then someone also added 6.0 explicitly when
> resolving"
>
> in general, if we're going to merge master->6.0 we don't have to worry
> about any issues that *currently* list both -- that wll be resolved when
> they merge.
>
> I'm pretty sure we only have to worry about:
>
> a) issues that list both "master
> + 6.1" and wether that really means "commited to branch_6_0=6.0 and
> branch_6x=6.1" or "commited to master=7.0 and branch_6x=6.0" ... which is
> why i suggested a manual audit based on jira query.
>
> b) issues that *should* only list "master" once we are all done ... which
> should be a really straight forward audit of the 7.0 CHANGES.txt.
>
> ...or am i still missing something?
>
> : generally assumed. We could remove master from all issues that already
> : have another fixVersion (except the forward ones, 6.0 and 6.1), and
> : then just deal with that list. It's much more manageable:
> :
> : 
> https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
>
> how would we remove master from master from those issues? the "Bulk Edit
> replaces whole field" problem would force us to remove all fixVersions in
> that case wouldn't it?
>
>
>
>
>
> : > : > for both the LUCENE and SOLR project...
> : > : >
> : > : > 1) Audit the list of Jira's with 'fixVersion=mater AND 
> fixVersion=6.1' and
> : > : > manually remove master from all of them (only ~100 total)
> : > : > 2) merge "master" into "6.0"
> : > : > 3) re add a "master" version to Jira
> : > : > 3) Audit CHANGES.txt and set fixVersion=master on the handful of 
> issues in
> : > : > the 7.0 section
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Reply via email to