Re: Q for all candidates: (Old) Architecture Support
В Thu, 18 Mar 2010 00:02:56 +0900, Charles Plessy написа: Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : * There should be an entitiy within the project to decide which arch gets released and which not I do not completely agree with this: I think that the porters should have much more latitude on how to what their port contain. If they can assemble a reasonable subset of Debian's packages into a working system that matches the expectations of the users and that Debian can be proud of. Interesting. Are you suggesting that bugs (mostly of the FTBFS type) should be ignored at the discretion of the porters and other important teams on a per-package basis (e.g. Nobody in their right mind would install `foo' here, so it's OK to ignore the bug)? I think that this is a dangerous path to follow. IMHO it is the fastest way to *prematurely* kill an arch. Problems will start to accumulate, and issues with non-trivial inter-dependencies (e.g. resolving one major bug depends on the fix for another, sometimes in a different package) will pile up on the TODO stack, which at some point would inevitably lead to enough, this arch is problematic, so we have no choice but to exclude it from the release. Ideally, all architectures should be equal (in practice they are not, but theoretically the criteria are the same). If the project allows the lapses you seem to suggest, that would be the end of all but mainstream archs. IMVHO. Architectures that lose their mainstream position and therfore upstream support in popular heavy-weight applications could survive much longer. I seriously doubt that if your view/plan is in force. IIRC, this plan was discussed on -m68k (at least) several times in the past, and this is a plan to hide bugs, to sweep them under the carpet. YMMV, of course. (Just as a side note, you would be surprised how much impossible to use complex/heavyweight packages people install and run (even for testing purposes) on slow architectures. It is hard to predict the limit of users' patience, therefore I conclude that it is not possible to state with certainty package foo is not suitable for arch bar because of performance reasons. And yes, I say this from the standpoint of experience -- my home machine park is Jurassic, and still I manage to do what I intend to do with the tiny computer power available.) if nobody wants to fix the bug, it is a good indicator that everybody has more important, more rewarding, and in the end more fun things to do, and that we should trust their judgement by changing our release strategy instead of maintaining an institution that opposes people. I disagree with this sentiment, but who am I to disagree... If nobody wants to fix the bug, this probably means that the majority of users are not affected by this bug. However, it has always been my understanding that a Debian package maintainer should look a little bit more forward than her own packages, and should do her best to ensure that everything she maintains is at least buildable on all Debian architectures, including unofficial ones (whether former stable ones or new, struggling to become official). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hntf4s$k...@dough.gmane.org
Q for all candidates: (Old) Architecture Support
Debian has been known through the years for its excellent support for many architectures. In theory, a released arch should be as stable as the common/popular archs. (In practice, it is/was pretty close, which is good enough.) This asset is not something to be proud of because of shallow marketing reasons -- it benefits the whole Free World as many bugs are uncovered, reported, and fixed, quite often by Debian people. It would not be incorrect to say that, having in mind how many packages are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, Debian is the most comprehensive testground of the GNU system. There is a disturbing and unpleasant tendency (which probably has its roots in the Dark Times, i.e. the Vancouver Proposal) to drop support for some problematic archs as years go by. That's entirely understandable, but: - m68k was the first kicked out arch. AFAICT, it is essentially dead now and not even a miracle can save it. - alpha will not be released with squeeze; I dare to speculate that it will be in the position of m68k within a release or two. - Debian is the last GNU distro with a sparc port (Gentoo has sparc too, but it's actually sparc64); squeeze+1 will probably drop sparc. (Again speculation/clairvoyance: sparc will follow m68k's footsteps pretty soon too, especially having in mind that there's no or little upstream support.) - hppa was (and always is, it seems) at great risk, although thanks to the Herculean efforts of the porters it is in a good shape (as far as I can judge) now. - mips/mipsel are probably the most hated archs by DDs in the past few months :-), and there's no ironclad way to secure their future too. So, having in mind the obvious conclusions a sensible person could do, namely * Support for old (and not only old) architectures cannot be infinite; and there's a line to draw somewhere when it comes to a release. * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. * There's not much a DPL could do except some publicity and RFH-oriented efforts which are known not to work well... the apparent solution to the problem is: Porters are an extremely valuable resource, and the survival of an architecture in the distribution is impossible without skilled people who can fix the hardest problems, assist upstream (especially toolchain packages) and Debian maintainers in fixing the issues that prevent a specific arch to meet the release criteria. Therefore, it is essential to preserve, and even grow, such resources by doing all possible to attract people with sufficient knowledge and also pass that knowledge through. (I hope that most of you remember how much insightful Thiemo's analysis about mipsen problems were.) If you managed to keep up reading until this point, my question to the candidates is: What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is goodness or you're in the good riddance camp? Extra question to Wouter as a (former?) porter and buildd admin (feel free not to reply at all; and for other candidates -- feel free to reply if you want to): IMVHO the m68k team was one of the most energetic, enthusiastic and tireless porter teams. It included many knowledgable people who contributed upstream as well (Linux, GCC, glibc, binutils, etc.) The release team made it clear that m68k can return as a release arch at any time, so the kick-out for Etch was (supposed to be) temporary. Why do you think the m68k port is not doing very well (to put it mildly; [*])? [*] It's like the old joke when a person sends a supposed-to-be delicate telegram to a relative: John not feeling well. Funeral tomorrow noon. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq8vys6b.gnus_not_unix!%ya...@gnu.org
Re: DFSG4 and combined works
At Fri, 10 Feb 2006 14:33:54 +0100, Frank Küster wrote: Yavor Doganov [EMAIL PROTECTED] wrote: The fact that people expressed the opinion that Debian doesn't consider non-free software as antisocial and unethical scares me a lot. There are several reasons why people are for Free Software, and for sure not all of them imply that any non-free software is antisocial or, even more, unethical. If you consider non-free software as morally acceptable thing, than you can hardly defend the freedom. I am glad that Debian does not fix itself to a specific ideologic motivation *why* we produce a Free operating system, but instead confines itself to an practical definition of what Free Software means. I was under the impression that Debian is far more than a fine OS. I read the SC/DFSG and my choice was based on them, not on some technical superiority. Nevermind, my mistake. -- Yavor Doganov
Re: DFSG4 and combined works
On Thu, 09 Feb 2006 19:15:08 +0100, Frank Küster wrote: And then, has nobody ever raised the rumor that the purpose of this GFDL is non-free hullaboo is just to make sure that we will have our non-free section, for ever? I feel it the same way. This is not a campaign for freedom, but an action to cover Debian's guilty conscience. Tolerating non-free software is not what the Social Contract is about. At the end, it might result in something like Yes, we are distributing non-free software, but our main section is even more free. Except that by removing GFDLed docs won't make it more free. The fact that people expressed the opinion that Debian doesn't consider non-free software as antisocial and unethical scares me a lot. That means that I, as a user, cannot rely on Debian's judgement for freedom. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Mon, 06 Feb 2006 16:37:20 +0100, Frank Küster wrote: Zephaniah E. Hull [EMAIL PROTECTED] wrote: So, I write a program, nice, big, with a license that says that you can do anything you want with it as long as you keep the copyright statements attached and don't make any changes at all to main.c, none, not for bug fixing, not for feature changes, none at all. Oh, and you are not allowed to delete it or keep it from being linked in either. Would you consider this license free? If so, you're an idiot because it's not even close. s/main.c/secondary.c/, but that doesn't change the argument, only the name, actually. Which is part of GFDL's problem. This is not a proper example. Non-modifiability of secondary.c may obstruct further improvements of the program. This is not the case with the invariant sections, which do not prevent the manual to be enhanced. Like the following example: #!/usr/bin/make -f # debian/rules file - for debian/keyring # Based on sample debian/rules file - for GNU Hello (1.3). # Copyright 1994,1995 by Ian Jackson. # Copyright 1998-2003 James Troup # I hereby give you perpetual unlimited permission to copy, # modify and relicense this file, provided that you do not remove # my name from the file itself. (I assert my moral right of # paternity under the Copyright, Designs and Patents Act 1988.) # This file may have to be extensively modified Is it free? I am sure it is. Imagine that it contained ...provided that you do not remove my name from the file and the statement `Dominación mundial de Debian'; what would happen then? You would be still allowed to make whatever modifications you want to your debian/rules, but it will contain a personal statement -- no problem at all (except some inconvenience). As for Zephaniah's first example: if you have to remove everything, you obviously don't need this documentation and it would be much better to write a new manual from scratch. Thus you can avoid the invariant sections. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
At Fri, 03 Feb 2006 16:46:47 -0300, Daniel Ruoso wrote: Em Qui, 2006-02-02 às 02:11 +0200, Yavor Doganov escreveu: | Everything must be modifiable I'm still not convinced GPL prevents that. You're still allowed to rephrase the copyright,no-warrant,where-is-the-license notices and to present it in a way that fits to your needs. It doesn't force you to use in the same way and with the same text the original author did. Well, it is not said explicitly, so this is an interpretation. I'm quite certain that rephrasing is not allowed. I really don't like dissections of licenses, but if I write a GUI program that shows that notice moving on the status bar (or as a background, ala Star Wars movie), I guess your fork must include the same. Such notices may contain stuff like Thanks to my wife for the patience or This is the power of Objective-C. Try GNUstep, step into the freedom!. I understand that you see this as a different kettle of fish, otherwise you would have to accept that the absurd reading of DFSG 3 (must allow arbitrary modifications) is indeed absurd. In the case of GNU Emacs, the authors considered natural, even necessary, to include the GNU Manifesto in the manual. People that don't like it or aren't interested may skip it; it doesn't prevent the manual to be improved (which in fact happens extremely often). Since GNU Emacs, the first component of the GNU operating system, is considered by many as a bastion of freedom, I am really amazed that there are people who think that the GNU Emacs Manual is non-free -- I think those people do not have a proper sense of software freedom. (I know, that's not an argument, but the freedom cannot be defined or defended with dry arguments, you have to use your sense sometimes.) [And BTW, Frank can still print Emacs commands on coffee cups and distribute them without the invariant sections, since Emacs' commands are knowledge, and knowledge is not copyrightable. You cannot copyright Ohm's Law.] -- Yavor Doganov
Re: Anton's amendment
On Thu, 02 Feb 2006 11:40:13 -0600, Manoj Srivastava wrote: On Thu, 2 Feb 2006 16:40:28 +, Stephen Gran [EMAIL PROTECTED] said: We already agree to distribute text we can't modify - that is, the licenses and attributions and the advertising clauses and so forth. Err. We distribute some works, with licenses attached to them that allow us certain rights on the work in question. We are not legally allowed to modify the license, so it is a good thing it is not part of the Work. Advertising clauses are not about the work itself -- they are about ancillary activities, so are a different issue. The Invariant sections *cannot* be about the work itself by definition, i.e. they must not contain technical stuff that is relevant to the manual. Think of them as opinions of the authors that they consider important to advertise, and which can be countered/improved by adding an additional section. Similarly to the advertising clauses they cannot be removed. Certainly it is up to the authors' conscience to include such sections as well as how sound they may be. Abnormal use of this option of the GFDL may lead to a manual to become non-free, but it is not a direct consequence from the DFSG. On the other hand, I guess everybody agrees that putting the text of the GPL in such a section is a necessary thing. You are also free to explicitly state that the GFDL restrictions are also to be considered free. Hence, the 3:1 requirement, to allow that statement to be inserted into the DFSG. Perhaps you'll never change your position because this is your reading of the DFSG. But for the sake of democracy you have to assume that people think different, so it is not fair to impose your view. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, 01 Feb 2006 12:46:55 -0300, Margarita Manterola wrote: Even though I strongly disagree with Anton's position and reading of the DFSG, I think that the point is that the text says allow modifications and not allow for the whole source to be modified. Of course, the spirit of the DFSG is that of allowing to modify the whole text, but it's not explicitly stated, and thus allows for unbeliavable conclusions like Invariant Sections are free. It is not an unbelievable conclusion. If I include your personal position about, let's say, software freedom in my documentation under GFDL, I have to put it in an Invariant section, otherwise people would be able to change/twist your words and turn it into something completely different. That is the whole purpose of these sections, if they were not invariant, it wouldn't make sense at all. So far I haven't seen abuse of this option (i.e. manual with many invariant sections, representing opinions of many authors), simply because evil people don't write free documentation and people who write free documentation prefer to spend their time on something useful ;-) As explained on http://www.gnu.org/licenses/fdl-howto.html, the Invariant sections serve a special purpose, which is the case of the GNU Manifesto. Many users, including myself, consider it a more important part than the GNU Emacs Manual itself. How removing the document, that inspired thousands to join the efforts, will make Debian more free, I cannot tell... Please apply some common sense when judging. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, 01 Feb 2006 12:46:19 -0800, Thomas Bushnell BSG wrote: Which means that you are perhaps arguing that we should make the change to the DFSG which the amendment in question calls for. I agree with this (e.g. that the Invariant sections are DFSG-compliant): http://lists.debian.org/debian-vote/2006/01/msg00240.html Since you and the Secretary (probably others as well) are interpeting the DFSG in a different way, perhaps it is a good idea to clarify that particular sentence, but it is not an obstacle for the current GR. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
At Wed, 01 Feb 2006 13:09:38 -0800, Thomas Bushnell BSG wrote: Yavor Doganov [EMAIL PROTECTED] writes: On Wed, 01 Feb 2006 12:46:19 -0800, Thomas Bushnell BSG wrote: Which means that you are perhaps arguing that we should make the change to the DFSG which the amendment in question calls for. I agree with this (e.g. that the Invariant sections are DFSG-compliant): http://lists.debian.org/debian-vote/2006/01/msg00240.html Since you and the Secretary (probably others as well) are interpeting the DFSG in a different way, perhaps it is a good idea to clarify that particular sentence, but it is not an obstacle for the current GR. I cannot fathom what you are saying, because you have so carefully excised all the relevant context from the sentence of mine which you quote. Sorry about that, I thought I was doing a favour by shortening my reply. But it sound sas if you are agreeing that the amendment is a change to the DFSG, and so it is clear that it requires a 3:1 majority then. Right? No, I think that Anton Zinoviev's amendment to the GR does *not* require a change to the DFSG. But as it is clear that DDs interpret the DFSG differently, I agree that a clarification to the DFSG #3 may be proposed at a later stage. This will require 3:1 majority, of course. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, 01 Feb 2006 16:44:59 -0600, Manoj Srivastava wrote: On Wed, 01 Feb 2006 23:45:42 +0200, Yavor Doganov [EMAIL PROTECTED] said: No, I think that Anton Zinoviev's amendment to the GR does *not* require a change to the DFSG. But as it is clear that DDs interpret the DFSG differently, I agree that a clarification to the DFSG #3 may be proposed at a later stage. This will require 3:1 majority, of course. This is a procedural nightmare. What happens if we do split things and Anton's proposal asses, we issue a statement, and the DFSG amendment fails? We'll have a contradiction between a position statement and the DFSG, which is bad. Why? If Anton's proposal passes, there won't be a contradiction since it is compliant with the present DFSG. It is valid in both cases. Your reading, I believe, is: | Everything must be modifiable Others think that | Everything, which is reasonable to be modified, must be modifiable Things that are unreasonable to be modified for me are license texts and personal opinions (or rants), which can only be copied verbatim. It is a matter of interpretation. There is contradiction if Anthony's (or Adeodato's) proposal passes. Since Debian is tolerating and distributing non-free software, many people will ask themselves how the Debian Project is questioning the freeness of the GFDL, a license acknowledged as free in the community. It is not a contradiction, it's a hypocrisy. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
