: The thing about commit messages is they can't easily be cleaned up after
: they are pushed... mistakes there are permanent.
Exactly.
In particular, a feature might be collaboratively developed & committed by
Alice & Bob; but then before it's ever released Carl might find a bug with
the ne
+1 for SOLR-17275 blocking 9.6.1
On Tue, May 14, 2024 at 4:21 PM David Smiley wrote:
> Thanks for volunteering:
> https://issues.apache.org/jira/browse/SOLR-17275 is a blocker IMO.
> It's being looked at now.
>
> On Tue, May 14, 2024 at 3:38 PM Houston Putman wrote:
> >
> > Hey everyone,
> >
>
I think SOLR-17296 is a good candidate (serious enough issue, with a safe
enough solution) but it's needs eyeballs on it ASAP...
https://issues.apache.org/jira/browse/SOLR-17296
: Date: Tue, 14 May 2024 14:37:53 -0500
: From: Houston Putman
: Reply-To: dev@solr.apache.org
: To: dev@solr.apac
Only 22nd works for me, but I keep forgetting to show up so that's probably
only information that should be used for a tie-break.
On Fri, May 17, 2024 at 9:51 AM Alessandro Benedetti
wrote:
> (1) (3) and (4) for me!
> Thanks for the heads up Jason and thanks Raghavan for volunteering!
>
(1) (3) and (4) for me!
Thanks for the heads up Jason and thanks Raghavan for volunteering!
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*
e-mail: a.benede...@sease.io
*Sease* - Information Retrieval Applied
Consult
The thing about commit messages is they can't easily be cleaned up after
they are pushed... mistakes there are permanent.
On Fri, May 17, 2024 at 9:47 AM Alessandro Benedetti
wrote:
> I feel the same.
> It's error-prone, easy to forget and even easier to end up with conflicts.
>
> Sure, once the
I feel the same.
It's error-prone, easy to forget and even easier to end up with conflicts.
Sure, once there, it's useful and I end up reading it from time to time, to
quickly refresh on the latest contributions I (or my team) did (but the git
log is more than enough for that).
In the end, what's