Re: [Pulp-dev] Release Note Process Improvements

[Brian Bouterse]

Great with the issue groomed, and much +1 feedback I think we should put it
in place soon so we can start having an accurate changelog for rc3. I am
planning to pick this up and so I've taken the issue as assigned. I'll post
PRs on this thread so everyone can see once they area available (hopefully
tomorrow or Thurs at latest).

More comments, ideas, or concerns are also welcome.

On Tue, May 28, 2019 at 3:53 PM Daniel Alley  wrote:

> +1
>
> On Tue, May 28, 2019 at 2:23 PM Dennis Kliban  wrote:
>
>> +1
>>
>> I updated the task[0] slightly and marked it as groomed.
>>
>>
>> [0] https://pulp.plan.io/issues/4875
>>
>> On Tue, May 28, 2019 at 12:14 PM Austin Macdonald 
>> wrote:
>>
>>> The proposed changes look awesome! I'm +1 for moving forward with it for
>>> pulpcore and pulpcore-plugin.
>>>
>>> If there is consensus (looks like we are close), lets go ahead. If
>>> anyone has concerns, we also have the option to implement this change for
>>> one plugin before we go all in.
>>>
>>> On Mon, May 27, 2019 at 5:26 AM Ina Panova  wrote:
>>>
 +1


 
 Regards,

 Ina Panova
 Senior Software Engineer| Pulp| Red Hat Inc.

 "Do not go where the path may lead,
  go instead where there is no path and leave a trail."


 On Sat, May 25, 2019 at 10:18 PM Tatiana Tereshchenko <
 ttere...@redhat.com> wrote:

