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. Ack. Paul
signature.asc
Description: OpenPGP digital signature
