lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jim ferenczi <jim.feren...@gmail.com>
Subject Re: Lucene/Solr 7.5
Date Thu, 13 Sep 2018 08:29:43 GMT
Sure you can backport Tomás, the first RC is planned for tomorrow.

Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe <tomasflobbe@gmail.com>
a écrit :

> Hi Jim,
> I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for
> internal requests, but the backoff time in cases with multiple updates can
> become big, and cause clients to timeout. The change is minimal, just
> backoff once for a retry batch instead of for every doc.
>
> I'm testing a patch and plan to commit later today, if there aren't any
> issues or objections.
>
> On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi <jim.ferenczi@gmail.com>
> wrote:
>
>> Thanks !
>>
>> Le mer. 12 sept. 2018 à 11:49, Adrien Grand <jpountz@gmail.com> a écrit :
>>
>>> Hey Jim,
>>>
>>> I added you to the hudson-jobadmin group so that you can do it next time.
>>>
>>> Steve, thanks for taking care of setting up the builds!
>>>
>>> Le mar. 11 sept. 2018 à 17:32, jim ferenczi <jim.ferenczi@gmail.com> a
>>> écrit :
>>>
>>>> No worries at all Cassandra. What do you think of building the first RC
>>>> on Friday and start the vote on Monday next week ? This will leave some
>>>> room to finish the missing bits.
>>>> Could someone help to setup the Jenkins releases build ? It seems that
>>>> I cannot create jobs with my account.
>>>>
>>>> Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <casstargett@gmail.com>
>>>> a écrit :
>>>>
>>>>> Sorry, Jim, I should have replied yesterday about the state of things
>>>>> with the Ref Guide - it's close. I'm doing the last bit of big review
I
>>>>> need to do and am nearly done with that, then I have a couple more small
>>>>> things done (including SOLR-12763 which I just created since I forgot
to do
>>>>> it earlier). My goal is to be done by the end of my day today so you
could
>>>>> do the RC tomorrow, but who knows what the day will bring work-wise,
so
>>>>> I'll send another mail at the end of the day my time to let you know
for
>>>>> sure.
>>>>>
>>>>> On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi <jim.ferenczi@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I just fixed the invalid version (7.5.1) that I added in master and
>>>>>> 7x. The next version on these branches should be 7.6.0, sorry for
the noise.
>>>>>>
>>>>>> Le lun. 10 sept. 2018 à 09:26, jim ferenczi <jim.ferenczi@gmail.com>
>>>>>> a écrit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Feature freeze for 7.5 has started, I just created a branch_7_5.:
>>>>>>>
>>>>>>> * No new features may be committed to the branch.
>>>>>>> * Documentation patches, build patches and serious bug fixes
may be
>>>>>>> committed to the branch. However, you should submit all patches
you want to
>>>>>>> commit to Jira first to give others the chance to review and
possibly vote
>>>>>>> against the patch. Keep in mind that it is our main intention
to keep the
>>>>>>> branch as stable as possible.
>>>>>>> * All patches that are intended for the branch should first be
>>>>>>> committed to the unstable branch, merged into the stable branch,
and then
>>>>>>> into the current release branch.
>>>>>>> * Normal unstable and stable branch development may continue
as
>>>>>>> usual. However, if you plan to commit a big change to the unstable
branch
>>>>>>> while the branch feature freeze is in effect, think twice: can't
the
>>>>>>> addition wait a couple more days? Merges of bug fixes into the
branch may
>>>>>>> become more difficult.
>>>>>>> * Only Jira issues with Fix version "7.5" and priority "Blocker"
>>>>>>> will delay a release candidate build.
>>>>>>>
>>>>>>> I'll create the first RC later this week depending on the status
of
>>>>>>> the Solr ref guide. Cassandra, can you update the status when
you think
>>>>>>> that the ref guide is ready (no rush just a reminder that we
need to sync
>>>>>>> during this release ;) ) ?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jim
>>>>>>>
>>>>>>> Le mer. 5 sept. 2018 à 17:57, Erick Erickson <
>>>>>>> erickerickson@gmail.com> a écrit :
>>>>>>>
>>>>>>>> Great, thanks!
>>>>>>>> On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi <jim.ferenczi@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > Sure it can wait a few days. Let's cut the branch next
Monday and
>>>>>>>> we can sync with Cassandra to create the first RC when the
ref guide is
>>>>>>>> ready.
>>>>>>>> >
>>>>>>>> > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <
>>>>>>>> erickerickson@gmail.com> a écrit :
>>>>>>>> >>
>>>>>>>> >> Jim:
>>>>>>>> >>
>>>>>>>> >> I know it's the 11th hour, but WDYT about cutting
the branch next
>>>>>>>> >> Monday? We see a flurry of activity (announcing
a release does
>>>>>>>> >> that....) and waiting to cut the branch might be
easiest all
>>>>>>>> 'round.
>>>>>>>> >>
>>>>>>>> >> Up to you of course, I can backport the test fixes
I'd like for
>>>>>>>> >> instance and I'd like to get the upgraded ZooKeeper
in 7.5.
>>>>>>>> >>
>>>>>>>> >> Erick
>>>>>>>> >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett
<
>>>>>>>> casstargett@gmail.com> wrote:
>>>>>>>> >> >
>>>>>>>> >> > It's not so much the building of the RC as
giving the content
>>>>>>>> a detailed editorial review.
>>>>>>>> >> >
>>>>>>>> >> > The build/release process itself is well-documented
and
>>>>>>>> published with every Ref Guide:
>>>>>>>> https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide.
>>>>>>>> It was designed from the artifact process, so it's nearly
identical as a
>>>>>>>> process. It's really barely a burden.
>>>>>>>> >> >
>>>>>>>> >> > In terms of preparing the content, there are
a number of
>>>>>>>> things I do:
>>>>>>>> >> >
>>>>>>>> >> > First, I try to ensure that every issue in
CHANGES.txt that
>>>>>>>> should be documented has been documented. That involves an
intensive review
>>>>>>>> of CHANGES.txt and a comparison with commits to find what
might be missing,
>>>>>>>> then chasing people down to see if they intend to make changes
or not.
>>>>>>>> Assuming the person responds, then it's waiting for them
to get their stuff
>>>>>>>> done. This is usually about 2-3 days of effort, before the
waiting around
>>>>>>>> for answers and/or commits.
>>>>>>>> >> >
>>>>>>>> >> > Then I review every commit and read it for
clarity and correct
>>>>>>>> English usage. Does it fit where someone put it? Does it
explain what the
>>>>>>>> author is hoping it explains? Also, many of our authors are
not native
>>>>>>>> English writers, and deserve the assistance of an editor
to help put their
>>>>>>>> work in the best possible light. In some cases, I feel I
should extensively
>>>>>>>> edit the contribution, which occasionally involves also immersing
myself
>>>>>>>> into the change itself. This is another 2-4 days of effort.
>>>>>>>> >> >
>>>>>>>> >> > Then there's this list of problems people commit
all the time,
>>>>>>>> many of which I can often resolve reasonably quickly with
find/replace:
>>>>>>>> >> >
>>>>>>>> >> > - sentences that don't end in periods
>>>>>>>> >> > - inconsistency with instances of "i.e.," and
"e.g.," (not
>>>>>>>> "i.e.", "ie:", "IE", etc.)
>>>>>>>> >> > - no spaces between words and punctuation (commas,
colons,
>>>>>>>> periods), such as "here is :" or "word , word"
>>>>>>>> >> > - used sentence case for section titles instead
of headline
>>>>>>>> case
>>>>>>>> >> > - used abbreviations instead of the correct
word ("ZK" instead
>>>>>>>> of "ZooKeeper" being the biggest one here, but also "params"
instead of
>>>>>>>> "parameters" is quite common)
>>>>>>>> >> > - misspellings like "Zookeeper" instead of
"ZooKeeper, or
>>>>>>>> "solr" instead of "Solr"
>>>>>>>> >> > - config file names and parameter names/values
not in monospace
>>>>>>>> >> > - lists of parameters are not properly formatted
(should not
>>>>>>>> be in tables)
>>>>>>>> >> >
>>>>>>>> >> > These are all to make the Ref Guide as consistent,
cohesive,
>>>>>>>> and easy to read as possible. It may be written by 30 people
but it
>>>>>>>> shouldn't read like it is.
>>>>>>>> >> >
>>>>>>>> >> > Should I do all this while the commits are
coming through?
>>>>>>>> Sure, but the reality is I can't. If we want to release the
moment someone
>>>>>>>> proposes a release, then most of my find/replace list above
needs to go
>>>>>>>> into precommit so these problems don't make it into the Guide
to begin
>>>>>>>> with. (Which might be onerous since we'd all get stalled
waiting for
>>>>>>>> someone to fix a typo...but really, precommit is meant in
part to find your
>>>>>>>> typos so why should this be different?)
>>>>>>>> >> >
>>>>>>>> >> > It would always still need editorial review,
however, and
>>>>>>>> that's not something we'll ever be able to fully automate.
I'm more than
>>>>>>>> happy to have a little help there, but assume since people
aren't doing it
>>>>>>>> today they don't have time, don't feel they have the skills,
or don't want
>>>>>>>> to bother. Or maybe I just kill myself for a level of quality
no one else
>>>>>>>> cares about...not sure I can stop doing it though if I'm
the RM.
>>>>>>>> >> >
>>>>>>>> >> > (as a side note on that though, if we do merge
the releases
>>>>>>>> someday, then whoever RMs is going to have to wait for these
editorial
>>>>>>>> processes to be completed or the vote may fail because the
Ref Guide reads
>>>>>>>> like crap.)
>>>>>>>> >> >
>>>>>>>> >> > On Tue, Sep 4, 2018 at 11:33 AM jim ferenczi
<
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> >> >>
>>>>>>>> >> >> Thanks for explaining the situation Cassandra.
I was planning
>>>>>>>> to build the first RC beginning of next week to give people
a week to
>>>>>>>> discover blockers. I can certainly slow down things but I
don't think that
>>>>>>>> the timing
>>>>>>>> >> >> differs from other releases. I am not aware
of the operations
>>>>>>>> that are required for the Ref guide release process but what
do you think
>>>>>>>> of sharing the tasks with the RM ? We could even merge the
two releases and
>>>>>>>> make the RM responsible of both if the process is documented.
 I'd be happy
