Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]
> 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, except for being a delay instead of a block. Or
did you mean that the social consequences are different?
(note: i'm only loosely familiar with ubuntu, please correct me if any of this is wrong).
Debian has a strong concept of package maintainership. Each maintainer (or sometimes team) essentially "owns" a package and is supposed to take responsibility for fixing issues in that package. Library maintainers can NMU their rdeps but there are time-consuming procedures surrounding that and of course the library maintainer may not be enough of an expert on the rdep to fix it.
So a big social question for library maintainers becomes "to what extent do issues in reverse dependencies get to block updates to my library?"
And the answer in recent times (particularly since the introduction of "smooth updates" to Britney) been "for the most part they don't". The library migrates to testing and the rdeps remain buggy in testing, if the bug is rc and left unfixed for long enough they will be removed, if the bug is not rc then it may just persist into the release.
Enforcing autopkgtests would radically change that dynamic.
Further Debian has this strange permissions system where any dd can technically upload any package and anyone can technically close any bug but if you want something more unusual doing you have to go through the small handful of people who have permission to do it. I expect a lot of DDs are worried that overriding a broken autopkgtest will fall into the latter category.
My understanding is that Ubuntu has a rather different social structure. Universe is an explicit second class citizen (does the ubuntu autopkgtest implementation allow universe packages to block main packages? if so how do you typically respond to that?), individual packages don't really have maintainers, many developers are paid by canonical etc.
Reply to: