A separate github repo might make sense. Right now our release scripts live inside our .travis folders in repo. I don't know that they are project specific so perhaps we could move them to this new repo?
David On Wed, Aug 19, 2020 at 5:57 AM Tatiana Tereshchenko <ttere...@redhat.com> wrote: > Would a separate github repo with issues enabled make sense? > One place for all templates if we need many (I can think of at least Y and > Z releases). > One place for all release tracking, one can see what is released, and what > is not, without going from repo to repo (or from one redmine project to > another). > This repo can also have release compatibility information/table, or any > other release related data. > > I'm also not aware of any easy way of creating a template/checklist in > redmine. > > Tanya > > On Tue, Aug 18, 2020 at 4:22 PM David Davis <davidda...@redhat.com> wrote: > >> Big +1. I really like this idea and believe it could help us organize the >> work for releases. >> >> How we can apply this to Pulp though? We don't use github issues and >> there's no way to template checklists for redmine issues AFAICT. >> >> David >> >> >> On Tue, Aug 18, 2020 at 9:55 AM Fabricio Aguiar < >> fabricio.agu...@redhat.com> wrote: >> >>> I like the idea, >>> maybe it is possible to automate when closing the issue, triggering a >>> github action >>> >>> Best regards, >>> Fabricio Aguiar >>> Software Engineer, Pulp Project >>> Red Hat Brazil - Latam <https://www.redhat.com/> >>> +55 11 999652368 >>> >>> >>> On Tue, Aug 18, 2020 at 8:55 AM Tatiana Tereshchenko < >>> ttere...@redhat.com> wrote: >>> >>>> I learned recently how Fedora CoreOS folks do their releases and I >>>> really like their process. >>>> I think something similar can be useful for Pulp. We already have ~15 >>>> steps in our release guide >>>> <https://pulp.plan.io/projects/pulp/wiki/Pulp3_Release_Guide> and it's >>>> without some pre/post-release steps, like release announcement >>>> collaboration, writing blog posts, etc. >>>> >>>> The idea is simple. >>>> Have a checklist template (for each type of release if needed). >>>> Create a github issue with this checklist and mark it as you perform >>>> the steps. >>>> In addition post any relevant links as comments. >>>> Here is the example >>>> https://github.com/coreos/fedora-coreos-streams/issues/158 >>>> >>>> Benefits: >>>> - release progress is open and transparent to everyone, including our >>>> community >>>> - it's easy to look at the history if needed >>>> - release "guide" is always up to date >>>> - if one started a release and can't finish for some reason (e.g. end >>>> of working day in their time zone), another one can take over >>>> - keeps a release person more organized (those who released many times >>>> sometimes perform steps by memory and might forget some small steps; often >>>> people multitask and do something while waiting for the builds to be done. >>>> Our release guide serves the same purpose but one needs to consciously go >>>> back to it, here it requires you to click the checkbox.) >>>> >>>> Cons: >>>> - a potential downside is that it's one more action to do and a new >>>> process to follow. Though it should be very close to the release guide, so >>>> I hope it does not add much to our processes, it should not feel like >>>> something new :) >>>> >>>> Thoughts? >>>> >>>> Tanya >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
