On Thu, Apr 01, 2010 at 10:58:07AM +0900, Charles Plessy wrote: > 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.
I'm not familiar with how the package sections came to be. I'll reluctantly take your word for it. > 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 Agreed. > (just like our website is being reimplemented on wiki.d.o or alioth.d.o, > etc.). I didn't know about this. > I think that one of the causes is that it is not directly under the project's > responsibility. I'm not sure what you mean by this. Having the packages in the distro grouped by secitions isn't the repsonsibility of the distro? > What is your vision of the package sections? Where is the big > picture? Its a way of categorizing packages to facilitate browsing through or searching for packages in debian. Its not much more than this. I think that once debtags is farther along, they could replace sections completely. > 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? I don't understand what you mean here at all. I'm not sure what time is being saved. If you don't want to care about them, you can probably ignore them. Some people don't, the ftp team makes sure there are sane choices being made in the cases where maintainers haven't cared enough. IfIf there is a package in an incorrect section or with the wrong priority, please just file a bug against ftp.debian.org and it will get fixed. Opening up write access to the database that maintains the archive to all developers just so that they can change sections (something that you yourself characterize as "not much useful" anyway) seems like something that is not worth the security risk. > > 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. The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. The issue that I was talking about would be when the license of a piece of software prohibits us from legally distributing the software at all, or if distributing the software might include a legal burden we don't want to carry. For instance, if someone were to upload software such as opera or adobe flash or skype which has explicit licenses which prohibit any redistribution, we cannot allow the ftp-master machine to become a point of redistribution. For this reason, we don't allow the software to be copied off of the ftp-master machine until we've audited it with respect to software licenses. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. > > 3) The FTP team is looking for people, but you left my propositions to help > with the NEW queue unanswered. If there were propositions that we aren't already discussing. I missed them. I'm sorry. > Whatever your opinion on me as a person, you > choice was to discard some help with no justification. Sorry. I mussed have missed something. I don't think there is any reason to discuss my opinion of you as a person, lets please drop that, its irrelevant. I don't know what help you are offering that I'm discarding with no justification. The ONLY thing I've done so far was to justify. > > 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). How do you think it should be defined then? > I am not surprised that your team is running out of > manpower frequently. I'm not either. But I get the feeling that we have differing opinions about why that is. It seems to me that we don't retain members becuase there is a lot of very very tedious, often thankless work that often puts you in the position of getting on people's bad side by giving them bad news about the non-distributability of their packages. If you have a differing opinion, what is it? stew
signature.asc
Description: Digital signature
