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
26 matches
Mail list logo