>>>>>>>> to experiment this for the 7.5 release if you want.
>>>>>>>> >> >>
>>>>>>>> >> >> Le mar. 4 sept. 2018 à 17:55, Cassandra
Targett <
>>>>>>>> casstargett@gmail.com> a écrit :
>>>>>>>> >> >>>
>>>>>>>> >> >>> I'm not objecting per se, but I feel
like we used to propose
>>>>>>>> a version and then give people a week before the branch was
cut. Maybe that
>>>>>>>> was just RM choice? From a personal perspective, I much prefer
that model
>>>>>>>> because the Ref Guide requires A LOT of my attention and
my work there
>>>>>>>> kicks into high gear as soon as a release is proposed.
>>>>>>>> >> >>>
>>>>>>>> >> >>> Even though the artifact and Ref Guide
release processes are
>>>>>>>> separate today, we want them to be a single process, so I
need to act as
>>>>>>>> though your timeframe for the RC is the deadline for Ref
Guide edits to do
>>>>>>>> an RC of the Ref Guide at the same time. That means I'm on
your timetable,
>>>>>>>> no matter what else I may have promised to my bosses and
colleagues. It's
>>>>>>>> stressful already to try to get it all done - I usually don't
finish
>>>>>>>> everything I want to do - and adding the burden of having
to backport
>>>>>>>> everything to 2 branches instead of 1 just makes it tedious
as well.
>>>>>>>> >> >>>
>>>>>>>> >> >>> Also, yesterday was a major holiday
in the US, and as of
>>>>>>>> this moment it's not even noon on the East Coast, so there's
a percentage
>>>>>>>> of the community who may not even have seen your proposal
yet.
>>>>>>>> >> >>>
>>>>>>>> >> >>> I greatly appreciate that you've volunteered
to do the
>>>>>>>> release and are energized to get it rolling, but is there
a reason an RC
>>>>>>>> has to be done by the beginning of next week?
>>>>>>>> >> >>>
>>>>>>>> >> >>> On Tue, Sep 4, 2018 at 10:36 AM Joel
Bernstein <
>>>>>>>> joelsolr@gmail.com> wrote:
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> +1,
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> I'll likely be adding some Solr
RefGuide changes later in
>>>>>>>> the week to the 7.5 branch but I'll make sure they don't
effect the build.
>>>>>>>> >> >>>>
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> Joel Bernstein
>>>>>>>> >> >>>> http://joelsolr.blogspot.com/
>>>>>>>> >> >>>>
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> On Tue, Sep 4, 2018 at 10:52 AM
jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> Thanks all,
>>>>>>>> >> >>>>> since there are no objections
I am planning to cut the
>>>>>>>> branch for 7.5 tomorrow. I'll build the first RC early next
week so there
>>>>>>>> will be some room to merge important bug fixes later this
week. All
>>>>>>>> blockers except SOLR-12727 seem to be merged/resolved, I'll
watch the
>>>>>>>> remaining solr issue for updates.
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> Le mar. 4 sept. 2018 à 10:21,
jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> a écrit :
>>>>>>>> >> >>>>>>
>>>>>>>> >> >>>>>> Sure Jan, this is a nice
cleanup, +1 to backport in 7x.
>>>>>>>> >> >>>>>>
>>>>>>>> >> >>>>>> Le mar. 4 sept. 2018 à
10:16, Jan Høydahl <
>>>>>>>> jan.asf@cominvent.com> a écrit :
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> Jim, we have some release
process improvements in
>>>>>>>> LUCENE-5143. Basically, we'll only have one KEYS file instead
of three plus
>>>>>>>> those in the versioned folders that we have today. And the
release py
>>>>>>>> script will start checking that the RM's key is present in
the KEYS file.
>>>>>>>> Would you be ok with that being committed and you being the
first RM to use
>>>>>>>> it for 7.5.0?
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> --
>>>>>>>> >> >>>>>>> Jan Høydahl, search
solution architect
>>>>>>>> >> >>>>>>> Cominvent AS - www.cominvent.com
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> 3. sep. 2018 kl. 10:42
skrev jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com>:
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> Hi all,
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> 7.4 has been released
two months ago on June 29th and we
>>>>>>>> have new features, enhancements and fixes that are not released
yet so I'd
>>>>>>>> like to start working on releasing Lucene/Solr 7.5.0.
>>>>>>>> >> >>>>>>> There's also a bad
bug with index sorting that deletes
>>>>>>>> the wrong documents when delete by query is used:
>>>>>>>> >> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-8466
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> I can create the 7.5
branch later this week and build
>>>>>>>> the first RC early next week if that works for everyone.
Please let me know
>>>>>>>> if there are bug fixes that needs to be fixed in 7.5 and
might not be ready
>>>>>>>> by then.
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>> Cheers,
>>>>>>>> >> >>>>>>> Jim
>>>>>>>> >> >>>>>>>
>>>>>>>> >> >>>>>>>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> >> 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