[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: uscan roadmap
From:       Tomas Pospisek <tpo2 () sourcepole ! ch>
Date:       2021-12-01 17:31:06
Message-ID: e32f67f2-4e15-d1ad-9cee-7c00aaacdc11 () sourcepole ! ch
[Download RAW message or body]

On 01.12.21 12:50, Mattia Rizzolo wrote:

> Likewise, I would love if uscan could just learn how github, gitlab,
> launchpad, etc are made so prople won't have to bother with sticking
> urls into watchfiles, such as:
> 
>    Source: GitHub
>    Source-Options:
>     namespace: trendmicro
>     project: tlsh
>     match-on: tags|releases

Excellent idea: +1

However at the very moment that abstractions get introduced (which is 
+1), please, please, please do keep the poor users in mind when stuff 
*does not* work. I.e. please make uscan trivially debuggable.

Something like:

     $ uscan --verbose
     ... found GitHub source definition:
         Source: GitHub
         Source-Options:
           namespace: trendmicro
           project: tlsh
           match-on: tags|releases
     ... using that GitHub source definition to find new release under 
https://github.com/foo/bar/releases/bar-1.2.3.tar (uscan.py:line 3498)

One of the regularly recurring frustrations I am encountering is that 
I'm using some SW that has abstracted something and I know in principle 
how the thing it has abstracted works, but am completely unable to find 
out where the abstraction gets all wired up and falls on its face. (Hi 
k8s!). The famous "computer says no" moment.

OK, this is just me whining and not contributing any code at all, so 
please take it as just that: a wishlist item.
*t

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic