Niels Thykier writes ("Re: RFR: email about regressions [was: Dealing with
ci.d.n for package regressions]"):
> Britney generates a machine-readable format that should be useful for
> solving this issue. The data file is updated hourly and available from:
> https://release
Ian Jackson:
> AFAICT we had consensus that by default both the delayer and the
> delayee should get mails about test failures. But I don't think that
> is implemented yet.
>
> I recently found out rather late that a test had failed which was
> important to me. I want to set up a thing to email
AFAICT we had consensus that by default both the delayer and the
delayee should get mails about test failures. But I don't think that
is implemented yet.
I recently found out rather late that a test had failed which was
important to me. I want to set up a thing to email me. I think I can
do thi
> In my perception, the biggest reason is a social one. The is resistance
> to the fact that issues with autopkgtests out of one's control can block
> one's package (this is quite different than in Ubuntu).
Can you elaborate on how this is different than in Ubuntu? It sounds
pretty similar to me
Hi
On 25-05-18 12:34, Sebastiaan Couwenberg wrote:
> DDPO, tracker.d.o, and the testing excuses already show the autopkgtest
> information I'm interested in.
>
> Unlike some maintainers I track the state of my packages daily and closely.
I said it before, and I am saying it again: not yet for th
Emilio Pozuelo Monfort writes ("Re: RFR: email about regressions [was: Dealing
with ci.d.n for package regressions]"):
> On 25/05/18 12:24, Mattia Rizzolo wrote:
> > But rather than false positive I should have said "things a maintainer
> > can usually do ~nothing
On 25/05/18 12:24, Mattia Rizzolo wrote:
> On Fri, May 25, 2018 at 12:16:20PM +0200, Emilio Pozuelo Monfort wrote:
>> On 25/05/18 12:09, Mattia Rizzolo wrote:
>>> autoremoval mails contains tons of false positive and cases where
>>> regular package maintainers can do nothing about but watch.
>>
>>
On 05/25/2018 12:09 PM, Mattia Rizzolo wrote:
> On Thu, May 24, 2018 at 09:02:04PM +0200, Sebastiaan Couwenberg wrote:
>> On 05/24/2018 08:53 PM, Raphael Hertzog wrote:
>>> On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
None of the other QA tools mail the maintainer without them asking for
On Fri, May 25, 2018 at 12:16:20PM +0200, Emilio Pozuelo Monfort wrote:
> On 25/05/18 12:09, Mattia Rizzolo wrote:
> > autoremoval mails contains tons of false positive and cases where
> > regular package maintainers can do nothing about but watch.
>
> Can you give some examples of false positives
On 25/05/18 12:09, Mattia Rizzolo wrote:
> autoremoval mails contains tons of false positive and cases where
> regular package maintainers can do nothing about but watch.
Can you give some examples of false positives in autoremoval mails?
Do you mean the case where you just fixed your package but
On Thu, May 24, 2018 at 09:02:04PM +0200, Sebastiaan Couwenberg wrote:
> On 05/24/2018 08:53 PM, Raphael Hertzog wrote:
> > On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
> >> None of the other QA tools mail the maintainer without them asking for
> >> it, autopkgtest shouldn't either.
> >
> > W
On 05/24/2018 08:53 PM, Raphael Hertzog wrote:
> On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
>> None of the other QA tools mail the maintainer without them asking for
>> it, autopkgtest shouldn't either.
>
> With the exception of piuparts, none of them affect testing migration.
What makes a
On Thu, 24 May 2018, Sebastiaan Couwenberg wrote:
> None of the other QA tools mail the maintainer without them asking for
> it, autopkgtest shouldn't either.
With the exception of piuparts, none of them affect testing migration.
Conversely, the autoremoval mails and the testing migration mails a
On 05/24/2018 08:28 PM, Raphael Hertzog wrote:
> Hi Paul,
>
> On Wed, 23 May 2018, Paul Gevers wrote:
>> I have had a complaint about my e-mail, boiling down to it should be
>> opt-in. I am not fully convinced (as I fear too many package maintainers
>> will miss the fact their autopkgtest delays a
Hi Paul,
On Wed, 23 May 2018, Paul Gevers wrote:
> I have had a complaint about my e-mail, boiling down to it should be
> opt-in. I am not fully convinced (as I fear too many package maintainers
> will miss the fact their autopkgtest delays another package, but I want
> to start sending the e-mail
Hello,
On Wed, May 23 2018, Paul Gevers wrote:
> I have had a complaint about my e-mail, boiling down to it should be
> opt-in. I am not fully convinced (as I fear too many package
> maintainers will miss the fact their autopkgtest delays another
> package, but I want to start sending the e-mails
Hi all,
On 06-05-18 20:55, Paul Gevers wrote:
> On 06-05-18 07:27, Paul Gevers wrote:
>>> But, anyway, thanks for your effort, but it obviously doesn't scale to
>>> have the central infrastructure team triage things. How easy would it
>>> be to have the CI automatically send an email to the maint
Hi Ian & Paul,
> > In the e-mail I also provide a boiler plate for forwarding the e-mail to
> > the BTS. You could also have meant that you wanted headers there. I
> > guess that is not what you meant.
(Indeed)
> > X-Debian-CI-Triggers: $trigger
> > X-Debian-CI-Broken: $broken
>
> So, yes, some
Hi Ian, all,
On 08-05-18 14:31, Ian Jackson wrote:
> Paul Gevers writes ("RFR: email about regressions [was: Dealing with ci.d.n
> for package regressions]"):
>> maintainers of the involved packages as one party has insight in what
>> changed and the other party ins
Paul Gevers writes ("Re: RFR: email about regressions [was: Dealing with ci.d.n
for package regressions]"):
> I was wondering if you want headers to the e-mail I will send out. I
> guess this is what you want, so, can you do a proposal (I have never
> really worked with tho
Paul Gevers writes ("RFR: email about regressions [was: Dealing with ci.d.n for
package regressions]"):
> Please find a proposed text for such an e-mail below. Comments or
> improvements very welcome.
Thanks. This looks broadly good but I wonder whether it would be
worth making
Hi Chris,
On 08-05-18 08:04, Chris Lamb wrote:
>>> Beyond that, I'd love to see some parsable X-Foo: headers. I
>>> find these very helpful in the BTS's mails to reliably file things
>>> in my email setup.
>>
>> Can you elaborate, do you mean in the boilerplate or in my e-mail?
>
> Not sure what
Hi Paul,
> > Beyond that, I'd love to see some parsable X-Foo: headers. I
> > find these very helpful in the BTS's mails to reliably file things
> > in my email setup.
>
> Can you elaborate, do you mean in the boilerplate or in my e-mail?
Not sure what you mean by "in my e-mail". As I understand
Hi Chris,
Thanks for the review.
On 07-05-18 00:31, Chris Lamb wrote:
> Beyond that, I'd love to see some parsable X-Foo: headers. I
> find these very helpful in the BTS's mails to reliably file things
> in my email setup.
Can you elaborate, do you mean in the boilerplate or in my e-mail?
X-Deb
Hi Paul,
> Please find a proposed text for such an e-mail below. Comments or
> improvements very welcome.
Just some brief and somewhat-pedantic suggestions for improvements
below. Beyond that, I'd love to see some parsable X-Foo: headers. I
find these very helpful in the BTS's mails to reliably f
Hi all,
On 06-05-18 07:27, Paul Gevers wrote:
>> But, anyway, thanks for your effort, but it obviously doesn't scale to
>> have the central infrastructure team triage things. How easy would it
>> be to have the CI automatically send an email to the maintainers of
>> the rdependency and the depend
Hi Ian,
On 04-05-18 13:08, Ian Jackson wrote:
> Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
>> I hadn't realissed that _test_ dependencies would trigger retests, as
>> well as actual package dependencies.
>
> Having read Mattia
Hi Ian,
On 04-05-18 12:50, Ian Jackson wrote:
> Doing as you suggest for a real test feels wrong, since it involves
> denormalising (in the relational database sense) the dependency graph.
>
> But I guess I could introduce a test which does nothing, but which has
> as direct dependencies the indi
Hi Chris,
On 04-05-18 01:35, Chris Lamb wrote:
>>> ie. 75 out of "top" 100 packages according to popcon are missing
>>> autopkgtests.
>>
>> Yes, go provide patches to add them ;) But let's make them smart.
>
> Well, you're pushing at an open door with me with the "patches
> welcome" call to arms
Hi Ian,
Can we carry this discussion over to debian...@lists.debian.org (added
in CC now)?
On 04-05-18 15:24, Ian Jackson wrote:
> James Clarke writes ("Re: Dealing with ci.d.n for package regressions"):
>> On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
>
Chris Lamb wrote:
> I can hack together quick things like:
I just noticed that UDD has lintian results, so you can just write
this as:
(Spoilers: I'm not a SQL programmer)
SELECT source, CASE (SELECT COUNT(*) FROM lintian
WHERE package = source AND package_type = 'source' AND
tag = 'te
Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
> unstable-to-testing migration.
I observe that the tests done for this are done without building the
source, where this is a feature advert
James Clarke writes ("Re: Dealing with ci.d.n for package regressions"):
> On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
> > Is that documented somewhere ? I can't find it here
> > https://manpages.debian.org/stretch/dpkg-dev/dpk
On Fri, 2018-05-04 at 12:08:31 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
> > I hadn't realissed that _test_ dependencies would trigger retests, as
> > well as actual package dependencies.
>
> Having r
On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
> Mattia Rizzolo writes ("Re: Dealing with ci.d.n for package regressions"):
> > On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote:
> > > Just add it as a test dependency in one of your tests?
>
Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
> I hadn't realissed that _test_ dependencies would trigger retests, as
> well as actual package dependencies.
Having read Mattia's message, and looking at the Testsuite-Triggers
line which is autoge
Mattia Rizzolo writes ("Re: Dealing with ci.d.n for package regressions"):
> On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote:
> > Just add it as a test dependency in one of your tests?
>
> Just to share a bit that doesn't seem to be of public know
Paul Gevers writes ("Re: Dealing with ci.d.n for package regressions"):
> On 03-05-18 14:12, Ian Jackson wrote:
> > 3. "Required age increased by 10 days because of autopkgtest"
> > seems to appear when either (i) when there are tests that should be
> >
Hi Paul,
> > ie. 75 out of "top" 100 packages according to popcon are missing
> > autopkgtests.
>
> Yes, go provide patches to add them ;) But let's make them smart.
Well, you're pushing at an open door with me with the "patches
welcome" call to arms :)
But is there not value to even the smalle
Hi Chris,
On 03-05-18 20:13, Chris Lamb wrote:
> Secondly, I was just wondering if you are collecting statistics
> over what percentage of packages have autopkgtests, or, perhaps
> more usefully which special/important packages have such tests?
https://ci.debian.net/status/ has a bit. Regarding i
On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote:
> > 4. Can we have a way to trigger tests from updates of non-direct
> > rdepends ? At some point in the future maybe we will run tests of
> > whole batches of updates and then have some algorithm to chop out
> > what the failures are ca
Hi Ian,
On 03-05-18 14:12, Ian Jackson wrote:
>
Skipped two point that Niels already covered.
> 3. "Required age increased by 10 days because of autopkgtest"
> seems to appear when either (i) when there are tests that should be
> run but which haven't completed and (ii) when some tests newly fai
Hi Paul,
> And finally, thanks to all the people that helped and contributed to
> make this possible, 5 years after the initial announcement⁷.
First, thank you for pushing this!
Secondly, I was just wondering if you are collecting statistics
over what percentage of packages have autopkgtests, or
Ian Jackson:
> Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
>> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
>> unstable-to-testing migration.
>
> This is great.
>
> I have some suggestions/observatio
Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
> unstable-to-testing migration.
This is great.
I have some suggestions/observations, looking particularly at
https://release.de
Hi all,
As I just announced on d-d-a¹, we have enabled autopkgtest usage for
unstable-to-testing migration.
There are a few tricks that I like to share here and now about how to
manipulate ci.d.n in case things needs some attention.
1) the excuses presented at the excuses.html² and e.g. on track
46 matches
Mail list logo
