Re: [sane-devel] Upcoming changes for handling release notes
I don't recall this conversation, where did it take place? In the past, we had a Changelog that everyone modified for every merge, and it was largely a duplicate of their commit messages. So, we stopped doing it. Are you proposing a return to that type of duplication? allan On Wed, Dec 29, 2021 at 4:57 PM Ralph Little wrote: > Hi, > > On 2021-12-29 1:30 p.m., Povilas Kanapickas wrote: > > Hello, > > > > There were some discussions on how to make handling release notes easier > > in the past so that releases are not as difficult. Time has come to > > actually implement them. > > > > What changes? > > > > Developers will need to write a short one or two sentence description to > > a new file in newsfragments directory when submitting the feature for > > review. That's it. > > > > Longer version: > > > > We'll write release notes as part of merge requests that introduce the > > features or bug fixes instead of deferring everything until the release > > time comes. > > > > This has the benefit that the release notes will be written by a more > > knowledgeable person than the release manager and we will not wait > > months only to forget what merge request was actually about. The side > > benefit of this will be that creating releases will become easier as no > > one will need to hunt all merge requests that comprise the release. > > > > The release notes for unreleased features will be stored in > > "newsfragments" directory in the repository. At the time of the release, > > the files will be combined into a single text block, edited by the > > release manager and added to the NEWS file. Storing release notes in > > separate files before the release makes it easy to avoid merge conflicts. > > > > Like I said above, for the developers almost nothing changes: just add a > > new file to the newsfragments directory with a one sentence description > > before creating a merge request. > > > > I've created a merge request with all unreleased changes since 1.0.32, > > you can see how the new process looks like in practice: > > https://gitlab.com/sane-project/backends/-/merge_requests/676 > > > > Regards, > > Povilas > > > Sounds great! > Will we clean this directory out on every release? > > Cheers, > Ralph > > > > -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Upcoming changes for handling release notes
Hi, On 2021-12-29 1:30 p.m., Povilas Kanapickas wrote: Hello, There were some discussions on how to make handling release notes easier in the past so that releases are not as difficult. Time has come to actually implement them. What changes? Developers will need to write a short one or two sentence description to a new file in newsfragments directory when submitting the feature for review. That's it. Longer version: We'll write release notes as part of merge requests that introduce the features or bug fixes instead of deferring everything until the release time comes. This has the benefit that the release notes will be written by a more knowledgeable person than the release manager and we will not wait months only to forget what merge request was actually about. The side benefit of this will be that creating releases will become easier as no one will need to hunt all merge requests that comprise the release. The release notes for unreleased features will be stored in "newsfragments" directory in the repository. At the time of the release, the files will be combined into a single text block, edited by the release manager and added to the NEWS file. Storing release notes in separate files before the release makes it easy to avoid merge conflicts. Like I said above, for the developers almost nothing changes: just add a new file to the newsfragments directory with a one sentence description before creating a merge request. I've created a merge request with all unreleased changes since 1.0.32, you can see how the new process looks like in practice: https://gitlab.com/sane-project/backends/-/merge_requests/676 Regards, Povilas Sounds great! Will we clean this directory out on every release? Cheers, Ralph
[sane-devel] Requiring GitLab merge requests for all changes
Hello, What do you think about requiring merge requests for all incoming changes on the sane-backends repository? This mostly doesn't change the current process because the majority of changes land to master via merge requests already. If the developer does not think a true review is necessary then he can merge the new merge request himself as soon as CI completes which currently introduces a delay of around 15 minutes. Out of 20 direct pushes to master since 1.0.32 we still managed to break master once (twice, if we count a MR merge without waiting for CI). This is important because any build failure will cause bisecting harder for unrelated backends. Lastly, merge requests provide a place for discussions even after a merge request is merged (e.g. if issues have been caused). Filing issue is not equivalent because there is no code review UI there. I can only think a single reasonable exception for the above policy: the push of the commit announcing a new release. With merge request we would need to create the release tag on a merge commit which is confusing. Please let me know what you think. Regards, Povilas
[sane-devel] Upcoming changes for handling release notes
Hello, There were some discussions on how to make handling release notes easier in the past so that releases are not as difficult. Time has come to actually implement them. What changes? Developers will need to write a short one or two sentence description to a new file in newsfragments directory when submitting the feature for review. That's it. Longer version: We'll write release notes as part of merge requests that introduce the features or bug fixes instead of deferring everything until the release time comes. This has the benefit that the release notes will be written by a more knowledgeable person than the release manager and we will not wait months only to forget what merge request was actually about. The side benefit of this will be that creating releases will become easier as no one will need to hunt all merge requests that comprise the release. The release notes for unreleased features will be stored in "newsfragments" directory in the repository. At the time of the release, the files will be combined into a single text block, edited by the release manager and added to the NEWS file. Storing release notes in separate files before the release makes it easy to avoid merge conflicts. Like I said above, for the developers almost nothing changes: just add a new file to the newsfragments directory with a one sentence description before creating a merge request. I've created a merge request with all unreleased changes since 1.0.32, you can see how the new process looks like in practice: https://gitlab.com/sane-project/backends/-/merge_requests/676 Regards, Povilas
