| 1 |
Hi Aaron, |
| 2 |
|
| 3 |
Thanks for your suggestion. |
| 4 |
|
| 5 |
On Tue, Jun 30, 2020 at 1:16 AM Aaron Bauman <bman@g.o> wrote: |
| 6 |
> Hi, Max. A couple thoughts... Just let me know if they are too crazy. |
| 7 |
> |
| 8 |
> 1. Could you enable the backend to ping devs/projects via email when a new release is available for their respective package(s)? Maybe make it optional for the dev/project to enroll? |
| 9 |
> |
| 10 |
|
| 11 |
I could imagine packages.g.o to provide different feeds (e.g. about |
| 12 |
new releases of package(s) on a per maintainer/project basis). |
| 13 |
Following this idea: |
| 14 |
|
| 15 |
1. Everyone might directly subscribe to the packages.g.o feeds he is |
| 16 |
interested in, to get notified |
| 17 |
|
| 18 |
2. We might additionally create a sidecar application which consumes |
| 19 |
the feeds and notifies developers/projects. This might be configurable |
| 20 |
so that developers and projects can choose the warnings they would |
| 21 |
like to receive. |
| 22 |
|
| 23 |
> 2. What about a setting to allow the Python team to deprecate a particular interpreter then notify respective pkg owners that their ebuild needs updated? |
| 24 |
> |
| 25 |
> This would possibly workaround the issues mgorny brought up regarding package.deprecated and noise for CI checks. Also, not sure if this is best implemented somewhere else first (e.g. pkgcheck) then leveraged by your work. |
| 26 |
> |
| 27 |
|
| 28 |
Same goes for your second idea. The sidecar application might also |
| 29 |
handle notifications like that in this scenario. |
| 30 |
|
| 31 |
By splitting this into two applications, packages.g.o would continue |
| 32 |
to focus on providing the package data while we might get a second |
| 33 |
application which handles all of the notifications. |
| 34 |
|
| 35 |
What do you think? |
| 36 |
|
| 37 |
-M |
Archives