> A script to use git commit data to help create CHANGES entries (or look
> for CHANGES entries that are missing credit) seems like a good sanity
> check to ensuring nothing trivial is overlooked in CHANGES.
That's an interesting idea. Not to add CHANGES entries for the smallest
ref-guide typo.
I’d like to have both committers and contributers included, not just
contributors. If it’s just contributors, and the list is short, then it may
appear we have a very small community ;-).
I do like the idea of thanking folks!
> On Apr 26, 2024, at 9:45 PM, Chris Hostetter wrote:
>
>
> : LO
: LOL meanwhile I posted https://github.com/apache/solr/pull/2424 for
: the script I developed and improved today.
: I think CHANGES.txt is the best source for a release centric view
: while git log is best for project health metrics.
Agreed. People are frequently mentioned in CHANGES because th
LOL meanwhile I posted https://github.com/apache/solr/pull/2424 for
the script I developed and improved today.
I think CHANGES.txt is the best source for a release centric view
while git log is best for project health metrics.
On Fri, Apr 26, 2024 at 4:38 PM Jan Høydahl wrote:
>
> I think it is a
> The changelog has the names. Repeating it in the release announcement mail
> feels redundant to me.
Being redundant in this case is not a problem. The DRY principle applies to
code, not expressions of gratitude.
Names are included to honor and thank the people who have helped. The point is
n
I think it is a good idea to include a list of contributors in the release note
mail.
it is a tiny encouragement for folks to contribute more. The list should perhaps
be excluding committers, so we only list external contributors?
I already added a script to dev-tools to parse SolrBot contributio
The changelog has the names. Repeating it in the release announcement mail
feels redundant to me.
On Fri, 26 Apr, 2024, 11:07 pm Andy Lester, wrote:
>
> > The context of the name appearing as I propose in a "thank you" is
> > merely to thank them, not to indirectly hold them to stability/quality
> The context of the name appearing as I propose in a "thank you" is
> merely to thank them, not to indirectly hold them to stability/quality
> measures.
I heartily endorse listing everyone who did something on a release.
It drives me crazy every time there is a release of GCC that ends with t
I like it!
> On Apr 26, 2024, at 9:39 AM, David Smiley wrote:
>
> On Fri, Apr 26, 2024 at 9:35 AM Gus Heck wrote:
>>
>> I don't know if it's relevant, but I recall that back in the early 2000's
>> around the time of the adoption of the ASL 2.0 (when I was contributing to
>> Ant) the ASF had us
On Fri, Apr 26, 2024 at 9:35 AM Gus Heck wrote:
>
> I don't know if it's relevant, but I recall that back in the early 2000's
> around the time of the adoption of the ASL 2.0 (when I was contributing to
> Ant) the ASF had us stop using @author tags in code. I was not a fan at the
> time, but they
I don't know if it's relevant, but I recall that back in the early 2000's
around the time of the adoption of the ASL 2.0 (when I was contributing to
Ant) the ASF had us stop using @author tags in code. I was not a fan at the
time, but they had some reason I don't fully recall relating to shielding
The 9.6 release is upon us. I'd like to find a way of highlighting
more prominently who contributed to the release in the release
announcement. Something like:
Thank you to those who contributed to this release: David Smiley,
Gus Heck, Christine Poerschke
(Of course the actual list for 9.6 i
We should encourage committers to include Author and Co-Authored-By tags in
commit message even for patches in Jira. This way contributors are credited in
git log history too. And it gives us a way to get rid of CHANGES.txt some
beautiful day ☀️
Jan Høydahl
> 13. feb. 2024 kl. 09:21 skrev Isha
Keep in mind the regulations in some part of the world if you plan to
maintain a file containing "full name, primary email, and email aliases"
For example
https://europa.eu/youreurope/citizens/consumers/internet-telecoms/data-protection-online-privacy/index_en.htm
Ilan
On Tue, Feb 13, 2024 at 8:1
: Looking up CHANGES.txt is inevitable. Sometimes reporting a bug in JIRA is
: also a valid contribution. That gets tracked in CHANGES.txt.
Agreed.
Commit != Contribute.
If it was that simple there wouldn't be any CHANGES.txt entries with more
then one name.
-Hoss
http://www.lucidworks.co
Looking up CHANGES.txt is inevitable. Sometimes reporting a bug in JIRA is
also a valid contribution. That gets tracked in CHANGES.txt.
On Tue, 13 Feb 2024 at 12:41, David Smiley wrote:
> I'm working on a script to track contributors so that (A) we can track
> project health for ASF board report
16 matches
Mail list logo
