Re: Fix versions

[Anshum Gupta]

Makes sense, as long as we don’t treat it as ‘optional’ in the literal sense. 
We should try and put in some affected version there for the bug fixes as this 
entry certainly doesn’t make sense for anything other than the bugs.

-Anshum



> On Jul 10, 2017, at 12:48 PM, David Smiley  wrote:
> 
> RE Affected Versions.  "All ..." seems wrong. to clarify, this is an optional 
> entry and shouldn't imply an exhaustive list.  The submitter and anyone 
> helping can put the known version (bug experienced in version X for sure) 
> and/or perhaps the earliest known/believed.
> 
> On Mon, Jul 10, 2017 at 1:58 PM Anshum Gupta  > wrote:
> As long as all of us agree, and try to use the same system, I think we'll be 
> fine.
> 
> I think there's a reasonable consensus on the following understanding of 
> "fixVersion/s", and "Affected Versions"
> - fixVersion: All branches that the code was committed. Example, assuming 
> that the last released version was x.y.z:
>   - If the code was committed to master: master (x + 1.0)
>   - If the code was committed to the current stable branch (branch_ax), x.y + 
> 1
>   - If the code was committed to a release branch  - the next release version 
> from that branch. There would be one entry for each of the release branches 
> that this fix is committed to.
>   
> - Affected Versions: All affected git tags (released versions of Lucene/Solr).
> 
> If there are no objections by tomorrow morning (24 hours), I'll change the 
> wiki page to reflect this, and it would be great if we could all just follow 
> this convention.
> 
> -Anshum
> 
> 
> 
>> On Jul 6, 2017, at 2:40 AM, Dawid Weiss > > wrote:
>> 
>>> But for new features, it is different. The CHANGES entry is only added to
>>> the first version the feature was introduced (e.g. 7.0.0), even if the
>>> feature is committed to master, branch_7x, branch_7_0. In my head it would
>>> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
>> 
>> I don't think it's that much different, really.
>> 
>> If you introduce a feature on branch_7x and apply it to master then
>> it's both on branch_7x and master. Let's say somebody then cuts out
>> branch_8x from master and creates a release of version 8.0. Then that
>> somebody should tag patches on current master with branch_8x and 8.0
>> (assuming he's immediately going for the release). And then you'd see
>> this on your feature issue's fix-for:
>> 
>> branch_7x, branch_8x, 8.0, master
>> 
>> and since branch_7x hasn't been released yet, the feature would be
>> introduced in version 8.0, not any tagged version on 7x (because they
>> haven't been released yet). You could either rollback that feature
>> from branch_7x (and remove the tag), or keep it and release that
>> feature from both branches (next version of 7x). Or never release
>> branch_7x at all, but keep the patch there anyway.
>> 
>> Sure, this is a bit abnormal to have the same new "feature" on two
>> different branches, but you can apply the same thinking to bugfix
>> versions as well (features or any kind of patch). This is something
>> Hoss mentioned -- when you're doing multiple parallel releases of
>> versions from different branches it becomes a headache quickly to
>> figure out which version carries a certain patch (whether it's a bug,
>> feature or whatever else). But in reality it is often the case (in my
>> personal experience) that multiple versions do carry the same set of
>> patches, be it bug fixes, refactorings or even new features and those
>> tags in jira help to figure out where a given patch exists.
>> 
>> Dawid
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

Re: Fix versions

[David Smiley]

RE *Affected Versions*.  "All ..." seems wrong. to clarify, this is an
optional entry and shouldn't imply an exhaustive list.  The submitter and
anyone helping can put the known version (bug experienced in version X for
sure) and/or perhaps the earliest known/believed.

On Mon, Jul 10, 2017 at 1:58 PM Anshum Gupta  wrote:

> As long as all of us agree, and try to use the same system, I think we'll
> be fine.
>
> I think there's a reasonable consensus on the following understanding of
> "fixVersion/s", and "Affected Versions"
> - *fixVersion*: All branches that the code was committed. Example,
> assuming that the last released version was x.y.z:
>   - If the code was committed to master: master (x + 1.0)
>   - If the code was committed to the current stable branch (branch_ax),
> x.y + 1
>   - If the code was committed to a release branch  - the next release
> version from that branch. There would be one entry for each of the release
> branches that this fix is committed to.
>
> - *Affected Versions*: All affected git tags (released versions of
> Lucene/Solr).
>
> If there are no objections by *tomorrow morning (24 hours)*, I'll change
> the wiki page to reflect this, and it would be great if we could all just
> follow this convention.
>
> -Anshum
>
>
>
> On Jul 6, 2017, at 2:40 AM, Dawid Weiss  wrote:
>
> But for new features, it is different. The CHANGES entry is only added to
> the first version the feature was introduced (e.g. 7.0.0), even if the
> feature is committed to master, branch_7x, branch_7_0. In my head it would
> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
>
>
> I don't think it's that much different, really.
>
> If you introduce a feature on branch_7x and apply it to master then
> it's both on branch_7x and master. Let's say somebody then cuts out
> branch_8x from master and creates a release of version 8.0. Then that
> somebody should tag patches on current master with branch_8x and 8.0
> (assuming he's immediately going for the release). And then you'd see
> this on your feature issue's fix-for:
>
> branch_7x, branch_8x, 8.0, master
>
> and since branch_7x hasn't been released yet, the feature would be
> introduced in version 8.0, not any tagged version on 7x (because they
> haven't been released yet). You could either rollback that feature
> from branch_7x (and remove the tag), or keep it and release that
> feature from both branches (next version of 7x). Or never release
> branch_7x at all, but keep the patch there anyway.
>
> Sure, this is a bit abnormal to have the same new "feature" on two
> different branches, but you can apply the same thinking to bugfix
> versions as well (features or any kind of patch). This is something
> Hoss mentioned -- when you're doing multiple parallel releases of
> versions from different branches it becomes a headache quickly to
> figure out which version carries a certain patch (whether it's a bug,
> feature or whatever else). But in reality it is often the case (in my
> personal experience) that multiple versions do carry the same set of
> patches, be it bug fixes, refactorings or even new features and those
> tags in jira help to figure out where a given patch exists.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Fix versions

[Anshum Gupta]

As long as all of us agree, and try to use the same system, I think we'll be 
fine.

I think there's a reasonable consensus on the following understanding of 
"fixVersion/s", and "Affected Versions"
- fixVersion: All branches that the code was committed. Example, assuming that 
the last released version was x.y.z:
  - If the code was committed to master: master (x + 1.0)
  - If the code was committed to the current stable branch (branch_ax), x.y + 1
  - If the code was committed to a release branch  - the next release version 
from that branch. There would be one entry for each of the release branches 
that this fix is committed to.
  
- Affected Versions: All affected git tags (released versions of Lucene/Solr).

If there are no objections by tomorrow morning (24 hours), I'll change the wiki 
page to reflect this, and it would be great if we could all just follow this 
convention.

-Anshum



> On Jul 6, 2017, at 2:40 AM, Dawid Weiss  wrote:
> 
>> But for new features, it is different. The CHANGES entry is only added to
>> the first version the feature was introduced (e.g. 7.0.0), even if the
>> feature is committed to master, branch_7x, branch_7_0. In my head it would
>> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
> 
> I don't think it's that much different, really.
> 
> If you introduce a feature on branch_7x and apply it to master then
> it's both on branch_7x and master. Let's say somebody then cuts out
> branch_8x from master and creates a release of version 8.0. Then that
> somebody should tag patches on current master with branch_8x and 8.0
> (assuming he's immediately going for the release). And then you'd see
> this on your feature issue's fix-for:
> 
> branch_7x, branch_8x, 8.0, master
> 
> and since branch_7x hasn't been released yet, the feature would be
> introduced in version 8.0, not any tagged version on 7x (because they
> haven't been released yet). You could either rollback that feature
> from branch_7x (and remove the tag), or keep it and release that
> feature from both branches (next version of 7x). Or never release
> branch_7x at all, but keep the patch there anyway.
> 
> Sure, this is a bit abnormal to have the same new "feature" on two
> different branches, but you can apply the same thinking to bugfix
> versions as well (features or any kind of patch). This is something
> Hoss mentioned -- when you're doing multiple parallel releases of
> versions from different branches it becomes a headache quickly to
> figure out which version carries a certain patch (whether it's a bug,
> feature or whatever else). But in reality it is often the case (in my
> personal experience) that multiple versions do carry the same set of
> patches, be it bug fixes, refactorings or even new features and those
> tags in jira help to figure out where a given patch exists.
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Fix versions

[Dawid Weiss]

> But for new features, it is different. The CHANGES entry is only added to
> the first version the feature was introduced (e.g. 7.0.0), even if the
> feature is committed to master, branch_7x, branch_7_0. In my head it would
> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.

I don't think it's that much different, really.

If you introduce a feature on branch_7x and apply it to master then
it's both on branch_7x and master. Let's say somebody then cuts out
branch_8x from master and creates a release of version 8.0. Then that
somebody should tag patches on current master with branch_8x and 8.0
(assuming he's immediately going for the release). And then you'd see
this on your feature issue's fix-for:

branch_7x, branch_8x, 8.0, master

and since branch_7x hasn't been released yet, the feature would be
introduced in version 8.0, not any tagged version on 7x (because they
haven't been released yet). You could either rollback that feature
from branch_7x (and remove the tag), or keep it and release that
feature from both branches (next version of 7x). Or never release
branch_7x at all, but keep the patch there anyway.

Sure, this is a bit abnormal to have the same new "feature" on two
different branches, but you can apply the same thinking to bugfix
versions as well (features or any kind of patch). This is something
Hoss mentioned -- when you're doing multiple parallel releases of
versions from different branches it becomes a headache quickly to
figure out which version carries a certain patch (whether it's a bug,
feature or whatever else). But in reality it is often the case (in my
personal experience) that multiple versions do carry the same set of
patches, be it bug fixes, refactorings or even new features and those
tags in jira help to figure out where a given patch exists.

Dawid

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

Re: Fix versions

[Jan Høydahl]

I agree that it makes sense for bug fixes to list all versions (branches) the 
fix was applied; we’ll also add CHANGES entry under the same version headings, 
except for unreleased versions.

But for new features, it is different. The CHANGES entry is only added to the 
first version the feature was introduced (e.g. 7.0.0), even if the feature is 
committed to master, branch_7x, branch_7_0. In my head it would make sense to 
tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 6. jul. 2017 kl. 08.50 skrev Dawid Weiss :
> 
>> As David mentioned, there isn’t a
>> single true ‘solution’ for this problem so the more information we provide
>> the better.
> 
> Think of it in terms of how your repository is structured:
> 
> This issue was *fixed* on git branches [x,y,z] and *affected* tags [a,b,c].
> 
> This gives a clear an unambiguous pointer and workflow as to what goes
> where. "Affected version" can only point to a tag in git (this
> requires every proper release to be tagged, of course). "Fix-for"
> points at *all* branches (and tags) a given issue has been applied to
> (whether it's the same patch or a backport). Certain branches may not
> have anything to do with particular versions yet (branch_6x, master,
> major_feature_xyz), others are versions-in-preparation (branch_6_5_1;
> so-called release branches).
> 
> The additional work (typically of the release manager) is to, when a
> given version is being released, add a tag of that particular release
> to "fix-for". If the process is followed by everyone this becomes
> fairly automatic and results in issues being marked as, for example:
> 
> Fix-for: branch_6x, master, 6.5.1, 7.0
> 
> All of the above makes sense -- as a developer you immediately see
> which git branches this issue was applied to. So do people who are not
> developers.
> 
> But like I said before, I'm not advocating for this process -- just
> wanted to highlight an example of how it can be done. The above
> process does require a fairly strict workflow from everyone involved,
> so it may be more suited for a corporate environment... But it is
> clear (to me at least), verbose, and fairly straightforward, so it
> certainly can be done.
> 
> D.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Fix versions

[Dawid Weiss]

> As David mentioned, there isn’t a
> single true ‘solution’ for this problem so the more information we provide
> the better.

Think of it in terms of how your repository is structured:

This issue was *fixed* on git branches [x,y,z] and *affected* tags [a,b,c].

This gives a clear an unambiguous pointer and workflow as to what goes
where. "Affected version" can only point to a tag in git (this
requires every proper release to be tagged, of course). "Fix-for"
points at *all* branches (and tags) a given issue has been applied to
(whether it's the same patch or a backport). Certain branches may not
have anything to do with particular versions yet (branch_6x, master,
major_feature_xyz), others are versions-in-preparation (branch_6_5_1;
so-called release branches).

The additional work (typically of the release manager) is to, when a
given version is being released, add a tag of that particular release
to "fix-for". If the process is followed by everyone this becomes
fairly automatic and results in issues being marked as, for example:

Fix-for: branch_6x, master, 6.5.1, 7.0

All of the above makes sense -- as a developer you immediately see
which git branches this issue was applied to. So do people who are not
developers.

But like I said before, I'm not advocating for this process -- just
wanted to highlight an example of how it can be done. The above
process does require a fairly strict workflow from everyone involved,
so it may be more suited for a corporate environment... But it is
clear (to me at least), verbose, and fairly straightforward, so it
certainly can be done.

D.

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

Re: Fix versions

[Anshum Gupta]

Thanks for the insight hoss :). I agree that I went into this with my 
assumptions.

>  A user who sees that a bug is fixed in "6.6.1" has no way to be 
> confident that the same bug is fixed in "7.0" just because the major 
> number is greater -- because we might releast 6.6.1 after 7.0 is released.  

The only way to confidently look at the information on the JIRA and comment on 
what versions have a particular feature/bug/fix is through a combination of 
“Affected Versions” and “fixVersions”. As David mentioned, there isn’t a single 
true ‘solution’ for this problem so the more information we provide the better.

In what I am proposing, I am certainly resting the responsibility of providing 
all of that information ‘correctly’ to the users on the committer/developer. 
So, missing a commit, and/or fixVersion certainly does mess things up. Also, 
the non-linear releases that we have make it confusing for anyone who isn’t 
aware of the order of releases.

I just wanted to highlight what I thought was missing information and I’d be 
happy to have an entry-per-commit as long as we think that’s the most 
reasonable available option. 

I am also not sure how adding “Affected Version” would completely help with 
mitigating problems like - ‘x’ was fixed in 7.2.0, 7.1.1, 7.0.2, and 6.6.3, but 
"affects versions” 7.1.0, 7.0.1, 6.6.2, and 6.5”.

If it was a known issue in 6.4,6.3, etc. it would 1. require the developer to 
figure out, and provide that information, and 2. Enlist all of those versions, 
which might get a little too much.

I don’t want to spiral this discussion and spin it off into a never ending one 
so whatever we all agree with, I’ll be more than happy to move ahead with it.

-Anshum



> On Jul 5, 2017, at 6:42 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote:
> 
> 
> : Here’s my issue with that approach. Say I commit something that would be 
> : released with 7.0 but obviously, I also commit to master at this point. 
> : Going with your approach here are the fix versions I’ll end up with on 
> : the JIRA - master (8.0), 7.1, and 7.0.
> : 
> : This confuses me, as anything that has a 7.0 fix version shouldn’t have 
> : anything else from the 7x line. Also, it shouldn’t have anything from a 
> : line greater than that i.e. master (8.0) as it is obvious to me that 
> : there can not be any fix that makes it’s way into 7.0 but not 7.1, or 
> : 8.0.
> 
> The problem(s) with your "obvious" assertion are:
> 
> 1) just because it's "obvious" to you doesn't mean it's obvious to 
> everyone.  A user who sees that a bug is fixed in "6.6.1" has no way to be 
> confident that the same bug is fixed in "7.0" just because the major 
> number is greater -- because we might releast 6.6.1 after 7.0 is released.  
> To you and I it's obvious that's a diff situation from your "8.0 vs 7.1 vs 
> 7.0" example -- but only because we know how the branches are used and 
> forked off of eachother.  If you tell a user "any bug fiexed in 7.0.0 is 
> by definition also fixed in 7.1.0" it is understandable for them to 
> extrapolate that "any bug fixed in 7.0.1 is also fixed in 7.1.0"
> 
> 2) It is in fact very possible for human error to result in a bug fix 
> making it's way into 7.0.0, but not into 7.1.0 when (as they are today, 
> post branch_7_0 creation) 2 distinct commits/merges are needed to 2 
> distinct branches.  a philosophy of "each branch changed == a fixVersion 
> added" helps developers sanity check their own actions vs their 
> expectations, and gives people watching jiras enough info to sanity 
> check a committers actions even if they don't understand the specifics of 
> the affected code...
> 
> If you commit a bug fix to your local branch_7x and branch_7_0, but 
> something goes wrong with your push to branch_7x (perhaps a conflict 
> because someone else has added a feature to that branch since your last 
> merge/rebase) and you don't notice, people watching the issue who see a 
> single commit to branch_7_0 and you setting the fixVersion=7.0 might 
> easily assume the "bug" only affects the 7.0 release line, and doesn't 
> exist in branch_7x due to other changes.  If you explicitly set 
> fixVersion="7.0, 7.(x|1)" but there is only 1 commit to branch_7_0 for 
> that jira, then hopefully that raises eyebrows from other people who can 
> ask you about it and help you catch your mistake.
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Fix versions

[Chris Hostetter]

: Here’s my issue with that approach. Say I commit something that would be 
: released with 7.0 but obviously, I also commit to master at this point. 
: Going with your approach here are the fix versions I’ll end up with on 
: the JIRA - master (8.0), 7.1, and 7.0.
: 
: This confuses me, as anything that has a 7.0 fix version shouldn’t have 
: anything else from the 7x line. Also, it shouldn’t have anything from a 
: line greater than that i.e. master (8.0) as it is obvious to me that 
: there can not be any fix that makes it’s way into 7.0 but not 7.1, or 
: 8.0.

The problem(s) with your "obvious" assertion are:

1) just because it's "obvious" to you doesn't mean it's obvious to 
everyone.  A user who sees that a bug is fixed in "6.6.1" has no way to be 
confident that the same bug is fixed in "7.0" just because the major 
number is greater -- because we might releast 6.6.1 after 7.0 is released.  
To you and I it's obvious that's a diff situation from your "8.0 vs 7.1 vs 
7.0" example -- but only because we know how the branches are used and 
forked off of eachother.  If you tell a user "any bug fiexed in 7.0.0 is 
by definition also fixed in 7.1.0" it is understandable for them to 
extrapolate that "any bug fixed in 7.0.1 is also fixed in 7.1.0"

2) It is in fact very possible for human error to result in a bug fix 
making it's way into 7.0.0, but not into 7.1.0 when (as they are today, 
post branch_7_0 creation) 2 distinct commits/merges are needed to 2 
distinct branches.  a philosophy of "each branch changed == a fixVersion 
added" helps developers sanity check their own actions vs their 
expectations, and gives people watching jiras enough info to sanity 
check a committers actions even if they don't understand the specifics of 
the affected code...

If you commit a bug fix to your local branch_7x and branch_7_0, but 
something goes wrong with your push to branch_7x (perhaps a conflict 
because someone else has added a feature to that branch since your last 
merge/rebase) and you don't notice, people watching the issue who see a 
single commit to branch_7_0 and you setting the fixVersion=7.0 might 
easily assume the "bug" only affects the 7.0 release line, and doesn't 
exist in branch_7x due to other changes.  If you explicitly set 
fixVersion="7.0, 7.(x|1)" but there is only 1 commit to branch_7_0 for 
that jira, then hopefully that raises eyebrows from other people who can 
ask you about it and help you catch your mistake.


-Hoss
http://www.lucidworks.com/

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

Re: Fix versions

[Anshum Gupta]

I’ve put this on a wiki page, and did that as a ‘trivial change’, which 
shouldn’t have triggered any emails to anyone other than Steve (sorry about 
that). I’m not sure how to have that as a permanent setting for this page 
though.

Anyone?

Here’s the page: https://wiki.apache.org/lucene-java/SettingFixVersions

-Anshum



> On Jul 5, 2017, at 3:10 PM, David Smiley <david.w.smi...@gmail.com> wrote:
> 
> This makes sense to me.  It's easy to forget this stuff though.  Perhaps we 
> can propose a policy, vote on it, and post it somewhere?  We could even do 
> this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal" 
> prominently at the top, and then share a link.  Keep it particularly succinct 
> so it's easy to see what the essence is, and then only potentially later 
> decorate with tips & whatever else.  It'd be nice but not required to have 
> changes to this page (and some selected others) be auto-copied to the dev 
> list somehow, e.g. by having a special account, but not required.
> 
> On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta <ansh...@apple.com 
> <mailto:ansh...@apple.com>> wrote:
> @Dawid: I remember that discussion, and I think things were fixed for the 
> issue back then.
> 
> My concern right now is that we will end up in a similar situation again with 
> everyone interpreting the fixVersion differently.
> 
> @Erick
> Here’s my issue with that approach. Say I commit something that would be 
> released with 7.0 but obviously, I also commit to master at this point. Going 
> with your approach here are the fix versions I’ll end up with on the JIRA - 
> master (8.0), 7.1, and 7.0. 
> 
> This confuses me, as anything that has a 7.0 fix version shouldn’t have 
> anything else from the 7x line. Also, it shouldn’t have anything from a line 
> greater than that i.e. master (8.0) as it is obvious to me that there can not 
> be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
> 
> Also, from my understanding, a fix version of 7.1 would mean that the first 
> time this was released on the 7x line was 7.1 (which wouldn’t be the case 
> here).
> 
> Yes, things would work differently for bug fix releases, but I’m talking 
> about the major release version here.
> 
> Here’s my suggestion:
> 
> - For a fix that will be released with a major version, just mention the 
> major version
> - For a minor version
>   - master (current version + 1)
>   - minor version release that would have this fix
>   - all prior bug fix releases, when this is back-ported to older branches
> - Bug fix release
>   - The only case when a fix is released with such a release, is when 
>   - The issue was introduced by a minor version release right 
> before this release AND
>   - There was no other minor/major release since this issue was 
> introduced.
>   - In such a case, the fix version should only have the bug fix version, 
> and not master, etc.
> 
> What would also be useful here is specifying the ‘Affects Version’ but in my 
> experience, this gets tough to figure at times for bug fixes, and doesn’t 
> generally make sense for new features/enhancements.
> 
> If there’s anything else, I’d be happy to just go with whatever everyone 
> wants to follow as long as it makes things easier to understand and manage. 
> 
> 
> -Anshum
> 
> 
> 
>> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com 
>> <mailto:erickerick...@gmail.com>> wrote:
>> 
>> I'm just including a fix version for each push I make. I.e.
>> 
>> If I push to master I'll add "master (8.0)".
>> If I push to 7x, at this point I'll add 7.1
>> If I push to 7_0 I'll add 7.0
>> If I push to 6x I'll add 6.7
>> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>> 
>> I think one push == one label is unambiguous. You do have to realize
>> that if there may never be, say, a 6.6.1 in my example. But we do
>> remove the onus of people having to figure out what a fix version of
>> plain "master" or "7x" means.
>> 
>> FWIW
>> Erick
>> 
>> 
>> 
>> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com 
>> <mailto:dawid.we...@gmail.com>> wrote:
>>> There's been a fairly recent discussion about it on the mailing list
>>> (David Smiley and were involved in that discussion, among other
>>> people). There are many different takes on how to handle fix-for and
>>> branches. I don't think we can find the "best" strategy, although
>>> perhaps we can agree on something project-specific. I've expressed my
>

Re: Fix versions

[Mike Drob]

This would be good to see as part of the How To Contribute guide, I think,
or at least linked from there.

On Wed, Jul 5, 2017 at 5:10 PM, David Smiley <david.w.smi...@gmail.com>
wrote:

> This makes sense to me.  It's easy to forget this stuff though.  Perhaps
> we can propose a policy, vote on it, and post it somewhere?  We could even
> do this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal"
> prominently at the top, and then share a link.  Keep it particularly
> succinct so it's easy to see what the essence is, and then only potentially
> later decorate with tips & whatever else.  It'd be nice but not required to
> have changes to this page (and some selected others) be auto-copied to the
> dev list somehow, e.g. by having a special account, but not required.
>
> On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta <ansh...@apple.com> wrote:
>
>> @Dawid: I remember that discussion, and I think things were fixed for the
>> issue back then.
>>
>> My concern right now is that we will end up in a similar situation again
>> with everyone interpreting the fixVersion differently.
>>
>> @Erick
>> Here’s my issue with that approach. Say I commit something that would be
>> released with 7.0 but obviously, I also commit to master at this point.
>> Going with your approach here are the fix versions I’ll end up with on the
>> JIRA - *master (8.0), 7.1, and 7.0*.
>>
>> This confuses me, as anything that has a 7.0 fix version shouldn’t have
>> anything else from the 7x line. Also, it shouldn’t have anything from a
>> line greater than that i.e. master (8.0) as it is obvious to me that there
>> can not be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
>>
>> Also, from my understanding, a fix version of 7.1 would mean that the
>> first time this was released on the 7x line was 7.1 (which wouldn’t be the
>> case here).
>>
>> Yes, things would work differently for bug fix releases, but I’m talking
>> about the major release version here.
>>
>> Here’s my suggestion:
>>
>> - For a fix that will be released with a major version, just mention the
>> major version
>> - For a minor version
>> - master (current version + 1)
>> - minor version release that would have this fix
>> - all prior bug fix releases, when this is back-ported to older branches
>> - Bug fix release
>> - The only case when a fix is released with such a release, is when
>> - The issue was introduced by a minor version release right before this
>> release AND
>> - There was no other minor/major release since this issue was introduced.
>> - In such a case, the fix version should only have the bug fix version,
>> and not master, etc.
>>
>> What would also be useful here is specifying the ‘*Affects Version*’ but
>> in my experience, this gets tough to figure at times for bug fixes, and
>> doesn’t generally make sense for new features/enhancements.
>>
>> If there’s anything else, I’d be happy to just go with whatever everyone
>> wants to follow as long as it makes things easier to understand and manage.
>>
>>
>> -Anshum
>>
>>
>>
>> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com>
>> wrote:
>>
>> I'm just including a fix version for each push I make. I.e.
>>
>> If I push to master I'll add "master (8.0)".
>> If I push to 7x, at this point I'll add 7.1
>> If I push to 7_0 I'll add 7.0
>> If I push to 6x I'll add 6.7
>> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>>
>> I think one push == one label is unambiguous. You do have to realize
>> that if there may never be, say, a 6.6.1 in my example. But we do
>> remove the onus of people having to figure out what a fix version of
>> plain "master" or "7x" means.
>>
>> FWIW
>> Erick
>>
>>
>>
>> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com>
>> wrote:
>>
>> There's been a fairly recent discussion about it on the mailing list
>> (David Smiley and were involved in that discussion, among other
>> people). There are many different takes on how to handle fix-for and
>> branches. I don't think we can find the "best" strategy, although
>> perhaps we can agree on something project-specific. I've expressed my
>> opinion on that previous post, but I'm open to any strategy.
>>
>> Dawid
>>
>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta <ansh...@apple.com> wrote:
>>
>> Hi,
>>
>> I was a bit confused in terms

Re: Fix versions

[David Smiley]

This makes sense to me.  It's easy to forget this stuff though.  Perhaps we
can propose a policy, vote on it, and post it somewhere?  We could even do
this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal"
prominently at the top, and then share a link.  Keep it particularly
succinct so it's easy to see what the essence is, and then only potentially
later decorate with tips & whatever else.  It'd be nice but not required to
have changes to this page (and some selected others) be auto-copied to the
dev list somehow, e.g. by having a special account, but not required.

On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta <ansh...@apple.com> wrote:

> @Dawid: I remember that discussion, and I think things were fixed for the
> issue back then.
>
> My concern right now is that we will end up in a similar situation again
> with everyone interpreting the fixVersion differently.
>
> @Erick
> Here’s my issue with that approach. Say I commit something that would be
> released with 7.0 but obviously, I also commit to master at this point.
> Going with your approach here are the fix versions I’ll end up with on the
> JIRA - *master (8.0), 7.1, and 7.0*.
>
> This confuses me, as anything that has a 7.0 fix version shouldn’t have
> anything else from the 7x line. Also, it shouldn’t have anything from a
> line greater than that i.e. master (8.0) as it is obvious to me that there
> can not be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
>
> Also, from my understanding, a fix version of 7.1 would mean that the
> first time this was released on the 7x line was 7.1 (which wouldn’t be the
> case here).
>
> Yes, things would work differently for bug fix releases, but I’m talking
> about the major release version here.
>
> Here’s my suggestion:
>
> - For a fix that will be released with a major version, just mention the
> major version
> - For a minor version
> - master (current version + 1)
> - minor version release that would have this fix
> - all prior bug fix releases, when this is back-ported to older branches
> - Bug fix release
> - The only case when a fix is released with such a release, is when
> - The issue was introduced by a minor version release right before this
> release AND
> - There was no other minor/major release since this issue was introduced.
> - In such a case, the fix version should only have the bug fix version,
> and not master, etc.
>
> What would also be useful here is specifying the ‘*Affects Version*’ but
> in my experience, this gets tough to figure at times for bug fixes, and
> doesn’t generally make sense for new features/enhancements.
>
> If there’s anything else, I’d be happy to just go with whatever everyone
> wants to follow as long as it makes things easier to understand and manage.
>
>
> -Anshum
>
>
>
> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com>
> wrote:
>
> I'm just including a fix version for each push I make. I.e.
>
> If I push to master I'll add "master (8.0)".
> If I push to 7x, at this point I'll add 7.1
> If I push to 7_0 I'll add 7.0
> If I push to 6x I'll add 6.7
> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>
> I think one push == one label is unambiguous. You do have to realize
> that if there may never be, say, a 6.6.1 in my example. But we do
> remove the onus of people having to figure out what a fix version of
> plain "master" or "7x" means.
>
> FWIW
> Erick
>
>
>
> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com> wrote:
>
> There's been a fairly recent discussion about it on the mailing list
> (David Smiley and were involved in that discussion, among other
> people). There are many different takes on how to handle fix-for and
> branches. I don't think we can find the "best" strategy, although
> perhaps we can agree on something project-specific. I've expressed my
> opinion on that previous post, but I'm open to any strategy.
>
> Dawid
>
> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta <ansh...@apple.com> wrote:
>
> Hi,
>
> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
> are being committed right now. I think it makes sense for the fixVersion to
> just be 7.0, and nothing else for everything that is going into branch_7_0,
> instead of being both 7.0, and master (8.0).
>
> Any thoughts?
>
> -Anshum
>
>
>
>
> -
> 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
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Fix versions

[Anshum Gupta]

@Dawid: I remember that discussion, and I think things were fixed for the issue 
back then.

My concern right now is that we will end up in a similar situation again with 
everyone interpreting the fixVersion differently.

@Erick
Here’s my issue with that approach. Say I commit something that would be 
released with 7.0 but obviously, I also commit to master at this point. Going 
with your approach here are the fix versions I’ll end up with on the JIRA - 
master (8.0), 7.1, and 7.0. 

This confuses me, as anything that has a 7.0 fix version shouldn’t have 
anything else from the 7x line. Also, it shouldn’t have anything from a line 
greater than that i.e. master (8.0) as it is obvious to me that there can not 
be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.

Also, from my understanding, a fix version of 7.1 would mean that the first 
time this was released on the 7x line was 7.1 (which wouldn’t be the case here).

Yes, things would work differently for bug fix releases, but I’m talking about 
the major release version here.

Here’s my suggestion:

- For a fix that will be released with a major version, just mention the major 
version
- For a minor version
- master (current version + 1)
- minor version release that would have this fix
- all prior bug fix releases, when this is back-ported to older branches
- Bug fix release
- The only case when a fix is released with such a release, is when 
- The issue was introduced by a minor version release right 
before this release AND
- There was no other minor/major release since this issue was 
introduced.
- In such a case, the fix version should only have the bug fix version, 
and not master, etc.

What would also be useful here is specifying the ‘Affects Version’ but in my 
experience, this gets tough to figure at times for bug fixes, and doesn’t 
generally make sense for new features/enhancements.

If there’s anything else, I’d be happy to just go with whatever everyone wants 
to follow as long as it makes things easier to understand and manage. 


-Anshum



> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com> wrote:
> 
> I'm just including a fix version for each push I make. I.e.
> 
> If I push to master I'll add "master (8.0)".
> If I push to 7x, at this point I'll add 7.1
> If I push to 7_0 I'll add 7.0
> If I push to 6x I'll add 6.7
> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
> 
> I think one push == one label is unambiguous. You do have to realize
> that if there may never be, say, a 6.6.1 in my example. But we do
> remove the onus of people having to figure out what a fix version of
> plain "master" or "7x" means.
> 
> FWIW
> Erick
> 
> 
> 
> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com> wrote:
>> There's been a fairly recent discussion about it on the mailing list
>> (David Smiley and were involved in that discussion, among other
>> people). There are many different takes on how to handle fix-for and
>> branches. I don't think we can find the "best" strategy, although
>> perhaps we can agree on something project-specific. I've expressed my
>> opinion on that previous post, but I'm open to any strategy.
>> 
>> Dawid
>> 
>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta <ansh...@apple.com> wrote:
>>> Hi,
>>> 
>>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>>> are being committed right now. I think it makes sense for the fixVersion to
>>> just be 7.0, and nothing else for everything that is going into branch_7_0,
>>> instead of being both 7.0, and master (8.0).
>>> 
>>> Any thoughts?
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
>> 
>> -
>> 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
> 

Re: Fix versions

[Erick Erickson]

I'm just including a fix version for each push I make. I.e.

If I push to master I'll add "master (8.0)".
If I push to 7x, at this point I'll add 7.1
If I push to 7_0 I'll add 7.0
If I push to 6x I'll add 6.7
If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1

I think one push == one label is unambiguous. You do have to realize
that if there may never be, say, a 6.6.1 in my example. But we do
remove the onus of people having to figure out what a fix version of
plain "master" or "7x" means.

FWIW
Erick



On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss  wrote:
> There's been a fairly recent discussion about it on the mailing list
> (David Smiley and were involved in that discussion, among other
> people). There are many different takes on how to handle fix-for and
> branches. I don't think we can find the "best" strategy, although
> perhaps we can agree on something project-specific. I've expressed my
> opinion on that previous post, but I'm open to any strategy.
>
> Dawid
>
> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
>> Hi,
>>
>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>> are being committed right now. I think it makes sense for the fixVersion to
>> just be 7.0, and nothing else for everything that is going into branch_7_0,
>> instead of being both 7.0, and master (8.0).
>>
>> Any thoughts?
>>
>> -Anshum
>>
>>
>>
>
> -
> 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

Re: Fix versions

[Dawid Weiss]

There's been a fairly recent discussion about it on the mailing list
(David Smiley and were involved in that discussion, among other
people). There are many different takes on how to handle fix-for and
branches. I don't think we can find the "best" strategy, although
perhaps we can agree on something project-specific. I've expressed my
opinion on that previous post, but I'm open to any strategy.

Dawid

On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
> Hi,
>
> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
> are being committed right now. I think it makes sense for the fixVersion to
> just be 7.0, and nothing else for everything that is going into branch_7_0,
> instead of being both 7.0, and master (8.0).
>
> Any thoughts?
>
> -Anshum
>
>
>

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

Fix versions

[Anshum Gupta]

Hi,

I was a bit confused in terms of setting the ‘fix version’ for JIRAs that are 
being committed right now. I think it makes sense for the fixVersion to just be 
7.0, and nothing else for everything that is going into branch_7_0, instead of 
being both 7.0, and master (8.0). 

Any thoughts?

-Anshum

[jira] [Resolved] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk/master 5.5)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke resolved SOLR-8566.
---
Resolution: Fixed

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk/master 
> 5.5)
> 
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 6.0, 5.5
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> SyncStrategy-syncWithReplicas.patch, TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-8566:
--
Attachment: SyncStrategy-syncWithReplicas.patch

Trivial change. And so perfect to be my first apache git commit.

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> SyncStrategy-syncWithReplicas.patch, TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15117196#comment-15117196
 ] 

