[Evergreen-dev] Evergreen point release discussion

[Lussier, Kathy]

Thank you for the summary Jason!

I am too far away from the code and bug tracking to make significant
contributions to a release, but if you need somebody to tap people on the
shoulder to remind them of a release, I'm happy to serve in that role. But
it also may be better suited to a person more heavily involved in releases.
Just let me know if I should do it and when and whom I should tap.

A requirement to include release notes with every code
> branch was raised as a possible solution to this issue.  Such a
> requirement would simplify the task of putting together release notes
> to a mostly copy and paste operation.


One benefit of this requirement is if developers get in the habit of
writing release notes with every code contribution, they may be less likely
to forget them for new features. When I was writing release notes, I often
found that the commit messages could often serve as the release notes entry
for a lot of the bug fixes. In other cases, though, the commit message
didn't convey good information  on the problem that was being solved, and
it often required going back to the LP bug to puzzle through what the end
benefit was to the bug fix.

Happy holidays everyone!

Kathy
--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org




On Fri, Dec 22, 2023 at 3:59 PM Jason Stephenson via Evergreen-dev <
evergreen-dev at list.evergreen-ils.org> wrote:

> Below is a summary of the point release discussion from the IRC
> Developers' Meeting on Tuesday, 12 December 2023.  I have endeavored
> to do the summary without much editorializing, other than the choice
> of what to include.
>
> The meeting minutes are here:
> <
> http://evergreen-ils.org/meetings/evergreen/2023/evergreen.2023-12-12-15.00.html
> >.
>
> The HTML log is here:
> <
> http://evergreen-ils.org/meetings/evergreen/2023/evergreen.2023-12-12-15.00.log.html
> >.
>
> The log contains discussion that did not make it into the minutes.
> The following summary is based on the log.
>
> The following issues were identified:
>
>    * lack of availability for some community members
>    * lack of coordination of releases
>    * difficulty of certain parts of the process
>
> There is a perceived lack of people who can commit to help with
> monthly bug fix releases.  At least one person expressed that they
> cannot make it on the third Wednesday of every month.  To help with
> this, the suggestion was made to reduce the frequency to bimonthly or
> quarterly.
>
> A consensus to stick with the current schedule emerged.  The following
> benefits of more frequent releases were cited:
>
>   * more opportunity for knowledge sharing
>   * less drift in the upgrade script
>   * less chance for the process to be forgotten
>   * more incentive to improve the process
>
> The possibility of having one person, or a team, be responsible for
> maintaining each active series was discussed as a possible way to
> ensure more participation in the monthly release process.  The most
> serious suggestion along these lines is to have the release team, or
> members of the release team, take over maintenance duties for a given
> Evergreen branch.
>
> One of the bigger issues with getting point releases done is that the
> release dates often come and go with no fanfare.  There was agreement
> that the community needs someone to step into the role of reminding us
> when releases dates are coming up and to organize a team to get
> releases done.
>
> The #evergreen-release IRC channel and a spreadsheet
>
> <
> https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0
> >
>
> had been used to organize releases in the past.  The community
> recently decided to discontinue the use of the #evergreen-release
> channel.  Alternatives to IRC were discussed briefly.  The consensus
> is to have release discussions in the main #evergreen channel on the
> Libera IRC network for now.
>
> Release notes and translations emerged as two procedural sticking
> points in getting releases made.  Both of these touch on issues of
> process and availability.
>
> In the case of release notes, someone has to write them before we can
> release.  This can be a tedious task involving looking through git
> commits.  A requirement to include release notes with every code
> branch was raised as a possible solution to this issue.  Such a
> requirement would simplify the task of putting together release notes
> to a mostly copy and paste operation.
>
> The current translation process adds extra steps to the build and
> requires requires special permissions on POEditor in order to complete
> that part of the process.  This is a real hurdle as Angular
> translations have to be skipped if someone is not around who can do
> the steps.
>
> In the end, it was decided that releases for 3.10.4 and 3.11.2 would
> be made/attempted on Wednesday, December 13 to coincide with the
> Evergreen 3.12.0 release.  These releases were made, albeit with some
> difficulty.
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20231222/37317095/attachment.htm>