I tried to add the back compat index for 5.5.0 by running the script on
branch_5x, but it errors out when running the test with : "Extra
back-compat test files: 5.5.0-cfs". I'm confused here in terms of what the
instructions say and what's supposed to be done.


On Fri, Apr 29, 2016 at 6:52 PM, Anshum Gupta <ans...@anshumgupta.net>
wrote:

> Seems like 5.5.0 back compat index was never added. Can someone confirm
> that?
> I have the RC but the smoke test failed when I ran it locally. Here's the
> error:
>
> Verify...
>   confirm all releases have coverage in TestBackwardsCompatibility
>     find all past Lucene releases...
>     run TestBackwardsCompatibility..
>       Backcompat testing not required for release 6.0.0 because it's not
> less than 5.5.1
> Releases that don't seem to be tested:
>   5.5.0
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1443, in <module>
>     main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1387, in main
>     smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
> c.is_signed, ' '.join(c.test_args))
>   File "dev-tools/scripts/smokeTestRelease.py", line 1425, in smokeTest
>     unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version,
> gitRevision, version, testArgs, baseURL)
>   File "dev-tools/scripts/smokeTestRelease.py", line 589, in
> unpackAndVerify
>     verifyUnpacked(java, project, artifact, unpackPath, gitRevision,
> version, testArgs, tmpDir, baseURL)
>   File "dev-tools/scripts/smokeTestRelease.py", line 769, in verifyUnpacked
>     confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1380, in
> confirmAllReleasesAreTestedForBackCompat
>     raise RuntimeError('some releases are not tested by
> TestBackwardsCompatibility?')
> RuntimeError: some releases are not tested by TestBackwardsCompatibility?
>
>
>
> On Fri, Apr 29, 2016 at 11:05 AM, Anshum Gupta <ans...@anshumgupta.net>
> wrote:
>
>> Something seems to be going on with TestManagedSchemaAPI as it's been
>> consistently failing.
>> I woke up with a fever today so I'll try and debug it some time later if
>> I'm unable to get an RC built, but if I do get the RC, I'll get it out to
>> vote and in parallel see if it's something that needs fixing unless someone
>> else beats me to it.
>>
>> On Fri, Apr 29, 2016 at 9:26 AM, Anshum Gupta <ans...@anshumgupta.net>
>> wrote:
>>
>>> That makes sense considering there are those checks for ignoring 1
>>> missing version.
>>>
>>> On Fri, Apr 29, 2016 at 6:53 AM, Steve Rowe <sar...@gmail.com> wrote:
>>>
>>>> Anshum,
>>>>
>>>> TL;DR: When there is only one release in flight, I think it’s okay to
>>>> run addVersion.py on all branches at the start of the release process for
>>>> all types of releases.
>>>>
>>>> When we chatted last night I said backcompat index testing was a
>>>> problem on non-release branches in the interval between adding a
>>>> not-yet-released version to o.a.l.util.Version and when a backcompat index
>>>> is committed on the branch.  I was wrong.
>>>>
>>>> Here are the places where there are back-compat coverage tests:
>>>>
>>>> 1. smokeTestRelease.py's confirmAllReleasesAreTestedForBackCompat()
>>>> will succeed until release artifacts have been published - see
>>>> getAllLuceneReleases() for where they are scraped off the lucene release
>>>> list page on archive.apache.org.  So back-compat indexes should be
>>>> generated and committed as soon as possible after publishing artifacts.
>>>>
>>>> 2. backward-codec’s TestBackwardsCompatibility.testAllVersionsTested()
>>>> will still succeed if a single version is not tested.  Here’s the code:
>>>>
>>>>   // we could be missing up to 1 file, which may be due to a release
>>>> that is in progress
>>>>   if (missingFiles.size() <= 1 && extraFiles.isEmpty()) {
>>>>
>>>> The above test could be improved by checking for the presence of
>>>> published release artifacts for each release like smokeTestRelease.py does,
>>>> and then not requiring the backcompat index be present for those that are
>>>> not yet published; this would allow for multiple in-flight releases.
>>>>
>>>> Steve
>>>>
>>>> > On Apr 28, 2016, at 10:44 PM, Anshum Gupta <ans...@anshumgupta.net>
>>>> wrote:
>>>> >
>>>> > I've updated the "Update Version Numbers in the Source Code" section
>>>> on the ReleaseToDo page. It'd be good to have some one else also take a
>>>> look at it.
>>>> >
>>>> > Here is what I've changed (only bug fix release):
>>>> > * Only bump up the version on the release branch using addVersion.py
>>>> > * Don't bump it up on the non-release versions in case of bug fix
>>>> release.
>>>> > * As part of the post-release process, use the commit hash from the
>>>> release branch version bump up, to increment the version on the non-release
>>>> branches.
>>>> >
>>>> > I thought we could do this for non bug-fix releases too, but I was
>>>> wrong. Minor versions need to be bumped up on stable branches (and trunk)
>>>> because during the release process for say version 6.1, there might be
>>>> commits for 6.2 and we'd need stable branches and master, both to support
>>>> those commits.
>>>> > We could debate about not needing something like this for major
>>>> versions but then I don't think it's worth the pain of different release
>>>> processes for each branch but I'm not stuck up with this.
>>>> >
>>>> >
>>>> > On Thu, Apr 28, 2016 at 5:31 PM, Anshum Gupta <ans...@anshumgupta.net>
>>>> wrote:
>>>> > That's fixed (about to commit the fix from LUCENE-7265) thought.
>>>> >
>>>> > While discussing the release process, Steve mentioned that we should
>>>> document the failing back-compat index test on the non-release branches due
>>>> to the missing index for the unreleased version.
>>>> > On discussing further, he suggested that we instead move the process
>>>> of adding the version to non-release branches as a post-release task. This
>>>> way, we wouldn't have failing tests until the release goes through and the
>>>> back-compat indexes are checked in.
>>>> >
>>>> > We still would have failing tests for the release branch but there's
>>>> no way around that.
>>>> >
>>>> > So, I'll change the documentation to move those steps as post-release
>>>> tasks.
>>>> >
>>>> >
>>>> > On Thu, Apr 28, 2016 at 11:40 AM, Anshum Gupta <
>>>> ans...@anshumgupta.net> wrote:
>>>> > Seems like LUCENE-6938 removed the merge logic that used the change
>>>> id. Now the merge doesn't happen, and there's no logic that replaces it.
>>>> >
>>>> > I certainly can do with some help on this one.
>>>> >
>>>> > On Thu, Apr 28, 2016 at 11:24 AM, Anshum Gupta <
>>>> ans...@anshumgupta.net> wrote:
>>>> > Just wanted to make sure I wasn't missing something here again. While
>>>> trying to update the version on 5x, after having done that on 5.5, using
>>>> the addVersion.py script and following the instructions, the command
>>>> consistently fails. Here's what I've been trying to do:
>>>> >
>>>> > python3 -u dev-tools/scripts/addVersion.py --changeid 49ba147 5.5.1
>>>> >
>>>> > Seems like addVersion.py is broken for minor version releases so I'd
>>>> need some help with someone who has a better understanding of python than I
>>>> do. I observed that 5.5.1 Version gets added to Version.java but also gets
>>>> marked as deprecated.
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Apr 28, 2016 at 9:27 AM, Anshum Gupta <ans...@anshumgupta.net>
>>>> wrote:
>>>> > Too much going on! Thanks Yonik.
>>>> > I'll start working on the RC now.
>>>> >
>>>> > NOTE: Please don't back port any more issues right now. In case of
>>>> exceptions, please raise them here.
>>>> >
>>>> > On Thu, Apr 28, 2016 at 9:09 AM, Yonik Seeley <ysee...@gmail.com>
>>>> wrote:
>>>> > On Thu, Apr 28, 2016 at 12:04 PM, Anshum Gupta <
>>>> ans...@anshumgupta.net> wrote:
>>>> > > Thanks. I'm waiting for the last back port of SOLR-8865.
>>>> >
>>>> > It should be already be there... I closed it yesterday.
>>>> > -Yonik
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>
>
> --
> Anshum Gupta
>



-- 
Anshum Gupta

Reply via email to