> +1 to improve release notes process
>
> If we decide to use PR numbers and not redmine issues in the release
> notes, then there will be no limitation/requirement to have a redmine 
> issue
> to add something to the release notes.
>
> Tanya
>
> On Fri, May 24, 2019 at 3:46 PM David Davis 
> wrote:
>
>> +1 to bmbouter's proposal and not including '[noissue]' items in
>> release notes.
>>
>> David
>>
>>
>> On Fri, May 24, 2019 at 3:52 AM Matthias Dellweg 
>> wrote:
>>
>>> I am fine with stating "[noissue] means 'not worth mentioning in
>>> release notes'".
>>> This would require the reviewer to decide to tell the contributor:
>>> "We
>>> want that to be part of the release notes. Please open up a ticket."
>>> And that process scales better than handpicking the notes in the end.
>>>
>>> On Thu, 23 May 2019 16:22:36 -0400
>>> Dana Walker  wrote:
>>>
>>> > My initial thought is this looks useful to the user and very clean.
>>> > I've also found it to be a burden trying to write good release
>>> notes,
>>> > having to dig through commits and try to decide what's important
>>> > enough and what's not, so +1 to trying to improve this process for
>>> > both the releaser and user.
>>> >
>>> > However:
>>> > "towncrier works best in a development system where all merges
>>> involve
>>> > closing a ticket."
>>> > We frequently make use of "[noissue]" in our PRs, in part to lower
>>> the
>>> > burden on contributors making small fixes.  Would we want to move
>>> to a
>>> > model where we *must* have an issue?  Are we instead assuming those
>>> > items are small enough that the user doesn't need to see it in the
>>> > release notes?
>>> >
>>> > Thoughts?
>>> >
>>> > --Dana
>>> >
>>> > Dana Walker
>>> >
>>> > She / Her / Hers
>>> >
>>> > Software Engineer, Pulp Project
>>> >
>>> > Red Hat 
>>> >
>>> > dawal...@redhat.com
>>> > 
>>> >
>>> >
>>> >
>>> > On Thu, May 23, 2019 at 3:49 PM Brian Bouterse <
>>> bbout...@redhat.com>
>>> > wrote:
>>> >
>>> > > In discussion with some other devs, I've realized that pulpcore
>>> and
>>> > > pulpcore-plugin would benefit from better release notes. Here are
>>> > > some of the reasons that have come up:
>>> > >
>>> > > * The release notes are incomplete. One person tries to go
>>> through
>>> > > and write release notes just before the release happens, and by
>>> > > that point, the number of changes are too many for this approach
>>> to
>>> > > produce complete and robust notes.
>>> > > * They are hard to produce. Producing "all the release notes" is
>>> a
>>> > > mentally difficult task.
>>> > > * We try to substitute with Redmine, but this approach limits us
>>> > > (a) it's now difficult and time consuming to see what changed,
>>> (b)
>>> > > there is way more detail than you actually want, and they aren't
>>> > > self-contained (can't be browsed off-line).
>>> > > * overall all ^ leads to both users and plugin writers feeling
>>> > > uncertain about what has changed in the last release, week, or
>>> even
>>> > > day.
>>> > >
>>> > > So what can we do? Recently I contributed to aiohttp and I found
>>> > > their release note process light and easy. It produces
>>> high-quality
>>> > > rel

Re: [Pulp-dev] Release Note Process Improvements

[Daniel Alley]

+1

On Tue, May 28, 2019 at 2:23 PM Dennis Kliban  wrote:

> +1
>
> I updated the task[0] slightly and marked it as groomed.
>
>
> [0] https://pulp.plan.io/issues/4875
>
> On Tue, May 28, 2019 at 12:14 PM Austin Macdonald 
> wrote:
>
>> The proposed changes look awesome! I'm +1 for moving forward with it for
>> pulpcore and pulpcore-plugin.
>>
>> If there is consensus (looks like we are close), lets go ahead. If anyone
>> has concerns, we also have the option to implement this change for one
>> plugin before we go all in.
>>
>> On Mon, May 27, 2019 at 5:26 AM Ina Panova  wrote:
>>
>>> +1
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Senior Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>  go instead where there is no path and leave a trail."
>>>
>>>
>>> On Sat, May 25, 2019 at 10:18 PM Tatiana Tereshchenko <
>>> ttere...@redhat.com> wrote:
>>>
 +1 to improve release notes process

 If we decide to use PR numbers and not redmine issues in the release
 notes, then there will be no limitation/requirement to have a redmine issue
 to add something to the release notes.

 Tanya

 On Fri, May 24, 2019 at 3:46 PM David Davis 
 wrote:

> +1 to bmbouter's proposal and not including '[noissue]' items in
> release notes.
>
> David
>
>
> On Fri, May 24, 2019 at 3:52 AM Matthias Dellweg 
> wrote:
>
>> I am fine with stating "[noissue] means 'not worth mentioning in
>> release notes'".
>> This would require the reviewer to decide to tell the contributor: "We
>> want that to be part of the release notes. Please open up a ticket."
>> And that process scales better than handpicking the notes in the end.
>>
>> On Thu, 23 May 2019 16:22:36 -0400
>> Dana Walker  wrote:
>>
>> > My initial thought is this looks useful to the user and very clean.
>> > I've also found it to be a burden trying to write good release
>> notes,
>> > having to dig through commits and try to decide what's important
>> > enough and what's not, so +1 to trying to improve this process for
>> > both the releaser and user.
>> >
>> > However:
>> > "towncrier works best in a development system where all merges
>> involve
>> > closing a ticket."
>> > We frequently make use of "[noissue]" in our PRs, in part to lower
>> the
>> > burden on contributors making small fixes.  Would we want to move
>> to a
>> > model where we *must* have an issue?  Are we instead assuming those
>> > items are small enough that the user doesn't need to see it in the
>> > release notes?
>> >
>> > Thoughts?
>> >
>> > --Dana
>> >
>> > Dana Walker
>> >
>> > She / Her / Hers
>> >
>> > Software Engineer, Pulp Project
>> >
>> > Red Hat 
>> >
>> > dawal...@redhat.com
>> > 
>> >
>> >
>> >
>> > On Thu, May 23, 2019 at 3:49 PM Brian Bouterse > >
>> > wrote:
>> >
>> > > In discussion with some other devs, I've realized that pulpcore
>> and
>> > > pulpcore-plugin would benefit from better release notes. Here are
>> > > some of the reasons that have come up:
>> > >
>> > > * The release notes are incomplete. One person tries to go through
>> > > and write release notes just before the release happens, and by
>> > > that point, the number of changes are too many for this approach
>> to
>> > > produce complete and robust notes.
>> > > * They are hard to produce. Producing "all the release notes" is a
>> > > mentally difficult task.
>> > > * We try to substitute with Redmine, but this approach limits us
>> > > (a) it's now difficult and time consuming to see what changed, (b)
>> > > there is way more detail than you actually want, and they aren't
>> > > self-contained (can't be browsed off-line).
>> > > * overall all ^ leads to both users and plugin writers feeling
>> > > uncertain about what has changed in the last release, week, or
>> even
>> > > day.
>> > >
>> > > So what can we do? Recently I contributed to aiohttp and I found
>> > > their release note process light and easy. It produces
>> high-quality
>> > > release notes like these:
>> > > https://aiohttp.readthedocs.io/en/stable/changes.html
>> > >
>> > > You can read about their process here:
>> > >
>> https://aiohttp.readthedocs.io/en/stable/contributing.html#changelog-update
>> > > You can see some examples of these release note files in their
>> repo
>> > > here: https://github.com/aio-libs/aiohttp/tree/master/CHANGES
>> > > Overall it makes use of the towncrier project
>> > > https://github.com/hawkowl/towncrier
>> > >
>> > > What do you all think about trying something like this for
>> pulpcore
>> > > and pulpcore-plugin

Re: [Pulp-dev] Release Note Process Improvements

[Dennis Kliban]

+1

I updated the task[0] slightly and marked it as groomed.


[0] https://pulp.plan.io/issues/4875

On Tue, May 28, 2019 at 12:14 PM Austin Macdonald  wrote:

> The proposed changes look awesome! I'm +1 for moving forward with it for
> pulpcore and pulpcore-plugin.
>
> If there is consensus (looks like we are close), lets go ahead. If anyone
> has concerns, we also have the option to implement this change for one
> plugin before we go all in.
>
> On Mon, May 27, 2019 at 5:26 AM Ina Panova  wrote:
>
>> +1
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Senior Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>>
>> On Sat, May 25, 2019 at 10:18 PM Tatiana Tereshchenko <
>> ttere...@redhat.com> wrote:
>>
>>> +1 to improve release notes process
>>>
>>> If we decide to use PR numbers and not redmine issues in the release
>>> notes, then there will be no limitation/requirement to have a redmine issue
>>> to add something to the release notes.
>>>
>>> Tanya
>>>
>>> On Fri, May 24, 2019 at 3:46 PM David Davis 
>>> wrote:
>>>
 +1 to bmbouter's proposal and not including '[noissue]' items in
 release notes.

 David


 On Fri, May 24, 2019 at 3:52 AM Matthias Dellweg 
 wrote:

> I am fine with stating "[noissue] means 'not worth mentioning in
> release notes'".
> This would require the reviewer to decide to tell the contributor: "We
> want that to be part of the release notes. Please open up a ticket."
> And that process scales better than handpicking the notes in the end.
>
> On Thu, 23 May 2019 16:22:36 -0400
> Dana Walker  wrote:
>
> > My initial thought is this looks useful to the user and very clean.
> > I've also found it to be a burden trying to write good release notes,
> > having to dig through commits and try to decide what's important
> > enough and what's not, so +1 to trying to improve this process for
> > both the releaser and user.
> >
> > However:
> > "towncrier works best in a development system where all merges
> involve
> > closing a ticket."
> > We frequently make use of "[noissue]" in our PRs, in part to lower
> the
> > burden on contributors making small fixes.  Would we want to move to
> a
> > model where we *must* have an issue?  Are we instead assuming those
> > items are small enough that the user doesn't need to see it in the
> > release notes?
> >
> > Thoughts?
> >
> > --Dana
> >
> > Dana Walker
> >
> > She / Her / Hers
> >
> > Software Engineer, Pulp Project
> >
> > Red Hat 
> >
> > dawal...@redhat.com
> > 
> >
> >
> >
> > On Thu, May 23, 2019 at 3:49 PM Brian Bouterse 
> > wrote:
> >
> > > In discussion with some other devs, I've realized that pulpcore and
> > > pulpcore-plugin would benefit from better release notes. Here are
> > > some of the reasons that have come up:
> > >
> > > * The release notes are incomplete. One person tries to go through
> > > and write release notes just before the release happens, and by
> > > that point, the number of changes are too many for this approach to
> > > produce complete and robust notes.
> > > * They are hard to produce. Producing "all the release notes" is a
> > > mentally difficult task.
> > > * We try to substitute with Redmine, but this approach limits us
> > > (a) it's now difficult and time consuming to see what changed, (b)
> > > there is way more detail than you actually want, and they aren't
> > > self-contained (can't be browsed off-line).
> > > * overall all ^ leads to both users and plugin writers feeling
> > > uncertain about what has changed in the last release, week, or even
> > > day.
> > >
> > > So what can we do? Recently I contributed to aiohttp and I found
> > > their release note process light and easy. It produces high-quality
> > > release notes like these:
> > > https://aiohttp.readthedocs.io/en/stable/changes.html
> > >
> > > You can read about their process here:
> > >
> https://aiohttp.readthedocs.io/en/stable/contributing.html#changelog-update
> > > You can see some examples of these release note files in their repo
> > > here: https://github.com/aio-libs/aiohttp/tree/master/CHANGES
> > > Overall it makes use of the towncrier project
> > > https://github.com/hawkowl/towncrier
> > >
> > > What do you all think about trying something like this for pulpcore
> > > and pulpcore-plugin? Please write back on-list with thoughts,
> > > ideas, concerns, alternatives, etc.
> > >
> > > Also, I made us a starter issue to coalesce some more of the
> > > practical aspect of adopting a change like this:
> > > https://pulp.pla

[Pulp-dev] 2019 Pulp Community Survey

[David Davis]

Today we are asking for community feedback in our second Pulp Community
Survey. The feedback we received in our first community survey provided
valuable insights into how our users use Pulp. For our second Community
Survey, we hope to also get feedback into how we can improve the upcoming
Pulp 3 release from users, contributors, and other community members.

We’re giving away Pulp gear (t-shirt, socks, stickers, etc) to anyone who
fills out the survey. More importantly, by filling out the survey, you’ll
help us to improve Pulp. So if you have a few minutes, please visit the
link below to fill out the survey.

https://tinyurl.com/pulp2019survey

David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Release Note Process Improvements

[Austin Macdonald]

The proposed changes look awesome! I'm +1 for moving forward with it for
pulpcore and pulpcore-plugin.

If there is consensus (looks like we are close), lets go ahead. If anyone
has concerns, we also have the option to implement this change for one
plugin before we go all in.

On Mon, May 27, 2019 at 5:26 AM Ina Panova  wrote:

> +1
>
>
> 
> Regards,
>
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
>
> On Sat, May 25, 2019 at 10:18 PM Tatiana Tereshchenko 
> wrote:
>
>> +1 to improve release notes process
>>
>> If we decide to use PR numbers and not redmine issues in the release
>> notes, then there will be no limitation/requirement to have a redmine issue
>> to add something to the release notes.
>>
>> Tanya
>>
>> On Fri, May 24, 2019 at 3:46 PM David Davis 
>> wrote:
>>
>>> +1 to bmbouter's proposal and not including '[noissue]' items in release
>>> notes.
>>>
>>> David
>>>
>>>
>>> On Fri, May 24, 2019 at 3:52 AM Matthias Dellweg 
>>> wrote:
>>>
 I am fine with stating "[noissue] means 'not worth mentioning in
 release notes'".
 This would require the reviewer to decide to tell the contributor: "We
 want that to be part of the release notes. Please open up a ticket."
 And that process scales better than handpicking the notes in the end.

 On Thu, 23 May 2019 16:22:36 -0400
 Dana Walker  wrote:

 > My initial thought is this looks useful to the user and very clean.
 > I've also found it to be a burden trying to write good release notes,
 > having to dig through commits and try to decide what's important
 > enough and what's not, so +1 to trying to improve this process for
 > both the releaser and user.
 >
 > However:
 > "towncrier works best in a development system where all merges involve
 > closing a ticket."
 > We frequently make use of "[noissue]" in our PRs, in part to lower the
 > burden on contributors making small fixes.  Would we want to move to a
 > model where we *must* have an issue?  Are we instead assuming those
 > items are small enough that the user doesn't need to see it in the
 > release notes?
 >
 > Thoughts?
 >
 > --Dana
 >
 > Dana Walker
 >
 > She / Her / Hers
 >
 > Software Engineer, Pulp Project
 >
 > Red Hat 
 >
 > dawal...@redhat.com
 > 
 >
 >
 >
 > On Thu, May 23, 2019 at 3:49 PM Brian Bouterse 
 > wrote:
 >
 > > In discussion with some other devs, I've realized that pulpcore and
 > > pulpcore-plugin would benefit from better release notes. Here are
 > > some of the reasons that have come up:
 > >
 > > * The release notes are incomplete. One person tries to go through
 > > and write release notes just before the release happens, and by
 > > that point, the number of changes are too many for this approach to
 > > produce complete and robust notes.
 > > * They are hard to produce. Producing "all the release notes" is a
 > > mentally difficult task.
 > > * We try to substitute with Redmine, but this approach limits us
 > > (a) it's now difficult and time consuming to see what changed, (b)
 > > there is way more detail than you actually want, and they aren't
 > > self-contained (can't be browsed off-line).
 > > * overall all ^ leads to both users and plugin writers feeling
 > > uncertain about what has changed in the last release, week, or even
 > > day.
 > >
 > > So what can we do? Recently I contributed to aiohttp and I found
 > > their release note process light and easy. It produces high-quality
 > > release notes like these:
 > > https://aiohttp.readthedocs.io/en/stable/changes.html
 > >
 > > You can read about their process here:
 > >
 https://aiohttp.readthedocs.io/en/stable/contributing.html#changelog-update
 > > You can see some examples of these release note files in their repo
 > > here: https://github.com/aio-libs/aiohttp/tree/master/CHANGES
 > > Overall it makes use of the towncrier project
 > > https://github.com/hawkowl/towncrier
 > >
 > > What do you all think about trying something like this for pulpcore
 > > and pulpcore-plugin? Please write back on-list with thoughts,
 > > ideas, concerns, alternatives, etc.
 > >
 > > Also, I made us a starter issue to coalesce some more of the
 > > practical aspect of adopting a change like this:
 > > https://pulp.plan.io/issues/4875
 > >
 > > All the best,
 > > Brian
 > >
 > >
 > >
 > > ___
 > > Pulp-dev mailing list
 > > Pulp-dev@redhat.com
 > > https://www.redhat.com/mailman/listinfo/pulp-dev
 > >
 ___