Hi,
On 07-08-2019 16:57, Ian Jackson wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"):
>> No, what I have been perceiving (and pretty please note that this is my
>> personal "feeling") is that maintainers, specially library maintainers, have
>> even more and more "stuff to care for".
>
> I can see why you feel that way.
>
> I think maybe we need to make it easier for the maintainer of a
> widely-used library to push some of this out to depending packages.
<RT hat off>I agree with this.</RT hat off>
> (And I speak as a maintainer of a leaf package with a thorough
> autopkgtest suite which often blocks the migration of my
> dependencies.)
>
> Lisandro, would it meet your needs if you had free licence to file RC
> bugs against all packages which were blocking your migration, before
> you had done the investigation yourself ?
>
> I think the effect would be that a maintainer of a dependent package
> would have to engage with the situation and if they did nothing for
> long enough, the autoremoval would kick in. Then your library would
> be able to migrate.
Obviously this only works if the reverse dependency isn't also a key
package. So, in any case, please contact the release team early if you
experience problems, we can help.
> This seems similar to the approach we take with (say) new compilers,
> which trigger FTBFS bugs in depending packages. The compiler
> maintainers do not investigate the issues - they file bugs, which
> eventually become RC, and then the depending packages must either be
> fixed our autoremoved.
I think we should also try to improve the visibility towards reverse
dependencies that their autopkgtest is blocking other packages. I would
love tracker (and the old pts) to show this on their page. (Working on
such a patch is on my TODO list, except not at the top).
> (Of course some library maintainers would prefer to do some
> investigation first.)
I can already trigger all the autopkgtests in unstable for packages that
are in experimental, so if you interested in this, please contact me.
This would enable library maintainers to at least have an overview of
what would happen. I could even activate this by default.
We also have an Outreachy intern working on a self-service corner on
ci.d.n, so that more testing can be done if people want it.
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature