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

Tatiana Tereshchenko ttereshc at redhat.com
Fri Aug 21 08:54:10 UTC 2020


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.

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.

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?

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/20200821/78fcadef/attachment.htm>


More information about the Pulp-dev mailing list