Dmitry Bogatov wrote:
> I am fine with maintaining custom profile, but it raises question of
> discoveribility: should many different developers maintain separate
> repositories of custom, not universally-accepted checks, we will get
> work duplication and fragmentation.
Whether the tag is
[2019-05-23 07:09] "Chris Lamb"
> Mattia Rizzolo wrote:
>
> > > (Personally, I doubt someone would fork Lintian, more likely its
> > > output would become less and less "trusted". But both outcomes suck.)
> >
> > Rather, people who until at some point diligently read the whole
> > lintian
Mattia Rizzolo wrote:
> > (Personally, I doubt someone would fork Lintian, more likely its
> > output would become less and less "trusted". But both outcomes suck.)
>
> Rather, people who until at some point diligently read the whole
> lintian output for every single upload they do, may just
Chris Lamb:
> Dmitry Bogatov wrote:
>
>>> [..] I just think that lintian should be less pro-active at adding
>>> checks for things that are far from accepted.
>>
>> That is why I propose introducing concept of "controversial" checks.
>
> I think we are all violently agreeing here.
>
>> Having
On Wed, 22 May 2019, 11:30 pm Chris Lamb, wrote:
> (Personally, I doubt someone would fork Lintian, more likely its
> output would become less and less "trusted". But both outcomes suck.)
>
Rather, people who until at some point diligently read the whole lintian
output for every single upload
Dmitry Bogatov wrote:
> > [..] I just think that lintian should be less pro-active at adding
> > checks for things that are far from accepted.
>
> That is why I propose introducing concept of "controversial" checks.
I think we are all violently agreeing here.
> Having Lintian plainly reject
[2019-05-20 15:45] Mattia Rizzolo
> On Fri, May 17, 2019 at 08:58:03AM +0100, Chris Lamb wrote:
> [...]
> > (This kind of conversation always makes me wonder if we need another
> > level of "extra pendatic" that people need to opt into... *g*)
>
> Nah. I just think that lintian should be less
On Fri, May 17, 2019 at 08:58:03AM +0100, Chris Lamb wrote:
> Wwat would you say this only triggered if the package had a testsuite
> or autopkgtests?
As Dmitry mentioned in a later mail, that would be wrong.
> > I don't think test-building the whole package every commit is useful
>
> Can you
[2019-05-17 08:58] "Chris Lamb"
> tags 928809 + moreinfo
> thanks
>
> Mattia Rizzolo wrote:
>
> > it wouldn't even make sense since they lack a testsuite
>
> Wwat would you say this only triggered if the package had a testsuite
> or autopkgtests?
Not enough for me. I want piuparts checks and
tags 928809 + moreinfo
thanks
Mattia Rizzolo wrote:
> it wouldn't even make sense since they lack a testsuite
Wwat would you say this only triggered if the package had a testsuite
or autopkgtests?
> I don't think test-building the whole package every commit is useful
Can you elaborate why? I
On Sun, May 12, 2019 at 02:27:51PM -0400, Chris Lamb wrote:
> Mattia, just to gauge your opinion, what would you hypothethically say
> to a "P:" check for this and, separately, the current "I:" autopkgtest
> check?
I only say that, out of 24 packages listed in my ddpo, 4 already have
gitlab-ci
Mattia Rizzolo wrote:
> > please add suggestion that if Vcs-Git points to salsa.debian.org,
> > CI should be used.
>
> Please, don't.
I'm somewhat inclined to agree with Mattia here but perhaps not as
strongly - I'm a huge fan of CI systems to catch things. I'm not very
happy with
Hi,
On Sat, May 11, 2019 at 02:49:02PM +, Dmitry Bogatov wrote:
> please add suggestion that if Vcs-Git points to salsa.debian.org,
> CI should be used.
Please, don't.
For most of my packages, I don't want to bother with setting up a CI,
neither I see any use for it, and I don't think
Package: lintian
Version: 2.13.0
Severity: wishlist
Dear Maintainer,
please add suggestion that if Vcs-Git points to salsa.debian.org,
CI should be used.
While CI config can be located anywhere (ci_config_path property of
project), both Debian Wiki and salsa(1) manpage mention
14 matches
Mail list logo
