Andrey Rahmatullin <wrar@debian.org> writes: > On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: >> > > I don't know if that has been proposed before, but how about waiving >> > > the NEW queue requirement for experimental packages as a start? >> > > [...] Since packages in experimental will never land in any >> > > official release, I think dropping the NEW queue requirement has no >> > > negative impact. >> > This makes no sense as NEW is mostly about checking licenses. >> >> I think this is exactly why it makes sense. I think we can trust the >> DDs to not make any large mistakes (e.g. putting steam in main). > The existence of NEW means we currently don't, for completely new > packages. > >> Since packages in experimental aren't supposed to be used by anyone else >> but the DDs themselves, the "damage" of a potentially missing / wrong >> license is minimal, considering that DDs are aware of the fact that the >> packages aren't "official". > The "damage" that's usually being discussed is Debian distributing > something we can't, not users e.g. getting non-free software thinking it's > free. Packages in NEW aren't even publicly accessible because of this, > and discussions of switching to git-based source packages end with "we > can't publish git history of random repos as we don't want to review > and rewrite it". > >> However I find that view a bit weird. Any update can change the license >> or add new files with different licenses, nothing is ever checked by the >> ftp-masters (that would be insanity). > Sure. And in light of the above, assume: - Source package foo with a single binary package foo, entered Debian under thorough FTP Masters checking 20 years ago, has had a very active upstream and rapid development (including numerous rewrites and language changes) since then, but always just that single binary package. - Source package bar that ships a binary libbarN, entered Debian under thorough FTP Masters checking a few weeks ago after NEW queueing for months. Slowly developing upstream with few, very limited and organized, changes over time. Needs a SONAME bump. Or needs to add a new bar-utils binary, or something. If the goal is to maximize our users' confidence that foo and bar can be assumed DFSG-compliant, then it does not to me seem like the best use of our (FTP Masters') limited resources to subject bar to another thorough review (perhaps having it spend another 4 months in NEW?), while trusting the maintainer of foo with no further scrutiny. I'd go as far as to say that if we could not trust the maintainer of foo the way we do, we could not reasonably make Debian work. And if we can trust the maintainer of foo with a task where it's arguably easier to make a mistake than it is for the maintainer of bar, and we cannot trust the maintainer of bar in that safer case, then we are quite inconsistent. I would argue that this inconsitency is problematic, both because it leads to a misapplication of resources, because it may well convey a false sense of safety onto our users, and because it may be detrimental to attracting new volunteers. -- Gard
Attachment:
signature.asc
Description: PGP signature