Christine Poerschke commented on SOLR-8566:
---

First git commits for this ticket:
* SOLR-8566: SyncStrategy.syncWithReplicas initialCapacity tweak
** master/trunk: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2782f607
** branch_5x: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/6234a115

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> SyncStrategy-syncWithReplicas.patch, TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk/master 5.5)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-8566:
--
Summary: umbrella ticket: various initialCapacity tweaks (Fix Versions: 
trunk/master 5.5)  (was: umbrella ticket: various initialCapacity tweaks (Fix 
Versions: trunk 5.5))

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk/master 
> 5.5)
> 
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> SyncStrategy-syncWithReplicas.patch, TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108914#comment-15108914
 ] 

ASF subversion and git services commented on SOLR-8566:
---

Commit 1725757 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1725757 ]

SOLR-8566: ManagedResource.buildMapToStore initialCapacity tweak. 
ManagedResource.storeManagedData log.error tweak ("load data" instead of "load 
stop words"). (merge in revision 1725752 from trunk)

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-8566:
--
Attachment: ManagedResource-buildMapToStore.patch

* ManagedResource.buildMapToStore initialCapacity tweak.
* ManagedResource.storeManagedData log.error tweak ("load data" instead of 
"load stop words").

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108863#comment-15108863
 ] 

ASF subversion and git services commented on SOLR-8566:
---

