+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 <davidda...@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 <dell...@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 <dawal...@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> >>> > >>> > dawal...@redhat.com >>> > <https://www.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 >>> > > 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 >>> > > >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
