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 Wed, 12 Sep 2018 12:38:46 GMT
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