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 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 > <https://calendly.com/timlinux> 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
