I went back through versions.props and I think there are only two that can
be removed:
commons-text - https://github.com/apache/solr/pull/1539 - this one is simple
joda-time - https://github.com/apache/solr/pull/1540 - this one is slightly
more complicated
But out of the 76 lines we define only
This PR will allow comments in versions.props:
https://github.com/apache/solr/pull/1537, as long as the rest of the lines are
sorted...
Jan
> 3. apr. 2023 kl. 22:09 skrev David Smiley :
>
> gradle/validation/versions-props-sorted.gradle
> -- will fail if you add a comment to this file.
I think for a lot of us the rapid release cycle of other projects is
surprising coming from our ASF context. Here a release takes three votes
and at least three days and comparatively quite a bit of process. For some
other project, a release involves as little as clicking a button to make a
github
gradle/validation/versions-props-sorted.gradle
-- will fail if you add a comment to this file. It insists that the file
is sorted. It also generates the file sorted if it isn't. So if we want
to support comments, we'll need to remove generating the file and remove
the comments in checking for
+1 to keeping dependencies up to date.
But we don't necessarily need to do it every week, if people feel it is noisy.
We could disable the bot until we start thinking about a new release, and then
get a ton of upgrades to merge for the new release. Personally I prefer smaller
bulks each week.
I'll set one up today (12-16 hours from now).
On Tue, 4 Apr, 2023, 12:21 am Shawn Heisey, wrote:
> On 3/31/23 03:47, Alessandro Benedetti wrote:
> > Thanks Ishan for organizing! I'll be there!
> > --
> > *Alessandro Benedetti*
> > Director @ Sease Ltd.
> > *Apache
On 3/31/23 03:47, Alessandro Benedetti wrote:
Thanks Ishan for organizing! I'll be there!
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*
e-mail: a.benede...@sease.io
*Sease* - Information Retrieval Applied
An update on the failing test.
The failure comes from documents having null version field from the add
operations running in parallel with the split shard operation.
Digging into this a bit more (and running the test a very large number of
times) I think I identified 3 problematic cases that can
Welcome Marcus!
On Mon, Apr 3, 2023 at 7:32 AM Houston Putman
wrote:
> Congrats Marcus!
>
> - Houston
>
> On Mon, Apr 3, 2023 at 9:48 AM Michael Gibney
> wrote:
>
> > Welcome, Marcus!
> >
> > On Mon, Apr 3, 2023 at 9:02 AM Jason Gerlowski
> > wrote:
> > >
> > > Congrats and welcome!
> > >
> >
So an outcome here is: groom versions.properties to not have needless
references to transitive dependencies.
It's too bad the format of this file doesn't support comments so that we
can explain our justification for listing a transitive dependency. Maybe
that would be easy for us to add.
~
Good idea Gus!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Apr 3, 2023 at 11:30 AM Gus Heck wrote:
> The only thing I think I would add is that perhaps we should think of
> things in terms of upgrading our direct dependencies. That
solrbot only updates things in versions.props. The PRs have found a few
cases where we could remove a few old transitive dependency pins in
versions.props. versions.props only has direct dependencies so not going
out of the way to upgrade transitive dependencies. That being said, the
direct
The only thing I think I would add is that perhaps we should think of
things in terms of upgrading our direct dependencies. That ensures the
proper testing at the preceding levels. Updates of transitive deps are
somewhat more risky, though justifiable if there is a valid security
concern such as
I screwed this up merging s3mock upgrade when I thought tests pass. The
change has already been reverted and being looked at here:
https://github.com/apache/solr/pull/1535
Kevin Risden
On Mon, Apr 3, 2023 at 11:03 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
Thanks for finding this!
Since we operate in git almost all of the time these things are hard to
find.
I imagine the only way going forward would be to disable the
":solr:solr-ref-guide:buildLocalAntoraSite" task by default if the project
is not in a git repo.
Not sure how to do that elegantly
I agree with Jason and Kevin that it's better to err on the side of
updating dependencies faster than updating them slower.
We have (hopefully) comprehensive testing for a lot of the features that
these dependencies are used for, and as Jason said we have ultimate
discretion in merging.
In
Congrats Marcus!
- Houston
On Mon, Apr 3, 2023 at 9:48 AM Michael Gibney
wrote:
> Welcome, Marcus!
>
> On Mon, Apr 3, 2023 at 9:02 AM Jason Gerlowski
> wrote:
> >
> > Congrats and welcome!
> >
> > On Sun, Apr 2, 2023 at 3:28 PM Noble Paul wrote:
> > >
> > > Congrats Marcus
> > >
> > >
Thank you, David and Houston!
On Sat, Apr 1, 2023 at 4:11 PM Anshum Gupta wrote:
>
> Congratulations David and thanks a lot for your service, Houston!
>
> On Fri, Mar 31, 2023 at 10:34 PM Houston Putman wrote:
>
> > Hello,
> >
> > Solr has had quite a year, with a major release and many cool
Welcome, Marcus!
On Mon, Apr 3, 2023 at 9:02 AM Jason Gerlowski wrote:
>
> Congrats and welcome!
>
> On Sun, Apr 2, 2023 at 3:28 PM Noble Paul wrote:
> >
> > Congrats Marcus
> >
> > Welcome
> >
> > On Mon, Apr 3, 2023, 4:00 AM Justin Sweeney
> > wrote:
> >
> > > Congratulations Marcus!
> > >
>
Congratulations and welcome, Marcus.
On Sat, Apr 1, 2023 at 12:49 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Hi all,
>
> I'm pleased to announce that Marcus Eagan has accepted the PMC's
> invitation to become a committer.
>
> Marcus, the tradition is that new committers
Congrats and welcome!
On Sun, Apr 2, 2023 at 3:28 PM Noble Paul wrote:
>
> Congrats Marcus
>
> Welcome
>
> On Mon, Apr 3, 2023, 4:00 AM Justin Sweeney
> wrote:
>
> > Congratulations Marcus!
> >
> > On Sun, Apr 2, 2023 at 12:48 PM Gus Heck wrote:
> >
> > > Congratulations and Welcome!
> > >
> >
Hi all,
New releases of dependencies can introduce new bugs for sure. But I
think the rationale is generally that on the whole, a new release of
dependency Foo is going to fix more than it breaks (otherwise why
would the Foo project have done the release).
Particularly since we still have
22 matches
Mail list logo
