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 <a.benede...@sease.io> wrote: > 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 in the Changes? > > - Type of Contribution ( New Features, Improvements, Optimizations, Bug > Fixes, Dependency Upgrades, Other Changes) > - earlier release the change is appearing > - A headline containing JIRA reference, a short description, Authors > > I think all of this information can be in the commit message, author and > pull request metadata (release version and type of contribution). > I definitely like the idea of having the release note automatically > generated from the info above (potentially in a similar manner to the link > shared by David). > I admit I've not looked into technical solutions and I am not sure I can > help pragmatically, but I'll do my best if go this renovation route. > > Cheers > > > -------------------------- > *Alessandro Benedetti* > Director @ Sease Ltd. > *Apache Lucene/Solr Committer* > *Apache Solr PMC Member* > > e-mail: a.benede...@sease.io > > > *Sease* - Information Retrieval Applied > Consulting | Training | Open Source > > Website: Sease.io <http://sease.io/> > LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter > <https://twitter.com/seaseltd> | Youtube > <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github > <https://github.com/seaseltd> > > > On Thu, 16 May 2024 at 21:26, Eric Pugh <ep...@opensourceconnections.com> > wrote: > > > I *do* find our current situation the worst of all possible options! > > > > > > > On May 16, 2024, at 2:51 PM, David Smiley <dsmi...@apache.org> wrote: > > > > > > Managing CHANGES.txt in each PR/change we do is a pain. It's so > > > merge-conflict prone. I don't mean to call for the removal of > > > CHANGES.txt (although I've wished for this off-and-on), but want to > > > solicit inputs on what can be done to make this easier. > > > > > > I could be mistaken but maybe it was Calvin Cowie that recommended a > > > scheme something like the following: each change/PR merely adds its > > > own txt file to a new CHANGES directory instead of adding to > > > CHANGES.txt. Then it will be aggregated / concatenated to CHANGES.txt > > > at a release boundary by the RM using a script. The per-change file > > > then goes away. The category (e.g. New Feature vs Bug Fix) would need > > > to be encoded somewhere, like maybe in the file name. Even the JIRA > > > number could be part of the file name and not its content. No ad-hoc > > > newline use either; just write the message and the script will > > > line-wrap it. This is probably the simplest and least disruptive > > > change. > > > > > > I'm kind of envious of small projects that can simply rely on GitHub's > > > release notes generator [1]. Yeah it's just the first-line commit > > > message, which emphasizes brevity over clarity. > > > > > > [1] > > > https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > _______________________ > > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com < > > http://www.opensourceconnections.com/> | My Free/Busy < > > http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > > > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > > > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
