Re: Changelog for 3.8! ARgh!

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Matthias Kuhn 🌍
Hi Nyall,

Ouch, that's a real pity. Releasing the version without a changelog is a
communication-GAU we should try to avoid.

As a first step I have just added the new version to projecta
http://changelog.qgis.org/en/qgis/version/3.8/

I'll try to fill it up at least with some basics, but I won't be able to
do it all on my own, so anyone else with a bit of spare time please jump
in and fill the gaps!

If we ship the next release towards mid next week we should be able to
put together something if everyone spends some time.


Now that this is sorted out:

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?

Best regards

Matthias


On 6/21/19 2:52 AM, Nyall Dawson wrote:

> Hey all,
>
> It just struck me that we're finalizing 3.8 in < 24 hours, and our
> visual changelog is.... completely non-existent. As in, we have NO
> entries, and not even a version number created yet.
>
> This is far from ideal, since the visual changelog is basically the
> only way we have of informing users of all the lovely new toys we've
> spent the last 4 months slaving away at making. If users don't even
> know these exist, there's basically no point in writing them :(
>
> In the past I've spent considerable time in the lead up to a release
> trawling through the git logs and adding dummy entries for all new
> features/stuff to highlight, which a handful of others have then spent
> HOURS fleshing out into pretty/nicely readable entries. Unfortunately
> I have no spare time to do that this round.
>
> Suffice to say, I think it's clear that this process was never great,
> and has totally broken down this time.
>
> It seems to me like Matthias' grant proposal covering documentation
> Pull Requests would tie in very nicely here. If that proposal is
> successful, and he can get the contents of feature pull requests
> pushed to documentation PRs, then it's a natural step to extend this
> and also push the same feature PR descriptions automatically to the
> changelog.
>
> So I have some questions:
> 1. Matthias: Do you think this would be a possible extension of your
> proposal? How much extra would you need to cover it?
> 2. Tim: Does the changelog API already exist which would make this
> possible? OR if not, would it be tricky/costly to develop?
> 3. How can we make this a reality? Who needs payment, and who can make
> this payment happen?
>
> -- OR --
>
> 4. Who is going to take this on for future releases and ensure we have
> a changelog ready to go at launch time?
>
> and finally, the most pertinent question right now:
>
> 5. Who the heck can get a changelog in place for 3.8.0? Who has 2-3
> days spare they want to volunteer into getting this in place?
>
> Nyall
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Tim Sutton-6
Hi


On 21 Jun 2019, at 08:50, Matthias Kuhn <[hidden email]> wrote:

Hi Nyall,

Ouch, that's a real pity. Releasing the version without a changelog is a communication-GAU we should try to avoid.

As a first step I have just added the new version to projecta http://changelog.qgis.org/en/qgis/version/3.8/

I'll try to fill it up at least with some basics, but I won't be able to do it all on my own, so anyone else with a bit of spare time please jump in and fill the gaps!

If we ship the next release towards mid next week we should be able to put together something if everyone spends some time.


Now that this is sorted out:

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)

Regards

Tim



Best regards

Matthias


On 6/21/19 2:52 AM, Nyall Dawson wrote:
Hey all,

It just struck me that we're finalizing 3.8 in < 24 hours, and our
visual changelog is.... completely non-existent. As in, we have NO
entries, and not even a version number created yet.

This is far from ideal, since the visual changelog is basically the
only way we have of informing users of all the lovely new toys we've
spent the last 4 months slaving away at making. If users don't even
know these exist, there's basically no point in writing them :(

In the past I've spent considerable time in the lead up to a release
trawling through the git logs and adding dummy entries for all new
features/stuff to highlight, which a handful of others have then spent
HOURS fleshing out into pretty/nicely readable entries. Unfortunately
I have no spare time to do that this round.

Suffice to say, I think it's clear that this process was never great,
and has totally broken down this time.

It seems to me like Matthias' grant proposal covering documentation
Pull Requests would tie in very nicely here. If that proposal is
successful, and he can get the contents of feature pull requests
pushed to documentation PRs, then it's a natural step to extend this
and also push the same feature PR descriptions automatically to the
changelog.

So I have some questions:
1. Matthias: Do you think this would be a possible extension of your
proposal? How much extra would you need to cover it?
2. Tim: Does the changelog API already exist which would make this
possible? OR if not, would it be tricky/costly to develop?
3. How can we make this a reality? Who needs payment, and who can make
this payment happen?

-- OR --

4. Who is going to take this on for future releases and ensure we have
a changelog ready to go at launch time?

and finally, the most pertinent question right now:

5. Who the heck can get a changelog in place for 3.8.0? Who has 2-3
days spare they want to volunteer into getting this in place?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer









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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Matthias Kuhn 🌍

Hi

On 6/21/19 9:03 AM, Tim Sutton wrote:
Hi

On 21 Jun 2019, at 08:50, Matthias Kuhn <[hidden email]> 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.

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



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Totò
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Tim Sutton-6
In reply to this post by Matthias Kuhn 🌍
Hi Matthias

On 21 Jun 2019, at 11:47, Matthias Kuhn <[hidden email]> wrote:

Hi

On 6/21/19 9:03 AM, Tim Sutton wrote:
Hi

On 21 Jun 2019, at 08:50, Matthias Kuhn <[hidden email]> 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?

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

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Tim Sutton-6
In reply to this post by Totò
Thanks Toto

Its great that you want to help but a few screenshots without documentation will make the work more rather than less I fear. If you want to contribute, create an account on the changelog site and pop me a note and I will give you the needed permissions.

Also it will be better to have screenshots in English I think as the changelog gets pulled over to the documentation project where translations happen.

Thanks!

Regards

Tim

On 23 Jun 2019, at 14:38, Totò <[hidden email]> wrote:

Hi everyone,
I made some screenshots to use in changelog [0]

[0] http://changelog.qgis.org/en/qgis/version/3.8/

https://mega.nz/#!xNYnDabK!0mnvs5HlKj_2y_vfklCoixMfxDoIMweoDWxeIuotVHk

thx



-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer









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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Changelog for 3.8! ARgh!

Matthias Kuhn 🌍
In reply to this post by Tim Sutton-6

Hi Tim

On 6/23/19 8:37 PM, Tim Sutton wrote:
Hi Matthias

On 21 Jun 2019, at 11:47, Matthias Kuhn <[hidden email]> wrote:

Hi

On 6/21/19 9:03 AM, Tim Sutton wrote:
Hi

On 21 Jun 2019, at 08:50, Matthias Kuhn <[hidden email]> 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

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer