First of all sorry for the late late reply, I was hoping to find time to
reply to this sooner :-/
On 19/08/08 09:46, Paul Gevers wrote:
> 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 ?
It might help, but I'm not certain. The bug may or may not be in the library on
in the leaf packages. Filing bugs may start a ping pong of "it's your fault"
bugs between maintainers.
My personal point of view (and because of this it might be biased) is that the
maintainers of the packages that ship autopkgtest should be the reponsibles for
any breackage it might occur on them because:
- They added autopkgtests, so they are showing an intent on reviewing them when
they fail.
- They will certainly know their packages better than the library maintainer,
and thus they have more chances to get the root of the issue sooner. Of course
that might mean finding a bug in the library, but that's just ok.
Note that the principle I'm basing myself is "we can't force a maintainer to do
stuff". So whoever adds autopkgtests to their packages must be the one who
starts the debugging when something fails, not the other side.
Pretty please don't get me wrong: in an ideal world everyone should start
digging the issue. But Debian being volunteer-based simply can't get to that
point, except by forcing maintainers to do even more stuff.
> > 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.
**Yes please**. This will certainly help *a lot* specially for us that we
prepare new releases on experimental.
> 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.
Perhaps derailing the thread a little, but other "pretty nice stuff to have" as
a Debian service would be something that allows rebuilds of rdeps of stuff in
experimental. It can be on just one powerful arch (amd64 possibly?). In this way
we libs maintainers would not need to use or personal resources in rebuilding
stuff. Says someone from Argentina who has a 10+years old machine as main
machine and a quite devaluated (and devaluating) currency. I think Ubuntu has
something along this idea.
But yes, once again I can't nor will force anyone into doing it :-)
Cheers, Lisandro.
