Re: Status of resolutions about TC tweaks
* Anthony Towns (aj@azure.humbug.org.au) [060302 12:11]: On Thu, Mar 02, 2006 at 08:51:10AM +0100, Andreas Barth wrote: ] So I propose we establish a rule that we won't make decisions on ] issues that aren't ready for an immediate NMU when we make that ] decision. BTW, I think something similar should be done, but not as strict as in this resolution draft. But let's discuss about that seperate from voting details. So, we're considering whether ndiswrapper should be moved to contrib atm. We don't actually have a package that we could upload to do that though -- should we decline to consider the issue without it? If we were to vote in favour of moving to contrib, and had a package we could upload it immediately, and request ftpmaster (eg, me) to process it straight away, and we'd be done. OTOH, without it, we'd either have to do it ourselves, or hope the maintainer was willing to. In the case of ndiswrapper, I think we want such a package, yes. But consider e.g. a similar case where the maintainer of a new package asks us please decide where the package should go to - in that case, there is nothing to NMU (another problem occurs if we are asked to decide/overrule in a case where the tech ctte doesn't have direct possibilities to commit a change - in that case, I think we should require a patch exists). So, I think the resolution should rather run like: We establish a rule that we won't make decisions on issues that are ready. This means, - for overruling a package maintainer's decision, an appropriate package for an NMU exists, and if we overrule, we upload that NMU; - for other overrulings, an appropriate patch exists, and if we overrule and someone from the tech ctte can apply that patch, we apply it; - for other decisions, we make sure a similar state of readiness exists. (Just a draft.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: Please reject to rule on the ndiswrapper question
On Wed, 01 Mar 2006, Steve Langasek wrote: On Wed, Mar 01, 2006 at 01:03:56AM -0300, Henrique de Moraes Holschuh wrote: Otherwise, the ctte could overrule just about everything in Debian. Were they not bound by the SC themselves, they could overrule even the SC itself by determining that the files that determine in which suite a package go should make all packages in the non-free suite go into the main suite. I wonder why you think it's *not* the intention of the constitution that the technical committee be in a position to overrule just about everything in Debian. The exact phrasing of the constitution is: *IMHO* the constitution doesn't feel like that was the intention, and it doesn't read like that either. So, please excuse me if I will not read into the constitution overlord powers for any body (ctte included) unless it is explicitly written in there. Of course, I can be convinced that the constitution does give the ctte that power, but so far, I am not. Otherwise, why didn't we pose to the ctte a request for how the GFDL issue should be handled? 4. Overrule a Developer (requires a 3:1 majority). The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. Overruling a Developer is so far from being able to overrule just about everything in Debian that it ain't funny. The example given is also of a Debian Developer in typical package maintenance function, and not of the Secretary, ftp-masters, or other delegates (and de-facto delegates) of the DPL when acting on their roles. To me, it is obvious that the ctte can resolve a dispute with the ftp-masters when the interpretation of the DFSG, SC, a GR or the constitution is not the object of the dispute. Nowhere do I see anything that says the committee must limit itself to requiring a developer to take a particular technical course of action *that agrees with the developer's pre-existing political views on the issue*. I Who said anything about the developer's pre-existing views? of course the ctte can't be bound by that, it wouldn't be able to do its job otherwise. I *specifically* talked about project-wide policy, as in that set by GRs, the SC, the DFSG, the constitution and whatever else we have that sets policy (and I am *NOT* talking about the Debian policy document, btw). only appelate body defined in the constitution, I don't believe it was ever intended that their authority could be vetoed by claiming that a particular technical decision was made on religious grounds. Constitution section 6.1.3 makes it clear that if the right person appeals, the ctte is brought into play without any possibility of other parts complaining (well, of their complaints affecting the appeal, anyway). You can appeal to the ctte always, but it doesn't have powers to *enforce* its decision unless its under 6.1.1, 6.1.2, 6.1.3 and 6.1.4 sections of the constitution. AFAIK the ftp-masters didn't appeal, so 6.1.3 is out (if they did appeal, then the question is indeed in the ctte enforcement sphere because of that). 6.1.2 is out as this is not a jurisdiction question. 6.1.4 could be worded much better. Does that apply to any registered member of the Debian project (that includes everyone, DPL and Secretary, DPL delegates and common Developers)? Or does it apply to the Developers as defined by 2, which clearly separates the DPL, Secretary, DPL delegates, the CTTE, a Developer doing an unamed task of his and the body of Developers? The way it is written, IMHO 6.1.4 is directed to a single Developer doing one of the usual Developer things (i.e. packaging, bug-fixing, etc), as opposed to delegates and other specialized tasks, or the entire body of Developers. As for 6.1.1, IMHO the examples and the emphasis on technical make it quite clear that stuff like interpreting the constitution and DFSG is not in 6.1.1's scope. I think this is uncontroversial, at least Ian Jackson seems to hold a similar position about 6.1.1, in http://lists.debian.org/debian-ctte/2004/06/msg2.html (last paragraph). the constitution invests in the TC, and you kinda have to trust that we won't abuse it. I do trust the ctte not to go around abusing its power. I would trust the ctte to not take extreme decisions that would split the project even when within its power as well (instead, I expect the ctte would call for an GR on the matter). But I still don't think the ctte has power to overlord about everything in Debian, unless you mean that it can be *requested* to do so by a body that has the power to address a given issue already, through 6.1.3. The question we have been asked to consider is, which section should the ndiswrapper package list in its control file?
Re: Bug#353277: ndiswrapper in main
On 3/2/06, Steve Langasek [EMAIL PROTECTED] wrote: With that in mind, policy on contrib says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib And I think ndiswrapper is a sort of free accessory for non-free programs. Ok. Would you say the same thing about a free library that implements an API/ABI which is primarily of interest to users of pre-existing non-free software? If not, why is one an accessory and the other not? That's a good question. The way I'm currently thinking: If there are debian packages that you can use in WINE, or if it has some functionality that makes it useful in and of itself, then it belongs in main. Otherwise it belongs in contrib. For example, if there's free software being developed against WINE (as a UI, or whatever) then that's sufficient reason right there, to leave it in main. I'm willing to hear reasons why this reasoning is wrong, but if we're going to go that route I think we to think those reasons through and come up with some suggested policy that distinguishes between the WINE case and the cases that belong in Contrib. Perhaps it could be phrased that ndiswrapper has a need for the presence of some software which is not available in debian main. If we didn't ship any free software built around the Motif API, would this mean lesstif had a need for the presence of some software which is not available in Debian main? I've been suggesting that the answers to these questions depend on our best understanding of how our users use the software. If it's built and deployed for people to develop against, that's one thing. If it's not documented and supported for development work, and no one is developing against it, and it's only being used by people who want to install something that's not free, then that's an entirely different situation. -- Raul
Re: Bug#353277: ndiswrapper in main
On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote: Ok, we should probably find a different word to describe this relationship. Perhaps it could be phrased that ndiswrapper has a need for the presence of some software which is not available in debian main. But it doesn't -- ndiswrapper will sit there quite beningly if the non-free driver isn't present. It'll do everything it's supposed to -- link with the kernel and provide an ABI for other software -- without any errors. Ok, but that's not everything it's supposed to do. If that's all it needed to do then the code implementing the ABI could do (*0)= dump core and that would be fine. You're right, of course, that it's more precise to say that the user has this need. Then again, there have been packages where there were two groups of users, one who would be better served by a dependency and another who would be better served without. -- Raul
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote: On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote: Ok, we should probably find a different word to describe this relationship. Perhaps it could be phrased that ndiswrapper has a need for the presence of some software which is not available in debian main. But it doesn't -- ndiswrapper will sit there quite beningly if the non-free driver isn't present. It'll do everything it's supposed to -- link with the kernel and provide an ABI for other software -- without any errors. Ok, but that's not everything it's supposed to do. If that's all it needed to do then the code implementing the ABI could do (*0)= dump core and that would be fine. Eh? If I found something that claimed to implement the C string library (strcpy, strcmp, strstr, etc) but just dumped core everytime it was invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave some behaviour undefined (such as free(x); free(x);), but none leave all of it undefined. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote: On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: But it doesn't -- ndiswrapper will sit there quite beningly if the non-free driver isn't present. It'll do everything it's supposed to -- link with the kernel and provide an ABI for other software -- without any errors. Ok, but that's not everything it's supposed to do. If that's all it needed to do then the code implementing the ABI could do (*0)= dump core and that would be fine. Eh? If I found something that claimed to implement the C string library (strcpy, strcmp, strstr, etc) but just dumped core everytime it was invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave some behaviour undefined (such as free(x); free(x);), but none leave all of it undefined. For the case you described, it would not dump core. -- Raul
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 09:21:33PM -0500, Raul Miller wrote: On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote: On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote: But it doesn't -- ndiswrapper will sit there quite beningly if the non-free driver isn't present. It'll do everything it's supposed to -- link with the kernel and provide an ABI for other software -- without any errors. Ok, but that's not everything it's supposed to do. If that's all it needed to do then the code implementing the ABI could do (*0)= dump core and that would be fine. Eh? If I found something that claimed to implement the C string library (strcpy, strcmp, strstr, etc) but just dumped core everytime it was invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave some behaviour undefined (such as free(x); free(x);), but none leave all of it undefined. For the case you described, it would not dump core. It wouldn't dump core if I didn't use it; as soon as I did, it would dump core, which would mean it didn't implement the ABI it claimed to, whether I was using it or not. We're getting into if a tree fell in a forest... territory here though. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 07:27:41PM -0500, Raul Miller wrote: On 3/2/06, Steve Langasek [EMAIL PROTECTED] wrote: With that in mind, policy on contrib says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib And I think ndiswrapper is a sort of free accessory for non-free programs. Ok. Would you say the same thing about a free library that implements an API/ABI which is primarily of interest to users of pre-existing non-free software? If not, why is one an accessory and the other not? That's a good question. The way I'm currently thinking: If there are debian packages that you can use in WINE, or if it has some functionality that makes it useful in and of itself, then it belongs in main. Otherwise it belongs in contrib. So... $ zcat dists/unstable/main/binary-i386/Packages.gz | grep-dctrl -FDepends -sPackage wine Package: libwine-alsa Package: libwine-arts Package: libwine-capi Package: libwine-cms Package: libwine-dev Package: libwine-esd Package: libwine-gl Package: libwine-jack Package: libwine-ldap Package: libwine-nas Package: libwine-print Package: libwine-twain Package: wine Package: wine-utils $ We have zero packages in main that use wine, except for the wine-utils package itself that contains various free toy implementations of common Windows utilities -- no more useful alone than wine itself is. By your reasoning, does this mean wine should be moved to contrib? Or is there some in and of itself usefulness that applies here but not in the case of ndiswrapper? For example, if there's free software being developed against WINE (as a UI, or whatever) then that's sufficient reason right there, to leave it in main. Counting the toy utilities that are bundled with wine, or only other free software? I don't know of anyone developing free software against wine. I've used it to develop *non-*free software; I could *imagine* someone developing free software against wine, but I can also *imagine* someone developing free software against ndiswrapper. I'm willing to hear reasons why this reasoning is wrong, but if we're going to go that route I think we to think those reasons through and come up with some suggested policy that distinguishes between the WINE case and the cases that belong in Contrib. Well, I would note that at this point, we seem to no longer be talking about confirming existing policy; if we were, I would expect that more weight would be given to AJ's proposed criteria, since as an ftpmaster he's pretty much the resident authority on what this de facto policy is. Perhaps it could be phrased that ndiswrapper has a need for the presence of some software which is not available in debian main. If we didn't ship any free software built around the Motif API, would this mean lesstif had a need for the presence of some software which is not available in Debian main? I've been suggesting that the answers to these questions depend on our best understanding of how our users use the software. If it's built and deployed for people to develop against, that's one thing. If it's not documented and supported for development work, and no one is developing against it, and it's only being used by people who want to install something that's not free, then that's an entirely different situation. But there's plenty of documentation for writing NDIS drivers, just as there is for writing Windows applications. AFAIK, you can develop NDIS drivers on Debian using mingw just as you can develop Windows applications this way. Doesn't that leave as the only distinction between wine and ndiswrapper the theory that one is interesting to free software developers and the other isn't? Does this mean wine and ndiswrapper belong in the same section, or do we then shuffle packages back and forth between contrib and main depending on the results of surveys of some kind? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 11:26:56AM +, Ian Jackson wrote: Steve Langasek writes (Re: Bug#353277: ndiswrapper in main): 1+5. As noted in my follow-up comments to Ian's proposal, I think the rationale is great, but I draw the opposite conclusion from it. :) I'm afraid you'll have to elaborate on that :-). Ah, what I had written before was: 4. The Committee does not wish to overturn or change established political policy about the distinction between main and contrib, and does not wish to usurp the political authority of the Project Leader. I agree in principle with what you've written here, but I disagree that it supports your conclusion. The ndiswrapper package is currently in main; saying that it belongs in contrib *is* an overturning, both of the package maintainer's judgement and of the judgement of the ftpmaster who approved it into the archive. I don't see how we can discern here an established policy that says ndiswrapper belongs in contrib when it sits in main today. I also didn't see that you had called for a vote on this one, just noted that it was submitted as a votable option, so I was hoping that before voting we could put together a couple of other ballot options representing other points of view that could be voted on as a group, since that's the way that Condorcet works best. Right. It seems that we're not going to just make a quick decision here. But that means we need your opinion written up in resolution form. Well, AJ seems to have had time for this before I did; so more follow-up on this to his draft resolution. Some questions that may help: * Do you agree with Raul and my view about the policy manual text in general - ie, paragraphs 3-4, 6(first instance), 7 and 8 of Raul's version and paragraph 10 of mine ? 3-4 6, yes. (The first 6, which I guess is what you mean by first instance; both of you seem to have double-sixes in your resolutions.) 7, no; and consequently 8 is also no, since it's worded as an exception to 8. 10 I'm pretty indifferent to. * What other things are like ndiswrapper that you think we all accept should be in main ? We might be able to suggest possible distinctions between ndiswrapper and your examples, or between your examples and (say) a package which Depends: on a non-main package. The packages that seem to be most like ndiswrapper in this regard are wine, dosemu, ibcs (no longer extant), and mol. All of these packages are (or were while they existed) in main; all of them are free software written for the primary purpose of making it possible to run various non-ported, non-free software on Linux. (Hmm, correction; mol is available in main because it can be used with mol-drivers-linux, but mol-drivers-macosx is in contrib. So we're inconsistent after all, hurrah!) While it is possible *to* use these packages with free software, that's not the common case by any means, and not the principal reason that they're interesting to users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#307833: Processed: Re: apt-file: broken. curl is needed
On Tue, Feb 28, 2006 at 11:35:02AM +, Ian Jackson wrote: I've taken a look at the bug logs and I'm very disappointed with the maintainer's lack of engagement. There seem to be a lot of people who are interested in helping maintain this package. Would any of the keen people we see involved in this bug report consider contesting the maintainership of the package ? The Committee has the power in s6.1(2) of the Constitution to Decide ... who should be the maintainer for a package but of course only when developers disagree. Jesus, you write to Sebastien: In a previous conversation with me you pointed out that there are others downloaders that a user can decide to select, but failing to depend on at least one of the ones provided as a package by Debian renders the package unusable. Which is not acceptable. Can we see that conversation ? Are the emails archived anywhere ? The control file at the moment says: Recommends: curl, wget which is definitely wrong since at most one of these is used. Sebastien, what is your opinion of Mike O'Connor's patch ? I understand that this bug has been (silently) fixed in the latest version of apt-file. Any objections to reassigning the bug back to apt-file and closing this issue out? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
