[Pulp-dev] Release Note Process Improvements

[Matthias Dellweg]

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
> >  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190524/d573caab/attachment.sig>