Re: Questions for all candidates: decentralization of power
On Thu, Apr 01, 2010 at 01:45:45PM +0900, Charles Plessy wrote: > If it is not an export or a license violation that a member of the FTP team > inspects a package, then I do not think it is for any other member of the > project. I am not proposing to give a read access to the NEW queue for any > other purpose. I think that what we are doing now puts us in very safe legal ground. I fear what could happen when some litigious copyright holder accuses us of illegally redistributing their software and our reponse is, "We just copied it to one other machine so that we could make it available to our entire membership." > If because you do not trust the other DDs to respect the rules, that packages > in the NEW queue must not be resdistributed before they are accepted, then > yes, > you have to do the work alone. It doesn't take long processing NEW to realize that many DDs cannot be trusted to make sure that all of the code they are uploading is legally redistributable. > If we do not think that the DDs respect the > rules (http://www.debian.org/devel/dmup, in which we could add a note about > NEW > packages before opening up the mirror), how can we tell our users that our > system is secure? The problem is also one of accountability. If the DD screws up and eventually an ftp-master or a mirror owner or DPL or SPI or someone else is the one getting sued, can the person getting sued hold the DD accountable? stew signature.asc Description: Digital signature
Re: Questions for all candidates: decentralization of power
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 w
Re: Questions for all candidates: decentralization of power
On Sun, Mar 21, 2010 at 12:46:44AM +0900, Charles Plessy wrote: > Dear Clint, > > I also think that there are many restricted operations that should be opened. > Write access to our website, chosing the priority and section of our pacakges, > triggering bin-NMUs, designating new members, inspecting new packages > submitted > to our archive, ??? 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/msg3.html stew signature.asc Description: Digital signature
Re: Q for all candidates: license and copyright requirements
On Wed, 24 Mar 2010 00:32:19 +, Dmitrijs Ledkovs wrote > 2. If tarball is not redistributable > It belongs in non-free, or must be repackaged to become redistributable No, If its not redistributable, It doesn't belong in non-free or any other place we distribute software. This is why we don't distribute other popular non-redistributable software like Opera or skype or flash in non-free. stew signature.asc Description: Digital signature
Re: GR proposal: Do not require listing of copyright holders
On Sat, Mar 21, 2009 at 03:08:26PM -0700, Steve Langasek wrote: > On Sat, Mar 21, 2009 at 09:38:04PM +, Mark Hymers wrote: > > I've therefore asked the DPL to get us legal advice on the minimum > > copyright information we should ship in debian/copyright. Once we get > > this, I propose we amend policy to be crystal clear about what we need > > (basically, what we can get away with[0]) and then all carry on. > > I think this needs to be a two-part question to the lawyer: what does > copyright law require, and what does the GPLv3 require. I believe they are > not the same. > And then, of course, there are the other dozens of licenses. Some of them (such as the BSD license in /usr/share/common-licenses/BSD) very clearly require us to list copyright holders somewhere in the binary packages. Some don't have this requirement in the license. Some are less clear. stew signature.asc Description: Digital signature
Re: gr_lenny vs gr_socialcontract
On Fri, Dec 19, 2008 at 02:44:46PM +0100, Johannes Wiedersich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Manoj Srivastava wrote: > > I suspect it would not be hard to create a non-free installer CD > > that obviates the requirement of a separate USB key for remote > > installs. > > If (almost?) everyone will use non-free stuff anyway, why not just make > live more easy for everyone and include it on all the installer images. > People still have the freedom to buy freely supported hardware or to not > use non-free firmware. So then debian becomes the "100% Free Operating System (some restrictions apply. see details*) (* Operating system deosn't include installer images, or kernel. Freedom only guaranteed on one CPU.) > > I don't think that any computer will be more 'free' whether some > non-free code is loaded on boot from hard disk (kernel firmware blob) or > whether the non-free code is loaded from ROM like the BIOS. IMHO, it > also does not contribute in any way to freedom to force users to load > the firmware blobs from a separate installation medium. Or to drive them > into buying hardware with on board ROM chips for the then still non-free > firmware/software. The point isn't to try to force users to only have free software on their machines, the point is to only have free software in debian. In my eyes, it is important to make a very clear distinction between what is free and what is not free, even If it means some inconvenience. It would be nice to be able to say with more confidence, "If you get it from debian main, you can be assured it is free. Debian worries about the licenses, so you don't have to." If we make users have to decide between the "100% free installer" and the "installer with non-free", and it makes the user have to think about "what is this non-free stuff, and why should I care". I think it is an added side benefit. If a user at some point decides to "vote with their pocketbook", by choosing a piece of hardware based on its compatibility with debian, I think that could also be a benefit. > > I don't understand the clout around the fight for removing the little > bits of non-free firmware for the network cards, while practically no > one is able to run his/her computer without much more non-free code > hidden in all the other places. Because if its software, and its not free software, it just doens't belong in debian. Read the last paragraph of the social contract: "We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our archive for these works" We can still acknowlege that some our users require the use of non-free software during the install process, without having to keep main contaminated. A line has to be drawn somewhere. If we don't fight for the line, I worry about it becoming a slippery slope that starts with firmware, then starts to include all kinds of binary blobs like the non-free nvidia drivers, then who knows what, a non-free userspace Then stuff like ipw3945d, then at some point the discussion we are having is "why not include rar, since we already have all of this other non-free stuff. The arguments about "we are losing users to [other distro] becuase of this" Hold very little weight. "Be a popular distro" is not a goal of debian, "Be a free distro" is. "Let's include non-free software because everyone else is" is a counter-argument to me. If we are the only ones left that cares so much, all the more reason to stick to our principles. stew signature.asc Description: Digital signature
Re: Technical committee resolution
On Tue, Apr 01, 2008 at 04:20:30PM -0500, Manoj Srivastava wrote: > On Tue, 1 Apr 2008 13:21:52 -0400, Mike O'Connor <[EMAIL PROTECTED]> said: > > > On Tue, Apr 01, 2008 at 09:43:28AM -0500, Manoj Srivastava wrote: > >> On Tue, 1 Apr 2008 05:43:47 -0400, Mike O'Connor <[EMAIL PROTECTED]> > >> said: > >> > >> > I saw multiple people suggesting such limits. I did NOT see anyone > >> > propose a reason for such a limit other than you who seemed to be > >> > concluding that the reason for a limit was the speed at which > >> > people were performing their job. I was just proposing an > >> > alternate reason to yours. If the proposers of such limits had > >> > stated that they think it would aid in the speed at which things > >> > got done, they eluded me. > >> > >> That is not quite right. I have not presumed to know what reasons > >> other people might have had for limits, nor did I propose a rationale > >> for limits; I have merely expressed my opinion about one cause for > >> the deficiencies in the tech ctte's performance. I have suggested > >> that this cause (lack of time pr participation) has an observable > >> metric, and that metric could be used to aid decisions about the > >> composition of the cotte, rather than just setting some arbitrary > >> limits. > > > well you clearly stated that you thought the proposal to limit the > > number of hats was silly "Because the number of hats does not seem to > > be a good predictor for performance..." I was just trying to suggest > > this is not the only reason that one might want to suggest such a > > limit. You seem to agree that my reason sounds valid, so I guess your > > previous reason for thinking it to be a silly proposal is no longer > > relevant, so we can drop it... > > You evidently have trouble reading what I said. I have never > ever stated anything about speed, as you quote shows. And then, > after misreading my stance, you proceed to knock down an argument never > made -- in logic, this is known as a strawman. > You are mistaken. I should have included more of the quote, where you definately talk about speed. Here is the entire paragraph: Because the number of hats does not seem to be a good predictor for performance -- at least, not for a low number of hats. There are better objective measure that would ensure hastening of the glacial pace and lack of follow through th tech ctte has. Note the words "hastening" and "glacial pace". I don't think i'm having trouble reading this. stew signature.asc Description: Digital signature
Re: Technical committee resolution
On Tue, Apr 01, 2008 at 09:43:28AM -0500, Manoj Srivastava wrote: > On Tue, 1 Apr 2008 05:43:47 -0400, Mike O'Connor <[EMAIL PROTECTED]> said: > > > I saw multiple people suggesting such limits. I did NOT see anyone > > propose a reason for such a limit other than you who seemed to be > > concluding that the reason for a limit was the speed at which people > > were performing their job. I was just proposing an alternate reason > > to yours. If the proposers of such limits had stated that they think > > it would aid in the speed at which things got done, they eluded me. > > That is not quite right. I have not presumed to know what > reasons other people might have had for limits, nor did I propose a > rationale for limits; I have merely expressed my opinion about one > cause for the deficiencies in the tech ctte's performance. I have > suggested that this cause (lack of time pr participation) has an > observable metric, and that metric could be used to aid decisions about > the composition of the cotte, rather than just setting some arbitrary > limits. well you clearly stated that you thought the proposal to limit the number of hats was silly "Because the number of hats does not seem to be a good predictor for performance..." I was just trying to suggest this is not the only reason that one might want to suggest such a limit. You seem to agree that my reason sounds valid, so I guess your previous reason for thinking it to be a silly proposal is no longer relevant, so we can drop it... > > > Are you implying that my hypothetical shouldn't be advanced here? > > Having seen no concrete rationale, I have no idea whether your > hypothetical has any value or not. Did I not invite you tpo present any > supporting arguments? You did not. You invited me to present a well thought out proposal that I was ready to defend publicly instead of just a hypothetical, which seemed to make me think that you didn't think I should be advancing any such hypothetical until I had such a proposal. Which i don't have. Sorry if I misinterpreted your intentions. stew signature.asc Description: Digital signature
Re: Technical committee resolution
On Tue, Apr 01, 2008 at 03:13:02AM -0500, Manoj Srivastava wrote: > On Tue, 1 Apr 2008 02:32:54 -0400, Mike O'Connor <[EMAIL PROTECTED]> said: > > > It seems to me however that there might be other valid reasons to > > limit the number of important hats one wears other than what effect it > > might have on ones performance. As examples I think that it would be > > reasonable for people to think that having the same person that is > > deciding which packages can be allowed into debian also be a person > > that decides what pepole can become new members might be too much > > power for one person. Or if you have one person in charge of the > > debian policy, in charge of conducting all votes and also serving on > > the team making technical deicistions it might be too much > > power. Regardless of the speed at which people in these kinds of > > positions may or may not be performing their jobs. > > Now that would be a valid argument, if you could defend it. But > that was not was being done; the sillyness resulted from putting > arbitrary numbers and limits; what you are hypothesizing requires thought > being put into the proposal, and taking into account the actual people, > roles, and powers, and stating why that amalgamation of > responsibilities is something to be avoided. Proposals about policy > are things that require effort and thought; short circuiting the > thought process and rushing in with limits just for the sake of limits > leads us nowhere. I saw multiple people suggesting such limits. I did NOT see anyone propose a reason for such a limit other than you who seemed to be concluding that the reason for a limit was the speed at which people were performing their job. I was just proposing an alternate reason to yours. If the proposers of such limits had stated that they think it would aid in the speed at which things got done, they eluded me. > > Now, if you have such s proposal (rather than a hypothetical, > and are prepared to defend that proposal in an open discussion, please > advance it here. I don't have such a proposal. Just though I would offer up an idea. Are you implying that my hypothetical shouldn't be advanced here? stew signature.asc Description: Digital signature
Re: Technical committee resolution
On Mon, Mar 31, 2008 at 11:28:24PM -0500, Manoj Srivastava wrote: > On Mon, 31 Mar 2008 12:47:42 -0300, MartÃn Ferrari <[EMAIL PROTECTED]> said: > > > On Mon, Mar 31, 2008 at 6:46 AM, MJ Ray <[EMAIL PROTECTED]> wrote: > >> Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > >> > better job of them than other candidates, why deprive the project > >> > due Clint's law of pointless limitations? [...] > >> > >> I feel that the above personalisation of argument is unhelpful. > >> > >> I don't believe that we should limit people to one hat, but limiting > >> people to one hat *of this type* might be helpful and merits further > >> consideration. What is "this type"? Probably we need to re-sort > >> http://www.debian.org/intro/organization> to decide that, if people > >> http://www.debian.org/intro/organization> feel it's a good idea. > > > I fail to understand why Manoj sees this as such a silly idea, and it > > Because the number of hats does not seem to be a good predictor > for performance -- at least, not for a low number of hats. There are > better objective measure that would ensure hastening of the glacial > pace and lack of follow through th tech ctte has. > It seems to me however that there might be other valid reasons to limit the number of important hats one wears other than what effect it might have on ones performance. As examples I think that it would be reasonable for people to think that having the same person that is deciding which packages can be allowed into debian also be a person that decides what pepole can become new members might be too much power for one person. Or if you have one person in charge of the debian policy, in charge of conducting all votes and also serving on the team making technical deicistions it might be too much power. Regardless of the speed at which people in these kinds of positions may or may not be performing their jobs. IANADDyet, stew signature.asc Description: Digital signature
