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

David Davis daviddavis at redhat.com
Tue Aug 25 14:11:13 UTC 2020


On Fri, Aug 21, 2020 at 4:54 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> Good to know that Redmine has some sort of template as well.
>
> I tested some and it seems like Redmine checklists are good when you want
> to specify in a short form each step and all in one list.
> The limitations which I noticed (let me know if I used something
> incorrectly):
>  - no multiline items (sometimes we put explanations for a step or
> examples)
>  - no structure, no nested items (IMO, it would be useful to have some
> pre-release, release, and post release items. Structure makes it more
> readable)
>  - text formatting is limited, e.g. a code snippet will change the font a
> bit but not add any background colour for readability.
>
> Having said that, those are not blockers but noticeable inconveniences.
>

Agreed.


>
> Here are my experiments.
> The template
> https://pulp.plan.io/projects/migration/checklist_templates/2/edit
> The checklist from the template https://pulp.plan.io/issues/7364
>
> I think one of the goals is to substitute our release guide and not create
> one more item to keep up to date.
> So just for reference, here is the release guide
> https://pulp.plan.io/projects/pulp/wiki/Pulp3_Release_Guide which I
> expect to be expanded a bit with pre-release activities at least.
>

+1. I'm imagining the release process will be to create a release issue
with the checklist and then just check items off. The PR(s) could be
attached to the release issue.


>
> A separate question.
> As a user, how can I easily see ongoing releases across pulp projects or
> recently published releases? Something that I can bookmark and track. Is
> the idea to have a redmine query for that?
>

I think a query makes sense. Maybe a Release tracker type or tag?


>
> Thanks for looking into that!
> Tanya
>
> On Thu, Aug 20, 2020 at 8:26 PM David Davis <daviddavis at redhat.com> wrote:
>
>> Nice find. I tested it and it works pretty well. I'm leaning towards us
>> using this in redmine but I have no objection with github issues.
>>
>> David
>>
>>
>> On Thu, Aug 20, 2020 at 10:44 AM Matthias Dellweg <mdellweg at redhat.com>
>> wrote:
>>
>>> You can have checklist_templates in redmine:
>>> https://pulp.plan.io/projects/pulp_container/settings/checklist_template
>>>
>>> However it's like 3 clicks to add that checklist to a task you are about
>>> to create. Maybe it is even possible to create a new tracker (called
>>> release) where every issue automatically gets that release checklist.
>>>
>>> On Wed, Aug 19, 2020 at 11:14 PM David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> Another idea: have the release PR contain the checklist. Then it would
>>>> all be in one place.
>>>>
>>>> David
>>>>
>>>>
>>>> On Wed, Aug 19, 2020 at 4:40 PM Fabricio Aguiar <
>>>> fabricio.aguiar at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 19, 2020 at 12:02 PM David Davis <daviddavis at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>> The script just get the plugin name, I believe it is easy to move to
>>>>> another repo and do something similar we do oat pulp-ci
>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 19, 2020 at 5:57 AM Tatiana Tereshchenko <
>>>>>> ttereshc at 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 <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
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>> 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/20200825/1d9b3c31/attachment.htm>


More information about the Pulp-dev mailing list