On Thu, 18 Nov 2021 at 19:28:28 +0500, Andrey Rahmatullin wrote:
On Thu, Nov 18, 2021 at 02:52:56PM +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.
Part of the problem with any discussion of NEW is that the answer to
"is NEW for A, or for B?" is usually "yes".
For new source packages, my understanding is that NEW is for:
* checking for acceptable licenses / absence of unacceptable licenses
- not breaking other people's rules, e.g. infringing copyright by
distributing without permission to do so
- not breaking our own self-imposed rules, e.g. not allowing non-free
software into main/contrib
* checking debian/copyright completeness
- all licenses mentioned
- all license text copied, unless present in common-licenses
- all entities claiming copyright mentioned (historically for all licenses,
now only for licenses that can be interpreted as requiring it)
* package namespace control
- not accepting obscure/niche packages with very short/generic names
- not accepting packages with misleading names
- enforcing naming conventions like `import foobar` -> `python3-foobar`,
`use Foo::Bar` -> `libfoo-bar-perl`, `libfoobar-1.so.2` -> `libfoobar-1-2`
and
https://github.com/go-debos/fakemachine ->
`golang-github-go-debos-fakemachine`
- not having excessively big bundled packages
- not having excessively small micro-packages
* any other QA checks that the ftp team feel like doing
- embedded code copies
- obviously wrong packaging like a shared library in /usr/share
- ??? (I don't know what else the ftp team actually look for in practice)
The justification for NEW packages being unavailable to people outside
the ftp team is that we don't want to be distributing them until they
have had some sort of checking for redistributability (the first of my
points above), because if we don't have permission to redistribute, then
that's copyright infringement. I think a lot of the other inconvenient
things about NEW are consequences of that.
However, most of the other reasons for these checks are essentially self-imposed - for example there's no legal reason *preventing* us
from distributing nvidia-graphics-drivers in main, but we don't *want*
to do that, because it would break our self-imposed rules and undermine
our intended mission (making an entirely Free OS). Similarly, there's no
legal reason preventing us from redistributing obviously wrong packages,
but we want to make a high-quality operating system, so we want to
exclude those packages if we can.
I think it's perhaps useful to make sure we distinguish between rules
that we have because external factors force us to have those rules
(like needing to avoid copyright infringement), and rules that we have
chosen for ourselves (like main being self-contained and Free Software).
Rules that we have chosen are something that we as a project can change,
if we can reach consensus that we want to, and the impact of breaking
them is whatever we as a project think it is. However, rules that come
from external factors are mostly not something that we can change: in particular, needing to have permission to redistribute is something that
is imposed on us by the legal system rather than something that we have
chosen, and it is not within our power to change it. The only thing about
those rules that could potentially be changed by project consensus would
be the level of legal risk we are willing to take, in exchange for the
benefit of being able to do things that benefit the project and our users.
The existence of binary-NEW (for existing source packages that have
added a new binary package) seems like partly namespace control, and
partly an accident of implementation: packages go into these queues
because their names do not appear in the overrides file that lists
packages that were already accepted, and that is equally true for new
binary packages in an existing source package. My understanding is that
the ftp team have a policy of taking the opportunity to do all the same
legal and QA checks they would do for new source packages, not just the
package namespace control part, on the basis that in principle every
package in the archive should be able to pass those checks at any time
(and it would be a RC bug if it didn't).
Of course, in practice typical uploads that do not introduce a new binary package name do not get held in a queue for manual review (because that
would slow down development to a point where we could not make a practical
OS distribution), so this leads to maintainers making packaging decisions
that are not necessarily "right" in the abstract, such as not splitting packages that ideally should have been split, because if they do the
"right" thing their package won't get into unstable until an arbitrary
time has passed (and might get rejected entirely if they have not copied
all the applicable licenses into the right place), whereas if they do the "wrong" thing it will be available immediately. The incentives are not necessarily particularly well-aligned with what we want happening.
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)