Commit 1725752 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1725752 ]

SOLR-8566: ManagedResource.buildMapToStore initialCapacity tweak. 
ManagedResource.storeManagedData log.error tweak ("load data" instead of "load 
stop words").

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: ManagedResource-buildMapToStore.patch, 
> TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-8566:
--
Attachment: TransformerFactory-defaultFactories.patch

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8566:
-

 Summary: umbrella ticket: various initialCapacity tweaks (Fix 
Versions: trunk 5.5)
 Key: SOLR-8566
 URL: https://issues.apache.org/jira/browse/SOLR-8566
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Priority: Minor
 Fix For: 5.5, Trunk
 Attachments: TransformerFactory-defaultFactories.patch

Everyone is welcome to use/reference this ticket to make small, 
uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106592#comment-15106592
 ] 

ASF subversion and git services commented on SOLR-8566:
---

Commit 1725469 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1725469 ]

SOLR-8566: TransformerFactory.defaultFactories initialCapacity tweak

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8566) umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106611#comment-15106611
 ] 

ASF subversion and git services commented on SOLR-8566:
---

Commit 1725471 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1725471 ]

SOLR-8566: TransformerFactory.defaultFactories initialCapacity tweak (merge in 
revision 1725469 from trunk)

> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: TransformerFactory-defaultFactories.patch
>
>
> Everyone is welcome to use/reference this ticket to make small, 
> uncontroversional initialCapacity changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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