| 1 |
Hi, |
| 2 |
|
| 3 |
On 2020/06/30 16:19, Max Magorsch wrote: |
| 4 |
|
| 5 |
> Hi Aaron, |
| 6 |
> |
| 7 |
> Thanks for your suggestion. |
| 8 |
> |
| 9 |
> On Tue, Jun 30, 2020 at 1:16 AM Aaron Bauman <bman@g.o> wrote: |
| 10 |
>> Hi, Max. A couple thoughts... Just let me know if they are too crazy. |
| 11 |
>> |
| 12 |
>> 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? |
| 13 |
>> |
| 14 |
> I could imagine packages.g.o to provide different feeds (e.g. about |
| 15 |
> new releases of package(s) on a per maintainer/project basis). |
| 16 |
> Following this idea: |
| 17 |
> |
| 18 |
> 1. Everyone might directly subscribe to the packages.g.o feeds he is |
| 19 |
> interested in, to get notified |
| 20 |
> |
| 21 |
> 2. We might additionally create a sidecar application which consumes |
| 22 |
> the feeds and notifies developers/projects. This might be configurable |
| 23 |
> so that developers and projects can choose the warnings they would |
| 24 |
> like to receive. |
| 25 |
This would be great. |
| 26 |
>> 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? |
| 27 |
>> |
| 28 |
>> 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. |
| 29 |
>> |
| 30 |
> Same goes for your second idea. The sidecar application might also |
| 31 |
> handle notifications like that in this scenario. |
| 32 |
> |
| 33 |
> By splitting this into two applications, packages.g.o would continue |
| 34 |
> to focus on providing the package data while we might get a second |
| 35 |
> application which handles all of the notifications. |
| 36 |
> |
| 37 |
> What do you think? |
| 38 |
|
| 39 |
Anything that'll help avoid the python dependency hell the next time |
| 40 |
round there are python changes. perl used to be the bane of my |
| 41 |
existence but for the last few years that dubious honour has gone to |
| 42 |
python. Not as a developer. As a user. |
| 43 |
|
| 44 |
texlive is the other one that annoys me from time to time but an emerge |
| 45 |
-C $(qlist -IC dev-texlive/*) + remerge generally fixes that. For |
| 46 |
python that's a death sentence. |
| 47 |
|
| 48 |
For that matter, if a CI check gets introduced and one of my packages |
| 49 |
are now affected this would be helpful too to get a notification, eg, |
| 50 |
let's say EAPI=6 now gets deprecated, getting a notification that |
| 51 |
packages x/y for which I'm responsible would be helpful, rather than |
| 52 |
being caugh off guard when next I bump, or worse, if there is no new |
| 53 |
version, EAPI=6 just going away completely before I notice. Bad example |
| 54 |
since EAPI's remain very long past deprecation, but you get the point. |
| 55 |
|
| 56 |
Kind Regards, |
| 57 |
Jaco |
Archives