[Pulp-dev] Release Note Process Improvements

[Tatiana Tereshchenko]

+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 <daviddavis at redhat.com> 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 <dellweg at atix.de> 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 <dawalker at redhat.com> 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 <https://www.redhat.com>
>> >
>> > dawalker at redhat.com
>> > <https://www.redhat.com>
>> >
>> >
>> >
>> > On Thu, May 23, 2019 at 3:49 PM Brian Bouterse <bbouters at 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
>> > > 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 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/20190525/e60a28a1/attachment.htm>