Web lists-archives.com

Re: Dealing with ci.d.n for package regressions

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 indirect dependencies I want to be retested
> for.  It's a bit of a bodge but if we invented a feature name for this
> test it would even give us an upgrade path:
>   Tests: some-empty-shell-script

^^ Test-Command: /bin/true ;)

>   Depends: indirect-dep-1, indirect-dep-2
>   Features: hint-indirect-dependencies-retest
> And then if we later add a more `proper' way of saying the same thing,
> it can understand this old way of writing it.  Or we can ignore it if
> we have a better way of doing the same thing later.
> What do people think ?

I agree on this.

> 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 dependency ?

I have already created multiple personal scripts to parse excuses.yaml
and store state on regressions, so this is trivial. However, people have
voiced their concerns about auto creation of bugs. I estimate that a
plain email for now is acceptable. I think I'll ask about converting the
email to a bug I guess. I'll create a cronjob that does this soon,
putting myself in CC to follow the discussion as it would actually
reduce my work for now.

> I think we need to get into the habit of the maintainers talking to
> each other about these kind of things, before we start increasing the
> blocking time.  Otherwise we risk developing a culture where the
> dependency's maintainers usually do some kind of workaround, which the
> rdependency's maintainers may find out about much later if at all.



Attachment: signature.asc
Description: OpenPGP digital signature