[Pulp-dev] github checklist as a part of the release process

Tatiana Tereshchenko ttereshc at redhat.com
Wed Aug 19 09:57:37 UTC 2020


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 <daviddavis at 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.aguiar at 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 <ttereshc at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200819/ae8c5aaf/attachment.htm>


More information about the Pulp-dev mailing list