[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19.01.2012 05:32, Michael Gilbert wrote:
>> Second concern i have here is that (AFAIK) everyone can upload
>> everything to mentors.debian.net. Which would mean we then would/could
>> distribute non-distribiteable material under the debian.org domain. How
>> can this issue be resolved? The webpage only very vague says:
>> "You can upload your package to this server (through special tools like
>> 'dupload' or 'dput') and after a few checks it will be stored in our
>> repository." What are these few checks?!
> 
> So, given the first statement above, alioth may not be the best
> example, but its a .org machine that is already subject to this
> potential problem and it seems to get along just fine.  For example,
> www space could potentially be used to host non-distributable files,
> and no one is really actively checking for that.  I don't recall if
> new users have to agree to the DMUP when they create their alioth
> account, but that could be a solution to the problem (on alioth as
> well as for mentors); perhaps with some additional wording for this
> type of hypothetical misuse.

Alioth users do not need to agree on the DMUP or any code of conduct on
that matter. Talking with Jörg in IRC yesterday about this topic I got
the impression, we'd need kind of a NEW queue processing for new,
unknown uploads which should be used as an ingress filter to new
packages. While I was kind of expecting this answer, I do not see the
possibility to implement that in the near future.

That approach lacks both, code support in mentors and a list of willing
people to process Mentors NEW queues. However I agree with Jörg, that
that's the only clean and feasible approach in the long time perspective.

Answering zobel's question: Packages which are uploaded to mentors are
being tested very rudimentary. We're basically testing the package for
consistency (e.g. all files present, checksums match, ..., probably very
similar to what dak does) and we're running Lintian on the package, but
we're not using any Lintian auto-rejects as we're kind of an archive
where packages are supposed to be broken from that perspective.

We're not doing any license checks, although pabs was pushing use of
automated license checks. We're aware of that problem, but we're not
having any implementation right now. Yet we're deleting packages where
we notice they're not distributable (i.e. not even non-free). Yes,
that's a post-publishing removal.

> Note that alioth as a .org machine can even be used as a mentors
> alternative today: e.g.
> http://alioth.debian.org/~gilbert-guest/unstable.

Right. But I think having one bad example is a poor rationale to get yet
another. :)

> Also, I would imagine that at some point someone will automate it so
> that RFP bug closure causes a removal of the mentors package.  Thus as
> bugs are closed out over time, anything non-distributable will just go
> away.  Additionally, give reviews to outright close bugs that they
> find in such a situation so it goes away more immediately.

Right. Currently I have code in beta-testing which removes packages from
mentors which are announced by dak to be accepted into unstable.

> Ultimately this is a rather hypothetical concern and as such deserves
> to be treated more on a case-by-case basis; rather assuming there is
> going to be a lot of abuse leading the discussion toward a strong a
> priori solution (in this case rejecting officialization of mentors).

The problem is existing in theory, but not a real problem. This does not
mean it couldn't happen.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPF/32AAoJEMcrUe6dgPNtBzkP/Aol7bC9NwurdC3gQOCNWtlx
nFQhUs+Omzb7ojZBQsW8eO3j86Cxk7XECq9Sxbbz60K5d/+jEhTDUOk8PkijWWni
DTLbXwvtrcKnzBg5/gQyFH3Gtj4XYdfEwCiPsLhVHaAAemxL0DalIV3/o+yMjYze
Mhs9ssQIGgYj1wA8Kw8UYwn24hJGphzpCNGixs4XVl/y2XE68QlKoQr6d4aqkG3P
MVHh+tjpB8cIulS5tDhlCfbsw+a0ufi9rNMRJdkbeP/cyQlNXe0Bh3dDMxZ5EyR6
8qPp6yTU1FuPlht/VXOLXpHnpY+cayQG2pPmq1vqoZacuByiSJpjxPfFRFEvCBZd
jHxrgkEGeUmRE8dZBg1fgmmZ33FKcyzJKckmBuzVNmVb/cx2cph+TjBlI1+4gzEz
F6rD/UWCSX8FDthxisClUAgAPf3lM9CtokkIVGY0a7brlQVaA7fZSTWb034OML/r
Goo2VbVjGgnCVwlICJfhQQbriXcbGVsv7A40rKfYY/fMukBiXKez3J7McidXxSSb
+ErknNDM/0bNT5MMR05ZYR/44Q/crlb/QfFjKE/fiPgsnzvRw6mmTvm9EGnreLbl
f6MXk8DBLC7xjpqAe7yx3SmciXNb/pY4/fSu8F3s+Y9WcOX8E5DulKw7wW1Pbt4D
Tx5P7b7mxJ2Iob6bDYQ/
=pwr9
-----END PGP SIGNATURE-----


Reply to: