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

Re: Questions for all candidates: decentralization of power



Le Wed, Mar 31, 2010 at 12:00:05PM -0400, Mike O'Connor a écrit :
> 
> You do get to choose the priority and section which your packages belong
> to, though the ftp team can override your choice.  When we do override
> your choice, you get an email inviting discussion about it.  I can't
> think of any instance where the ftp team and maintainers haven't been
> able to come to an agreement about where the packages belong.  The
> alternative option, where DDs are given write access to the dak database
> doesn't seem worth the security issues for the small benefit(?) of
> avoiding having this discussion with the ftp team.
> 
> Inspecting new packages which haven't cleared NEW has potential legal
> problems.  We don't want to be in the position where we are distributing
> software that might not be legal for us to distribute.  Our trend has
> been to increase the amount of info about the packages we make available
> on http://ftp-master.debian.org/new.html (currently down), but we have
> to stop short of potentially illegally distributing software.  For
> people that want to help with the process of auditing packages in NEW,
> The ftp team is looking for new members, our most recent solicitation
> being here:
> http://lists.debian.org/debian-devel-announce/2010/03/msg00003.html

Hi Mike,

you give three interesting examples on how the FTP team is isolating itself.


1) By a combination of (self-appointed?) authority and technical design, the
package section splitting becomes a private tool of the FTP team. Apart from a
couple of usual examples, sections are not much useful nowardays, and they are
getting reimplemented in parallel through debtags, tasks, or meta-packages
(just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.).
I think that one of the causes is that it is not directly under the project's
responsibility. What is your vision of the package sections? Where is the big
picture? Why the maintainers should even care about them if everything in the
design reminds them that sections are not their business, except for saving a
bit of your time at the first upload?

2) We can not export software without doing some procedures, but what is the
definition of an export? If it is not an export when a DD appointed by a DD
delegated by the DPL logs in from outside the USA to inspect a package, then I
think that the DPL or the Project can delegate all DDs equally the possibility
to do this inspection and write in a NEW package's ITP bug what they think
about its copyright and how it is summarised for Debian. Again, the line is
currently drawn in a way that increases your workload. That is your choice.

3) The FTP team is looking for people, but you left my propositions to help
with the NEW queue unanswered. Whatever your opinion on me as a person, you
choice was to discard some help with no justification.


In my opinion, the perimeter of the FTP team is not well defined, and has a
tendency grow with self-appointed new responsibilities (like the lintian checks
at upload for instance). I am not surprised that your team is running out of
manpower frequently.


Debian needs to trust more its maintainers, and shift from control to
resilience over errors. This requires some infrastructural work, but I think
that it is worth the effort.


Cheers,

-- 
Charles


Reply to: