| 1 |
On Fri, 10 Apr 2020 12:31:19 +0100 |
| 2 |
Samuel Bernardo <samuelbernardo.mail@×××××.com> wrote: |
| 3 |
|
| 4 |
> - if there is more then X new versions in upstream, get from a release |
| 5 |
> feed associated with ebuild (X value defined by project leader with |
| 6 |
> threshold set by CI) |
| 7 |
|
| 8 |
This is probably the biggest difficult part really. |
| 9 |
|
| 10 |
There's lots of different services that provide this, but none of them |
| 11 |
are great for us, really. |
| 12 |
|
| 13 |
The majority of the ones I've looked at have a very hard time as soon |
| 14 |
as perl versions turn up. |
| 15 |
|
| 16 |
Even our own project, euscan, had serious problems with this. |
| 17 |
|
| 18 |
And evaluating this data in a notifiable way can be very expensive |
| 19 |
depending on how you do it, when contacting a service. |
| 20 |
|
| 21 |
( Most services I've seen don't have a 'bulk' query interface, so you |
| 22 |
need a query-per-package... , and trying to get the service to work out |
| 23 |
'what gentoo has' to work it out is even trickier ) |
| 24 |
|
| 25 |
I've been abusing release-monitoring for perl stuff, it was very time |
| 26 |
consuming to get everything we use tracked there, and I'm the only |
| 27 |
person who really adds new perl entries to it to track, so it only |
| 28 |
covers a fraction of gentoo. |
| 29 |
|
| 30 |
( And again, it has the query-rate limitations, and the "perl versions |
| 31 |
are hard" problems as well ) |
Archives