Hi Tim
On 6/23/19 8:37 PM, Tim Sutton wrote:
Hi Matthias
On 21 Jun 2019, at 11:47, Matthias Kuhn <[email protected]
<mailto:[email protected]>> wrote:
Hi
On 6/21/19 9:03 AM, Tim Sutton wrote:
Hi
On 21 Jun 2019, at 08:50, Matthias Kuhn <[email protected]
<mailto:[email protected]>> wrote:
Yes, I think it would make a lot of sense to integrate the
changelog creation directly with labels into pull requests.
Since projecta is also based on markdown this should all play
nicely together. And we could even add an (optional) #Changelog
section to the pull requests and some other tags to automatically
set funder etc. so one could already write the whole changelog
entry during the development cycle. That should easily pay back
with all the volunteer time that is saved during the already busy
run up time to release!
Resource wise, most the allocated time in the grant proposal is for
getting the service up and running and integrating with all the
notification hooks. Parsing the content and sending it to another
API should be pretty much straightforward. The main question would
rather be if creation of new versions can also be automated and how
to decide to which version a new feature should be sent (i.e. find
out the "current" version). The best match for this would probably
be to use github milestones. In the end I would say that this
should increase the offer by 20%.
Tim, is everything ready on your end for that?
So yes we would be happy to pitch in to help here. Admire can help
more immediately by getting this changelog ready and we can work
with Anita (Hapsari) to get things in place to support PR githook
thing-a-me-doodahs. (See my reply to OP)
Great! I started with the changelog, but it's not even close to
finished, so whatever Admire gets too on Monday will be appreciated.
And of course whatever others get to meanwhile!
Concerning the changelog, I think there are too possibilities:
* Integrate it into the service we are going to set up if the grant
proposal is accepted. This will already have some logic builtin to
cover things like also reacting to labels added after the PR is
merged etc.
* Bypass the grant proposal service and directly hook into the
github webhooks, which I think is what you propose.
Can you share the link again to your proposal?
Sure,
After some fiddling I finally found the link to the proposals again.
https://docs.google.com/document/d/1VzgLJ-hy2GtcWrAy5geivhDDdXRGJUDcikCWUtXRe9k/edit#heading=h.cuzf1c5o2ciq
Basically the idea is to do pretty much the same thing as the GitHub
Backporting App (https://github.com/tibdex/backport#goal). The app will
listen to label changes and state (open/close) changes and open issues
on the docs repo accordingly, but could very well also call other REST
APIs upon such events. The result should be a fairly generic and open
source Github App, that can be installed on any repo and configured via
a yaml file inside the repo.
Best regards
Matthias
Yes I was leaning towards a generic approach if possible, but let me
read your proposal again and see how that fits in…
Regards
Tim
I think the main advantage of the first one would be that it could be
integrated in a single tool and since we would be working on it
already it would be less effort. The second one would add some value
to projecta if it can be used for other projects too.
I'm happy to step back if the second one is preferred.
Regards
Matthias
Regards
Tim
—
*Tim Sutton*
*Co-founder:*Kartoza
*Ex Project chair:*QGIS.org <http://QGIS.org>
Visit http://kartoza.com <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 <http://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
