gwcelery issueshttps://git.ligo.org/emfollow/gwcelery/-/issues2024-02-22T18:35:54Zhttps://git.ligo.org/emfollow/gwcelery/-/issues/764Follow-up from "deployment release docs"2024-02-22T18:35:54ZDeep Chatterjeedeep.chatterjee@ligo.orgFollow-up from "deployment release docs"The following discussions from !1363 should be addressed:
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920068):
> The main branch must eventually also have a complete, ...The following discussions from !1363 should be addressed:
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920068):
> The main branch must eventually also have a complete, linear change log history. How will you do that?
>
> I predict that we will have _many_ copy-paste errors in the change log if we try to do this manually. If you are really sure that you want to use this branching model, then there are automated changelog management tools that can help you do this accurately, such as https://github.com/changesets/changesets.
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920069): (+1 comment)
> Are you going to preserve changelog entries for release candidates forever, or are you going to eventually merge together all of the RC changelogs once you have done a stable release?
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920070):
> Each step should have a bold heading.
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920072): (+1 comment)
> Yikes! You're going to create a release candidate every time the acceptance tests fail?
>
> Instead, how about you only create a release candidate once you are sure that the acceptance tests pass?
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920074): (+1 comment)
> Easier said than done; the changelog will be a frequent source of merge conflicts. To follow this procedure, the person who is performing the release will need to be an expert in git merge conflict resolution.
>
> Instead, I suggest that you cherry-pick changelog entries from the _main_ branch onto the release branch.
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920075): (+1 comment)
> On what branch(es)?
- [ ] @leo-singer started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_920076):
> Should codenames be for minor increments only? Or both minor and patch increments?
- [ ] @patrick.godwin started a [discussion](https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1363#note_942761): (+5 comments)
> Looking at this MR and the relevant [issue](https://git.ligo.org/emfollow/gwcelery/-/issues/737), I have a few comments/suggestions on the release procedure. While not necessarily an issue, I personally think introducing release candidates and required release branches adds extra complexity without much value added.
>
> Regarding release candidates, I don't see what this adds compared to the previous procedure, except potentially not burning releases that don't pass acceptance tests or review. I'd argue that's a failure of the workflow, however. I'd expect most of the time that the release candidate will be functionally identical to the release, but adding an extra step along the way to change/consolidate the changelog and doubling the number of releases (or more) that will be published on PyPI. Why not stick with the previous procedure to only make a release once the acceptance tests pass?
>
> Regarding the release branches, one thing we can do that could simplify this is to only make a release branch if it's needed, and otherwise make a release directly off of the main branch (as was done previously). For example, feature releases can be made directly off of main. Bug fix releases might be made directly from main if they don't introduce new features. Only in the case where making a release from main would be an issue is where a release branch is really needed, in which case a release branch is created from the last release. One benefit from this is that main is not devoid of release tags and the automatic versioning scheme that this project uses shouldn't cause issues on the main branch.
>
> Anywho, not necessarily opposing to any of the big procedural changes proposed here. I'm pitching these ideas as a way to reduce friction in making new releases in the future.O4bhttps://git.ligo.org/emfollow/gwcelery/-/issues/672Create documentation for operations2024-03-28T12:58:31ZSara ValleroCreate documentation for operationsAdd a userguide paragraph with instructions on how to operate gwcelery (documentation for on-call people).Add a userguide paragraph with instructions on how to operate gwcelery (documentation for on-call people).Roberto DePietriSara ValleroRoberto DePietrihttps://git.ligo.org/emfollow/gwcelery/-/issues/390Document redis resource requrements2021-11-05T14:30:35ZGeoffrey MoDocument redis resource requrementsDocument into the docs the updated redis resource requirements, as is discussed in #354.Document into the docs the updated redis resource requirements, as is discussed in #354.Deep Chatterjeedeep.chatterjee@ligo.orgGeoffrey MoDeep Chatterjeedeep.chatterjee@ligo.org