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
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
(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
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!
>
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
+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,
> >
>
: 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
