Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: libshell-utils-clojure
Version : 1.0.2
Upstream Author : Puppet Labs Inc
* URL : https://github.com/puppetlabs/clj-shell-utils
* License : Apache-2.0
Programming Lang: Clojure
Descripti
On 04.09.20 03:39, Paul Wise wrote:
> On Thu, 2020-09-03 at 15:18 -0400, Mark Pearson wrote:
>
>> For DSA - I'm assuming all role addresses have members behind it with
>> debian addresses? "Please don't register on the portal with role
>> addresses" would seem a sensible guideline to me.
>
> I
> Why do we need to make this 100% accurate in the first place? Everyone
> who got access to a debian.org email address has been an OSS contributor
> of sorts. Which leaves those who opted out of the email address entirely
> (rather than not using it) - but they are free to reactivate it. It
> feel
On 04.09.20 11:23, Philip Rinn wrote:
>> Why do we need to make this 100% accurate in the first place? Everyone
>> who got access to a debian.org email address has been an OSS contributor
>> of sorts. Which leaves those who opted out of the email address entirely
>> (rather than not using it) - but
On 2020/09/04 11:23, Philip Rinn wrote:
>> Why do we need to make this 100% accurate in the first place? Everyone
>> who got access to a debian.org email address has been an OSS contributor
>> of sorts. Which leaves those who opted out of the email address entirely
>> (rather than not using it) - b
Raphael Hertzog wrote on 29/08/2020:
@@ -200,7 +204,7 @@ developers and the package maintainers are not the same set
of persons.
When upstream is Debian (or one of its derivative), the upstream vendor
should not use the usual `/` prefix (but all others vendors should
-do so). The main d
Package: wnpp
Severity: wishlist
Owner: Jai Flack
* Package name: golang-github-rakyll-magicmime
Version : 0.1.0-1
Upstream Author : Jaana Dogan
* URL : https://github.com/rakyll/magicmime
* License : Apache-2.0
Programming Lang: Go
Description : Go bi
Hi,
On Fri, 04 Sep 2020, Paride Legovini wrote:
> As the name of the development branch is not specified anymore, should dep14
> ask for it to be the repository default branch? Otherwise there's no safe
I took this as granted. But maybe we should make it explicit, yes. I also
clarified that those
Raphael Hertzog wrote on 04/09/2020:
Hi,
On Fri, 04 Sep 2020, Paride Legovini wrote:
As the name of the development branch is not specified anymore, should dep14
ask for it to be the repository default branch? Otherwise there's no safe
I took this as granted. But maybe we should make it expli
On 2020-09-04 at 11:42, Raphael Hertzog wrote:
> So here's my counter proposal:
>
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -201,12 +201,16 @@ Native packages
>
> The above conventions mainly cater to the case where the upstream
> developers and the package maintainers are
Hi All,
If the test done in the autopkgtest does not provide significant test
coverage then it should be marked with "Restrictions: superficial".
Ref: https://people.debian.org/~eriberto/README.package-tests.html
Examples of tests which are not significant includes (its not a complete list):
1)
On Fri, Sep 4, 2020 at 6:53 PM Sudip Mukherjee wrote:
> If the test done in the autopkgtest does not provide significant test
> coverage then it should be marked with "Restrictions: superficial".
...
> I am still trying to figure out a generalized method to find them but
> an initial script has fo
12 matches
Mail list logo
