On Fri, 7 Feb 2020 at 19:49, Denis Rouzaud <[email protected]> wrote: > > Hi all, > > It sounds that going through pull requests rather than the commits make sense. > > For now, I have created a small -- not anymore ;) -- script that will output > corresponding pull requests as JSON with title, HTML body and author. > Working for this series, the script returns all PRs having [FEATURE] in one > of their commit message or in the PR title, within the corresponding dates > and targeting master > script: https://gist.github.com/3nids/0cf399297888ea8ebd0e64169c9fbbc2 > output (changelog): > https://gist.github.com/3nids/4f6e948a94526515391899a5701cce47
Are you sure this is working? There's definitely items missing from this, e..g. https://github.com/qgis/QGIS/pull/33165 Nyall > > That should be easy to feed the changelog with this. > > Probably for the future, it would be interesting to create a Changelog label? > > Best wishes, > > Denis > > > Le jeu. 6 févr. 2020 à 00:25, Tim Sutton <[email protected]> a écrit : >> >> Hi >> >> On 5 Feb 2020, at 17:03, Matthias Kuhn <[email protected]> wrote: >> >> On 2/5/20 11:33 AM, Nyall Dawson wrote: >> >> On Wed, 5 Feb 2020 at 20:29, Tim Sutton <[email protected]> wrote: >> >> Hi >> >> >> >> On 4 Feb 2020, at 23:57, Nyall Dawson <[email protected]> wrote: >> >> >> >> >> Is it enough to just grab the items labelled ‘Feature’ - we are planning to >> automatically create entries from the changelog as part of the QGIS funded >> improvements we are doing >> >> >> In my experience... no. Some of us naughty developers don't always use >> this tag :( >> >> >> Now about we add a ‘Changelog’ tag that we can just go and add to each PR >> (either at the time of making it or retrosopectively) and we can just go >> through the PR queue and scan for those? Other options I guess is to >> strongly encourage people to use a relevant tag when they submit their PR. >> >> Definitely. Like you've pointed out, it could be done retrospectively, >> and added also by others. >> >> >> What are the guidelines for using [feature] in the future? I think it acted >> as a combination of [needs docs], [changelog] and [look, this is cool] in >> the past. If the first two are about to be solved by more precise labels, do >> we keep it for the third one or are there other compelling reasons? >> >> >> For me, I don’t have any strong opinions - I think we will build the >> harvester to take a user-defined list of tags that should be harvested, so >> that we can deal with things flexibly. Basically just looking for advice on >> which tags I should use and then we will set it up to use those. >> >> Thanks, >> >> Tim >> >> >> >> Matthias >> >> >> — >> >> >> >> >> >> >> >> >> Tim Sutton >> >> Co-founder: Kartoza >> Ex Project chair: QGIS.org >> >> Visit http://kartoza.com to find out about open source: >> >> Desktop GIS programming services >> Geospatial web development >> GIS Training >> Consulting Services >> >> Skype: timlinux >> IRC: timlinux on #qgis at freenode.net >> >> I'd love to connect. Here's my calendar link to make finding time easy. >> >> _______________________________________________ >> QGIS-Developer mailing list >> [email protected] >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
