I like the idea yet I also wonder if most folks simply won't care to provide any input anyway, and then it becomes just yet another release task. Also, I wouldn't want to recommend any process that would need to be rethought if we streamline CHANGES.txt management (e.g. we spoke of using separate files and a script that generates a combined one). But we could piggy-back off of such... like that would end up generating a CHANGES.txt section of the release, and thus it could easily be posted as a PR for follow-up editing.
On Wed, Jul 24, 2024 at 12:44 PM Eric Pugh <ep...@opensourceconnections.com> wrote: > > I was thinking that as part of our release process we should have a “review > CHANGES.txt” step? I don’t know if that is already in there, but it might > be a good step for us as a community to have a single point in time to review > that to make sure it’s clear and accurate…. > > We have lots of folks contributing to it, each with their own style and their > own opinion of what change is what type of change, and so maybe having a step > in the release process to say “Hey, now is the time to review these to make > it look the best it can” might help? > > Eric > > _______________________ > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
