You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Alexandre Rafalovitch <ar...@gmail.com> on 2014/11/21 21:14:40 UTC
Testing Solr 5
Hi,
I am writing something that - will - depend on Solr 5. As I usually
work with released versions, I am not entirely sure of the correct
workflow.
I can check out branch_5x and do my research against that. I assume
that's the correct source for what will land in version 5.
But if I find an issue, do I then report it against 5? Or do I need to
retest that against trunk and report against trunk? I don't know how
in-sync these two are at this point.
I've checked https://wiki.apache.org/solr/HackingSolr but it is not
specific enough (and is actually out of date regarding version 5).
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Testing Solr 5
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Well, my concern was mostly about not reporting something against
brunch_5x that may have already been fixed in trunk (to avoid
JIRA-spam). I am not sure I am yet at the patch skill-level.
But I got my answer and the extra knowledge is extra power, so I am
not complaining. :-)
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853
On 21 November 2014 16:13, Jack Krupansky <ja...@basetechnology.com> wrote:
> My understanding from what I have heard over the past year:
>
> 1. Reporting of issues (bugs) can be on any release or branch or trunk.
> Testing on the other releases, branches, or trunk is encouraged, but not
> mandatory. The main thing is to capture a repro scenario.
> 2. Any bug fixes should be on: 1) trunk, 2) branch_5x, and 3) branch_4x - to
> all that the bug applies to.
> 3. Any new features should be first on trunk and given time to bake (i.e.,
> fix any Jenkins errors), then backported to branch_5x as the feature is
> completed and debugged. A determined effort must be made to keep "the stable
> branch" as stable as possible.
>
> -- Jack Krupansky
>
> -----Original Message----- From: Shawn Heisey
> Sent: Friday, November 21, 2014 3:36 PM
> To: dev@lucene.apache.org
> Subject: Re: Testing Solr 5
>
>
> On 11/21/2014 1:14 PM, Alexandre Rafalovitch wrote:
>>
>> I am writing something that - will - depend on Solr 5. As I usually
>> work with released versions, I am not entirely sure of the correct
>> workflow.
>>
>> I can check out branch_5x and do my research against that. I assume
>> that's the correct source for what will land in version 5.
>>
>> But if I find an issue, do I then report it against 5? Or do I need to
>> retest that against trunk and report against trunk? I don't know how
>> in-sync these two are at this point.
>>
>> I've checked https://wiki.apache.org/solr/HackingSolr but it is not
>> specific enough (and is actually out of date regarding version 5).
>
>
> Any testing we do for branch_5x probably isn't enough, so please do test
> with it. That is the branch where development will happen for all 5.x
> releases. If you do find a problem and *can* try again with trunk,
> please do, but don't make that a prerequisite for filing an issue or
> creating a patch. A patch against trunk is preferred, but any patch is
> better than none.
>
> We'd like to know which branch the patch applies to, and if there are
> any problems we may need to know the SVN revision number, so it's better
> to include that info up front if you have it. If you are using one of
> the git mirrors, the SVN revision number may not be available. The git
> commit hash may be useful instead.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> 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
Re: Testing Solr 5
Posted by Jack Krupansky <ja...@basetechnology.com>.
My understanding from what I have heard over the past year:
1. Reporting of issues (bugs) can be on any release or branch or trunk.
Testing on the other releases, branches, or trunk is encouraged, but not
mandatory. The main thing is to capture a repro scenario.
2. Any bug fixes should be on: 1) trunk, 2) branch_5x, and 3) branch_4x - to
all that the bug applies to.
3. Any new features should be first on trunk and given time to bake (i.e.,
fix any Jenkins errors), then backported to branch_5x as the feature is
completed and debugged. A determined effort must be made to keep "the stable
branch" as stable as possible.
-- Jack Krupansky
-----Original Message-----
From: Shawn Heisey
Sent: Friday, November 21, 2014 3:36 PM
To: dev@lucene.apache.org
Subject: Re: Testing Solr 5
On 11/21/2014 1:14 PM, Alexandre Rafalovitch wrote:
> I am writing something that - will - depend on Solr 5. As I usually
> work with released versions, I am not entirely sure of the correct
> workflow.
>
> I can check out branch_5x and do my research against that. I assume
> that's the correct source for what will land in version 5.
>
> But if I find an issue, do I then report it against 5? Or do I need to
> retest that against trunk and report against trunk? I don't know how
> in-sync these two are at this point.
>
> I've checked https://wiki.apache.org/solr/HackingSolr but it is not
> specific enough (and is actually out of date regarding version 5).
Any testing we do for branch_5x probably isn't enough, so please do test
with it. That is the branch where development will happen for all 5.x
releases. If you do find a problem and *can* try again with trunk,
please do, but don't make that a prerequisite for filing an issue or
creating a patch. A patch against trunk is preferred, but any patch is
better than none.
We'd like to know which branch the patch applies to, and if there are
any problems we may need to know the SVN revision number, so it's better
to include that info up front if you have it. If you are using one of
the git mirrors, the SVN revision number may not be available. The git
commit hash may be useful instead.
Thanks,
Shawn
---------------------------------------------------------------------
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
Re: Testing Solr 5
Posted by Shawn Heisey <ap...@elyograg.org>.
On 11/21/2014 1:14 PM, Alexandre Rafalovitch wrote:
> I am writing something that - will - depend on Solr 5. As I usually
> work with released versions, I am not entirely sure of the correct
> workflow.
>
> I can check out branch_5x and do my research against that. I assume
> that's the correct source for what will land in version 5.
>
> But if I find an issue, do I then report it against 5? Or do I need to
> retest that against trunk and report against trunk? I don't know how
> in-sync these two are at this point.
>
> I've checked https://wiki.apache.org/solr/HackingSolr but it is not
> specific enough (and is actually out of date regarding version 5).
Any testing we do for branch_5x probably isn't enough, so please do test
with it. That is the branch where development will happen for all 5.x
releases. If you do find a problem and *can* try again with trunk,
please do, but don't make that a prerequisite for filing an issue or
creating a patch. A patch against trunk is preferred, but any patch is
better than none.
We'd like to know which branch the patch applies to, and if there are
any problems we may need to know the SVN revision number, so it's better
to include that info up front if you have it. If you are using one of
the git mirrors, the SVN revision number may not be available. The git
commit hash may be useful instead.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org