Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: >For the jessie release, all software that currently supports being run >under sysvinit should continue to support sysvinit unless there is no >technically feasible way to do so. I believe "currently" needs to be clarified - are you talking about the current state of jessie, of wheezy, or something else? Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017093813.ga13...@raptor.chemicalconnection.dyndns.org
Re: call for votes on code of conduct GR
Hi, On Sun, Apr 06, 2014 at 02:23:39PM +0200, Wouter Verhelst wrote: > I'd like to call for votes on the code of conduct GR. Just a question - the CoC we are voting on is the one from https://lists.debian.org/debian-vote/2014/02/msg2.html or which one is it? Were any of the numerous objections and comments since then taken into account at all? Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140417225718.gc19...@raptor.chemicalconnection.dyndns.org
Re: Ian Jackson, could you fork Debian? (was: RE: git is slavery! (Re: Proposal - preserve freedom of choice of init systems (Why won't emails go through to the list?)
Hi Arnold, On Mon, Mar 03, 2014 at 07:33:21AM -0800, Arnold Bird wrote: > What this > discussion proves is that debian needs to be forked.The > systemd/gnome/redhat camp constantly derideds the idea that Linux is > about freedom and choice.(I've been around for awhile, freedom and choice > usedto be the bylines of linux fans). They mock anyone'salternative > and more traditional opinion.They are the new kids on the block and > know what isbest for everyone.We are old and about to be shoved out > the door.(And rightly so, lol rotflmao and so on)They have > achieved a victory and are standing firm.Furthermore they constantly show > us where the door is.They beckon us to go through it. It seems to be > ouronly option. Debian is ours nolonger.Debian is now > systemd/gnome3/so-on-and-so-on into madness.Ian Jackson, could you > fork Debian?There could be a new distribution that caters to > choice.Perhaps even the founder of debian Ian Murdok wouldbecome > interested again.You have the skills to do so, you have been > withdebian from almost the begining. Those junior to younow give you > opinions no respect: they have madeup their minds and will not > countenance dissent.However, many other debian devs do respect > you,and your pro-choice position on Linux and debian,they would > likely follow you to create a new distroout of the ashes of the old > (Ashes from a rocketignition flying straight into the heart of the > Newcenter of the linux system)More specifically, Could there be a > GR to fork debianso that all debian devs will be alerted to this > situationand with that knowlege could choose to leave the antichoice > official debain for the more traditionalnew fork of debian, and could you > lead that GR and the fork. Free e-mail, simple, > clean and easy to use. Visit CosmicEmail.com for your instant free > account. Please keep in mind that HTML posting are not welcome on Debian lists. Check out the docuementation of your email client on how to send plain text. If you need help on how to configure your email client accordingly, please ask on debian-user in case they can read what you write and are able to answer. Otherwise, Debian is maybe just not the right distro for you. Best regards, Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140303154521.gb26...@raptor.chemicalconnection.dyndns.org
Re: Proposal - preserve freedom of choice of init systems
Hi, On Sat, Mar 01, 2014 at 11:17:12AM +, Neil McGovern wrote: > I'm very wary about passing resolutions which require work from future > persons unidentified. Presumeably it would need a person who is a) keen > on the desktop system in question and also b) keen on a particular init > system which isn't supported by the desktop by default. > > I'm not entirely sure that this person exists, or would be able to > essentially maintain that support long term, this would leave the burden > on the maintainer to carry something they don't care about. I assumed this person would be Matthew. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302133622.gg2...@raptor.chemicalconnection.dyndns.org
Re: planet.debian.org is RC buggy (?)
On Sat, Mar 27, 2010 at 06:57:41PM +0100, Frank Lin PIAT wrote: > May be some content could be moved to collaborative media, bts, etc > May be some "I am doing something" post could be turned into a news > May be that allowing comments should be a best practice "A corporate blog is just like a personal blog, except you don't get to use the word 'motherfucker'" -- Mark Pilgrim Similarly, a project's planet is just an aggregation of personal blogs, so they might use 'motherfucker' sometimes. If you think some content should be moved, address the relevant people (as zack mentioned). Whether or not people should allow comments is out of scope for planet, as-in, it is the personal preference of the respective Debian contributor. The proper fix would be to make the other Debian announce channels more attractive to developers, so that they do not want or have to resort to their blogs for announcements. Or maybe just point them to them, if those channels have indeed improved and we just need to convince people that this is the case. Michael -- 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/20100328001723.gi5...@nighthawk.chemicalconnection.dyndns.org
Re: Question to all Candidates: 2IC
On Fri, Mar 12, 2010 at 03:47:53PM +0100, Stefano Zacchiroli wrote: > In fact, if you think about it, the proposal of a DPL board / 2IC just > gives a formal status to something that should be normal, > i.e. interaction among DPL and people knowledgeable/competent on > specific topics/tasks. FWIW, I think a 2IC is much more effective for outside-leaning communication, i.e. filtering and/or answering leader@ mail (which apparently can be overwhelming) and such, not for communication with other project members or teams. Michael -- 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/20100312161025.ga24...@nighthawk.chemicalconnection.dyndns.org
Re: Bits from the release team and request for discussion
On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote: > Any thoughts? We could have such a vote over and done in about two > weeks, with the DPL's consent, and it'd seem a lot more inclusive and > less cabal-tastic than how things seem to be working atm... I think it is a bad idea, given that the release team seems to be listening to the project and revising their freeze schedule ideas. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process
On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote: > I'd also like to complain about the title text of the initial GR. It is > clearly manipulative, as it pretends to be merely describing the proposed > changes when in fact it is asserting an opinion. I hope the Secretary > will fix this. Hear, hear. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 08:22:58AM +0100, Robert Millan wrote: > You're the Secretary. You're supposed to give answers, not speculation. If > the ballot was ambigous, or confusing, it is YOUR responsibility. It has to be said that at least I am taking YOU personally responsable for a lot of why the ballot was ambigous as well, not least to the fact you named your proposal "Reaffirm the Social Contract", i.e. SC-trolling the rest of the project not in line with your opinion. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:44:25PM +0100, Josselin Mouette wrote: > Le mardi 23 décembre 2008 à 15:27 +0100, Michael Banck a écrit : > > > How about ???Software that is not executed on the host CPU??? ? That can > > > include e.g. non-free documentation, which clearly doesn???t belong in the > > > same place than nVidia binary drivers. > > > > While I think that non-dfsg-free documentation also merits to be split > > off from non-free, I don't think we should generalize this too much; > > e.g. clearly non-free copyrighted artwork or data should probably stay > > in non-free. > > Why? In essence, it is very similar to a firmware. It can also be > necessary (e.g. for game data) to make free software work, in a similar > way to the kernel with firmware. While that might be true technically, I don't think you can compare it from a social POV. Firmware is (when it applies) (mostly) essential to make your hardware run; documentation is important to understand and learn code and/or important system programs. Game data is not essential at all in the wider scope of a Free Operating System. > And I know that installing it is not going to blow away my system with > untrusted code. That's certainly a requirement, but not the only one I would like to have. In the end, I guess that most games depend on their game data, so the question boils down to whether this new section is "part of Debian" and thus whether a depends-on relationship on this new section is allowed or not. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:24:25PM +0100, Josselin Mouette wrote: > Le mardi 23 décembre 2008 à 13:07 +0100, Kurt Roeckx a écrit : > > The idea is to create a new section that contains files like > > firmware images and FPGA data that gets written to the hardware > > to make it fully functional. It is not meant for drivers that run > > on the host CPU. > > There is no reason to restrict this area to firmware images. > > How about ???Software that is not executed on the host CPU??? ? That can > include e.g. non-free documentation, which clearly doesn???t belong in the > same place than nVidia binary drivers. While I think that non-dfsg-free documentation also merits to be split off from non-free, I don't think we should generalize this too much; e.g. clearly non-free copyrighted artwork or data should probably stay in non-free. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: I hereby resign as secretary
On Thu, Dec 18, 2008 at 11:00:26PM +0100, Pierre Habouzit wrote: > > On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote: > > > As to the people who emailed me that they are putting together a > > > petition for the DAM to have me removed from the project, I hear you > > > too. I am going to spend the next few days evaluating how important the > > > project is to me, and whether I should save you the bother or an > > > expulsion process. > Huh, who talked about expelling Manoj !? Doesn't the above paragraph imply that? Michael, skipping the expel vs. expulse joke -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dwindling popularity
On Wed, Nov 19, 2008 at 04:35:04AM -0500, Michael Pobega wrote: > Anyway, we all know Ubuntu is just a crappy overlay on top of Sid, > bundled with proprietary blobs. Please keep your opinion on off-topic matters to yourself or voice them elsewhere. This list is bad enough to read as is right now, adding some good old slashdot distro flamewar to it won't make things better. thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dwindling popularity
Hi Ean, On Tue, Nov 18, 2008 at 05:35:20PM -0600, Ean Schuessler wrote: [...] Why the heck did you post this to -vote? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18, 2008 at 12:12:18PM -0600, Manoj Srivastava wrote: > On Tue, Nov 18 2008, Luk Claes wrote: > > > > Note that firmware is no program AFAICS... > > I do not think I agree. I think it is indeed a software program, > and I am not alone: > ,[ http://en.wikipedia.org/wiki/Computer_software ] > | Firmware which is software programmed(sic) resident to electrically > | programmable memory devices on board mainboards or other types of > | integrated hardware carriers It's "software", which is "programmed [...] (in)to [flash]", as I read it. I.e. the "programmed" up there pertains to the way the firmware is put onto the device, not what the firmware is in itself. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 08:44:45AM -0600, Ean Schuessler wrote: > A desktop with a "host cpu" and components with "firmware" is directly > analogous to a small cluster of computers. There is no *real* > difference between a host programming its RAID controller and a > cluster manager handing a blade its boot image. Sure there is, the RAID controller doesn't run Debian GNU/Linux; it just runs some uploaded microcode. Your blade will run Debian GNU/Linux (or whatever else you hand it to). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
On Mon, Nov 10, 2008 at 04:05:42PM -0600, Manoj Srivastava wrote: > The difference being that the former is being resolved with a > license change, and the latter is being resolved with code changes, and > will require adjustments to the infrastructure. That makes the former > a faster process. Uhm, Sun passed it on to their lawyers. I am less optimistic than you that it will be solved faster than the latter. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, Mar 10, 2008 at 09:57:15AM -0500, Manoj Srivastava wrote: > On Mon, 10 Mar 2008 13:48:28 +1100, Anthony Towns > <[EMAIL PROTECTED]> said: > > >3. When there are 8 members, the Project Leader may appoint any > > Developer to the Technical Committee replacing the longest > > serving current member, provided there have not already been 2 > > or more appointments to the Technical Committee during the > > current Leader's term. > > This is a bad idea. The length of term of service is a bad > indicator of utility of the member to Debian. Consider this scenario: > what if the longest serving members are the most active members of the > team, and the newer members being mostly MIA, you have just degraded > the tech ctte's utility. > > The grounds for removing people should be whether they are > present at all (which is the criteria used when we last shed people > from the ctte), or some measure of the quality of contribution. > > Most of the arguments posited against term limits apply here; > because this is just term limits in disguise (with a term limit of 4 > years). AJ explicitely commented that it would be possible for the DPL to remove/reappoint somebody at one go, essentially making them the youngest standing member on the TC and recognizing their utility. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question to the Debian community ...
On Fri, May 11, 2007 at 12:32:15PM +0200, Sven Luther wrote: > On Fri, May 11, 2007 at 12:18:33PM +0200, Michael Banck wrote: > > On Fri, May 11, 2007 at 11:10:14AM +0100, MJ Ray wrote: > > > Because I would seek one that mandates listmasters banning Sven Luther > > > >from all lists, and DAMs expelling for ban-evasion. I realise that > > > there is a way for it to continue after that, but hopefully it wouldn't. > > > > Did you (or somebody else) ask the listmasters to have Sven banned from > > the lists he disturbs? > > The list master have been asked to censor me on the debian lists > already. I suppose their decision was to not do it, but they did ask me > to stay absent from the lists, which i mostly did these past weeks, > until two posts i made two weeks ago or so retrigered this matter. So in other words you violated their request? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question to the Debian community ...
On Fri, May 11, 2007 at 11:10:14AM +0100, MJ Ray wrote: > Because I would seek one that mandates listmasters banning Sven Luther > >from all lists, and DAMs expelling for ban-evasion. I realise that > there is a way for it to continue after that, but hopefully it wouldn't. Did you (or somebody else) ask the listmasters to have Sven banned from the lists he disturbs? If they decline, you can still initiate a GR, I don't see the point in one before you (or somebody else) tried the obvious route first. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to all candidates: Release importance, release blockers, release quality
On Mon, Mar 05, 2007 at 02:52:32PM +0100, Josselin Mouette wrote: > Le lundi 05 mars 2007 à 14:52 +0200, Kalle Kivimaa a écrit : > > Criticise, yes. Mock, no. > > If I understand your opinion, Greg Folkert's way of criticising people > is acceptable, while Sam's is not. Is that correct? Greg isn't a DD, just a user who vented on the wrong list, AFAIK. Plus, I was sort of on the receiving end of his mockery, so I'm biased, but I didn't like it at all either. (I didn't like the mocking of other (some of them quite well-known) DDs in that thread either, but those were more mocking Gnome anymously than the Debian Gnome-team or the Gnome upstream developers in particular) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [GR] DD should be allowed to perform binary-only uploads
On Fri, Feb 09, 2007 at 04:33:14PM +0100, Pierre Habouzit wrote: > * security (I _really_ think it's nonsense, as it's not less secure > than the usual DD's uploads, which I tried to prove) ; Maybe "security" in this context means "build can be reproduced by our official buildd network and we are therefore sure our security team can issue security updates for this package using said network". Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
On Thu, Sep 21, 2006 at 12:05:39AM +0200, Denis Barbier wrote: > Again, the question is: is this organisation sufficiently "outside" > of Debian when the DPL is intimately involved. In my opinion, the > answer is obviously no, meaning that this quarantine will not work > and as a result may badly harm the project. By recalling the > Project Leader, we ensure that there is no confusion between both > projects, give the Dunc project a better chance of success, and > preserve Debian in case of failure. Uhm, did you ask any of the dunc-tank people whether they would like to carry on after your GR passed? I don't see that as a given. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Hrm, maybe this thread should move elsewhere. On Sat, Aug 26, 2006 at 05:35:00AM -0500, Peter Samuelson wrote: > > [Eduard Bloch] > > > . Ship a separate non-free CD. > > > > >* Does bad things to our CD/DVD disk space requirements. > > > > How? Basedebs take about 40MB. I think there is a plenty of space on the > > non-free CD for those, together with udebs and boot images. > > Because it implies that we provide 2 copies each of the business card, > netinst, full CD number 1, and full DVD number 1, for every > architecture. We could concentrate on building just e.g. the netinst ISO with broken out firmware, only duplicating things there. People could still download the full regular CD1 if they need it and use apt-cdrom after a netinst-install. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:30:23AM +0200, Sven Luther wrote: > he doesn't use the leader@ address even on issues related to his DPL role, as > i well know, so this is no guarantee. AFAICT, he always signs those mails with DPL in the signature. Plus, at least in this thread, he did use [EMAIL PROTECTED] Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
I believe this should be voted on and second the below proposal. On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: > The application of DFSG#2 to firmware and other data > > > The Debian Project recognizes that access to source code for a work of > software is very important for software freedom, but at the same time > "source" is often not a well-defined concept for works other than those > traditionally considered "programs". The most commonly cited definition is > that found in version 2 of the GNU GPL, "the preferred form of the work for > making modifications to it," but for non-program works, it is not always > clear that requiring this "source" as a precondition of inclusion in main > is in the best interest of our users or advances the cause of Free Software: > > - The author's preferred form for modification may require non-free tools > in order to be converted into its final "binary" form; e.g., some > device firmware, videos, and graphics. > - The preferred form for modification may be orders of magnitude larger > than the final "binary" form, resulting in prohibitive mirror space > requirements out of proportion to the benefits of making this source > universally available; e.g., some videos. > - The "binary" and "source" forms of a work may be interconvertible with no > data loss, and each may be the preferred form for modification by > different users with different tools at their disposal; e.g., some > fonts. > > While the Debian Free Software Guidelines assert that source code is a > paramount requirement for programs, they do not state that this is the case > for non-program works, which permits us to consider whether one of the above > points justifies a pragmatic concession to the larger context within which > Free Software operates. > > THE DEBIAN PROJECT therefore, > > 1. reaffirms its dedication to providing a 100% free system to our > users according to our Social Contract and the DFSG; and > > 2. encourages authors of all works to make those works available not > only under licenses that permit modification, but also in forms that make > such modifications practical; and > > 3. supports the decision of the Release Team to require works such as > images, video, and fonts to be licensed in compliance with the DFSG without > requiring source code for these works under DFSG #2; and > > 4. determines that for the purposes of DFSG #2, device firmware > shall also not be considered a program. > > == signature.asc Description: Digital signature
Re: Question for the DPL Teams
Hi, On Wed, Mar 15, 2006 at 05:22:52PM +1000, Anthony Towns wrote: > (1) Did you join the (proposed) DPL team as an endorsement of the > candidate or the team concept, or because it seemed the best opportunity > for you to assist Debian in the event that candidate was elected? I think Jeroen has presented a very good platform and I agree with his points. However, I have not finalized my ballot yet and I think most other non-joke candidates would be doing a good job as DPL as well. As for a DPL team, I think the team concept has definetely some merit which should be further explored, most other Free Software projects do not have one particular (non-technical) leader either but rather share the burdon of the more boring non-technical day to day tasks. I will try to assist Debian wherever possible, and being asked to join Jeroen's team seemed to me like a very good opportunity to do so. > (2) Should one of the other candidates be elected, do you expect to > contribute as much as you would if your DPL team won? If not, what > contributions do you feel you wouldn't be in a position to make? What, > if anything, could the other DPL candidates or the project in general > do to encourage your contribution? Positively contributing to the internal communications accessible only to the DPL (and his team, possibly) would be impossible of course. I will continue trying to contribute to Debian in any way possible (and especially to raise the S/N ratio on IRC and lists) given time restraints and would of course consider accepting whatever other means of contributions another DPL would propose. > (3) Will you all be going to debconf6 in Mexico, and can we therefore > expect you to flip a coin to see who gets Steve and Raphael for an > exciting game of five-a-side football or ultimate frisbee? Having missed the last two debconfs, I will hopefully be able to come this year. I will need to sort out vacation and travel first, though. I need to do more sports anyway, so either discipline is fine with me. > (4) When asked about why things didn't work last year, both Andreas [0] > and Jeroen [1] seem to have mostly pointed to Branden not doing things > that, if elected, they will. What, if anything, will you do this year > as a member of a new DPL team to provide the new DPL with more support > than Branden had? An important part of both team strategies appears to be sharing the workload of DPL mail, or at least keeping the team in the loop all the time. I think this will make for a better interaction between the DPL and his team and will provide better support in both directions. > (5) How would you rate the importance of your participation on the DPL > team compared to your other roles in Debian? That role would be important, but not much more or less so than my other roles from my point of view. cheers, Michael -- trivial == does not require soldering iron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggest ballot-by-section of the FDL position GR
> I'm thinking of something like > http://people.debian.org/~mjr/gr-fdl.txt (24k, only based on originals) Uhm, this is a joke, right? Michael -- ban me ban me ban me 20:58 -!- apprentice has quit [Excess Flood] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Sun, Jan 15, 2006 at 11:30:55PM +0100, Bill Allombert wrote: > This requirement is extremly costly for anyone attempting to > distribute Sarge either as a mirror or as an ISO image. Can you point to testimony of people actually hindered by this? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Thu, Jan 12, 2006 at 08:53:04PM +0100, Roland Mas wrote: > Having invariant sections (or any other non-free stuff) in main could > be seen as a betrayal of the people who chose the license. This is not about invariant sections. This is about the other bugs in the GFDL the FSF has not fixed (yet?) and ignoring them for one more release. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
On Thu, Jan 05, 2006 at 06:15:18PM -0500, Alexander (Sasha) Wait wrote: > It's really sad to see blood boil over these licenses. Since I am > talking to people at FSF & CC regularly, I would be more than happy to > bring Debian concerns to both groups in a, hopefuly, productive > fashion.If there's a desire for that, just get in touch with me. Thanks for your offer. Mako Hill and Don Armstrong have been talking to the FSF in that matter for some time now, I suggest you contact them first to discuss whether this is likely to be of good use. cheers, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Wed, Mar 09, 2005 at 03:15:11PM +0100, martin f krafft wrote: > That said, there is no way to ban flamewars since they are sort of > part of the nature of a project like this. I do not subscribe to this. Flamewars are *not* a necessary evil (or even a good thing), I believe we would be at least as productive without them. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My platform
On Wed, Mar 09, 2005 at 12:54:47AM -0600, Ean Schuessler wrote: > Oh. Ooops. I'm not running for DPL am I? Uh, will one of you guys add > "database of free software capable equipment" to your platform? I'll help > write it. Just do it[tm]. You don't need a platform, vote or anything for that. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Red-tops, was: Clarification about krooger's platform
On Sat, Mar 05, 2005 at 01:28:43PM +, MJ Ray wrote: > Henning Makholm <[EMAIL PROTECTED]> wrote: > > The list shows everybody who has more than 1000 points. You are not > > among them (except if my DWN-parsing script is broken), but MJ himself > > currently has 2661 points and a ranking of #30. > > Interesting, but missing any measure of whether I'm being > kissed or kicked. Can you cross-reference the stories? The cabal recognizes its peers. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: General Resolution: Force AMD64 into Sarge
On Tue, Jul 20, 2004 at 04:39:57PM -0500, John Goerzen wrote: > On Tue, Jul 20, 2004 at 10:20:40PM +0100, Martin Michlmayr - Debian Project Leader > wrote: > > I am pursuing it. I posted the three items which are currently > > stopping the amd64 port to be added to the archive, and I'm in active > > contact with ftpmaster to move the new architecture and common > > architecture proposals forward; I've also asked someone to find out > > what the technical questions are and to get them posted. > > I've also asked a member of the amd64 porting team today to clarify > > what their thoughts are about an inclusion in sarge. It's quite > > interesting to note that there is no agreement at all among the amd64 > > porters whether the port should (in their opinion) be included in > > sarge or not. Ah, nice to read this. Thanks for saving the day. [...] > However, that issue is orthogonal to inclusion in the archive in sid, > which is something that we also can't seem to get done. Yep. But can't we all agree that this GR is just a waste of time and ditch it? How many people will jump and say: "Woot! Sarge will be delayed again coz it looks like amd64 is getting in! In order to celebrate, I'll be fixing a couple of RC bugs today!" Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Sat, Jul 17, 2004 at 05:41:25PM -0400, Sam Hartman wrote: > It is not abuse of the process for the project as a whole to decide > that it disagrees with a decision that some part of the project has > made. Except there is no decision any part of the project made, contrary to popular believe. Some parts of the project just want to have another part of it work faster. At least, that's my take on the situation :) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 09:27:01PM -0400, Raul Miller wrote: > On Thu, Jul 15, 2004 at 09:22:01PM -0400, Stephen Frost wrote: > > I fail to understand how you still don't get it. multiarch *is* > > 64/32bit userland. Is there something you don't understand about that? > What I really want is LSB compliant 64 bit user land and LSB compliant > 32 bit userland. Well, you get what you pay for. Or you get involved and help out. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 09:24:26PM -0400, Raul Miller wrote: > On Thu, Jul 15, 2004 at 09:09:46PM -0400, Stephen Frost wrote: > > Those funcs may be available through ia32-libs... I was actually > > wondering more about specific programs. > > The no-cost linux downloads from kx.com and jsoftware.com are the ones > I'm most concerned about (in that order). Honestly, I fail to see what this has to do with Debian development or voting. You might want to subscribe to debian-amd64 and raise your concerns there. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A FIFO DAM, was: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 02:26:28AM +0100, MJ Ray wrote: > >[...] or could see someone in the queue whom he knows to be > >competent and valuable and would want to process first. > > Is queue-jumping desirable? It really sucks to see people (with > questionable philosophies expressed on lists) getting through NM in 10 > days while you're dangling there for months without being able to > detect anyone doing anything about you. Feel free to subscribe to -newmaint (it's quite low-traffic) and comment on the AM reports of those applicants if you think they are not ready. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 03:26:13PM -0700, Thomas Bushnell, BSG wrote: > 1) Should amd64 support biarch as an interim before multiarch support > is in place? > 2) What's the best way to support the change in library directory > that is involved here? This second one is the only open question, and I agree it is off-topic for -vote. I guess constructive feedback on the multiarch proposal (the URL of which has been cited in this thread) is welcome on -devel. > 3) Should the existing pure64 be added to sid? > 4) Should the existing pure64 be added to sarge? This last one could be considered on-topic for -vote in the context of this unholy GR, but I rather think it's abuse of it, as we have a release team for this kind of issue. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 06:45:59PM -0400, Raul Miller wrote: > If so, which part of "I'm talking about 64/32 bit userland -- which > is something other distributions already offer." or "That's not vapor" > are you having problems with? The part about 'other distributions' and the fact that this is a Debian- related mailing-list. If you want to install some other distribution with 32/64 bit userland, fine. If you want to have multiarch in Debian be more than vapour, well: "Put up or shut up" -- GangStarr. Glad to clear up the confusion, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 04:43:39PM -0400, Raul Miller wrote: > > Fact of life: multiarch is vapour and will not be usable for quite a > > while. > > I'm talking about 64/32 bit userland -- which is something other > distributions already offer. > > That's not vapor. I haven't seen you post one mail to debian-amd64 or otherwise do something to help multiarch come along, so I wonder how you make that claim. Debian is just what the people who do the work decide to do. Multiarch is just vapour so far (granted, it's spiced up with all kinds of nice smelling perfums, but still). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 03:54:29PM +0200, Robert Millan wrote: > Really nice, but I already knew that. Now can you tell me what > prevents FIFO processing? Are you processing all of your bugs in a FIFO fashion? I don't. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 08:17:55AM -0400, Stephen Frost wrote: > * Raul Miller ([EMAIL PROTECTED]) wrote: > > In other words, that the only thing we're talking about is distribution > > of binaries built from sarge sources? > > Make it a release architecture which will move those bugs to RC and give > us a BSP weekend. Did the amd64 team even ask the release team whether NMUing for amd64 support is alright in case maintainers are inactive? I don't see why we absolutely need to have amd64 on ftp.d.o in order to achieve this. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 09:19:55AM +0200, Sven Luther wrote:
> Well, no, but i believe that new kernel release handling deserve it too,
> and not this almost a month if not more wait from upload to NEW queue
> handling we are currently seing. And i have sent a non-flame mail to
> ftp-masters, proposing help on handling of this, like overviewing the
> changes between versions and proposing a resume of it, to help the
> ftp-masters job, but to this date, i hardly have seen a reply.
Sven, I guess everybody would be much more sympathetic to your cause if
you would not use every remotely connected opportunity to argue about
it. ("Oh! Somebody said ftp-master! Better jump in there!")
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Wed, Jul 14, 2004 at 12:28:28PM +0200, Sven Luther wrote: > On Wed, Jul 14, 2004 at 12:02:03PM +0200, Michael Banck wrote: > > On Wed, Jul 14, 2004 at 08:23:44AM +0200, Ingo Juergensmann wrote: > > > > I strongly suspect there are many others in Debian who also have no > > > > problems communicating with James. > > > > > And there are many others that actually have those problems and I don't > > > think it's their fault, when James can't differ personal dislikes and duties > > > of his job as being in a role position. > > > > Funnily enough, I was under the impression that mostly some other > > ftp-master than James is working on the mirroring rework, which > > (rightfully) should be completed before we add other ports. > > Well, the real problem is one of information and transparence. Yeah, cvs.debian.org should be made public ASAP. Oh, wait... Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Wed, Jul 14, 2004 at 08:23:44AM +0200, Ingo Juergensmann wrote: > > I strongly suspect there are many others in Debian who also have no > > problems communicating with James. > And there are many others that actually have those problems and I don't > think it's their fault, when James can't differ personal dislikes and duties > of his job as being in a role position. Funnily enough, I was under the impression that mostly some other ftp-master than James is working on the mirroring rework, which (rightfully) should be completed before we add other ports. Ah, but James is the catchall-address for problems in Debian, anyway. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Tue, Jul 13, 2004 at 07:12:19PM -0500, Chris Cheney wrote: > Of the people that I have heard comment about James he seems to be > quite easy to talk to if you have met him in person but otherwise is > nearly impossible to even get him to respond at all. I am pretty sure > you fall into the first category since you live near him... Out of personal experience, I can say that it was easier talking to him *before* having met him. Afterwards, he was just calling me names... Just to give some data to sample ;) Michael -- Anybody who writes functionality they think should be mainstream in Linux and doesn't make their command-line tool a thin wrapper over a library a) is a moron b) should be shot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Statement that Sarge will follow Woody requirement for main.
On Wed, May 26, 2004 at 10:12:59AM -0400, Daniel Jacobowitz wrote: > On Wed, May 26, 2004 at 09:24:19AM -0400, Raul Miller wrote: > > The technical committee has yet to issue any official opinion. > > In that case, I think it's premature to be this focused on the GRs > until that has happened. I at least would prefer to avoid a GR if the > Technical Committee's opinion permits. With all due respect, but waiting for the tech-ctte in order to *speed up* the release of Sarge looks like a flakey plan to me, given the committee's track record in the last couple of years. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ready to vote on 2004-003?
On Fri, May 21, 2004 at 05:25:43PM +1000, Anthony Towns wrote: > Three quarters of the developers interested enough to vote on the issue > told me (and the rest of the project) what to do once; when I followed > their instructions to the best of my ability, they told me -- fairly > unanimously -- it was a stupid thing to do, or at least that I was a > stupid person for doing it. I've no idea why you think I'd repeat the same > process that's already failed rather catastrophically from my perspective, > least of all after I've told you, repeatedly, that I will not. Well, fair enough then. So that basically means we are waiting for the -ctte, right? Do we get a release update on the technical matters at least? I've no idea what's going on WRT sarge at the moment. If the -ctte is the only thing we are waiting for, what's the status for the rest of Sarge? thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ready to vote on 2004-003?
On Wed, May 19, 2004 at 05:29:30PM -0400, Raul Miller wrote: > On Wed, May 19, 2004 at 02:15:57PM -0700, Thomas Bushnell, BSG wrote: > > I thought carefully about the last resolution, and assumed that it was > > blindingly obvious that of course changes would get phased in over a > > period of tim. > > I didn't see anything that made this obvious -- can you explain to me > the basis for this assumption? "common sense". Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed ballot for the GR: Deciding on the effect of GR 2004_003
On Sun, May 16, 2004 at 10:32:50PM -0500, Manoj Srivastava wrote: > It is belabouring the obvious. How can anyone think that 40 > characters is the full text of the proposal? > > And are there really debian developers who do not understand > this? Yeah, let's just try it out. Three's a charm anyway, right? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Thu, May 06, 2004 at 03:01:29AM -0400, Nathanael Nerode wrote: > Michael Banck wrote: > > In contrast, having the possibilty to modify $APPLICATION's stock > > 'File->Open' icon in its native form, i.e. gimp layers or whatever seems > > to be of less importance by several orders of magnitude, as long as we > > can *somehow* fix it by e.g. replacing it with another one, or fixing it > > by gimping it up or so. I mean, very few of us are graphic designers or > > so. > Well, I suppose the graphic designers among Debian should comment. :-) How many are there? How often do you have to modify graphics when packaging stuff? > > Same goes with fonts. > Likewise. You'd find even less people who'd design fonts. And I don't know how many would just modify a given font or rather create a new one from scratch. > > Even less so with "You've got mail" sounds or > > so, what's the use in having the Cubase samples for that or something? > > We could still edit the waveform somehow, even if that would be a bit > > more tedious > Ow. A lot more tedious. Sure. But how often do you have to modify sounds when packaging stuff? Compared to modifying Makefiles or C source code? I agree that programs shipping sounds for the sake of *creating* music (like samples for a tracker) should be capital F free so that people making music can use them in a useful way. But I don't believe the same holds for a 'You've got mail' sound from e.g. Evolution. Perhaps the crucial part is to look whether the file in question can be reasonably/typically used to create new art/software as opposed to just accompain a bigger package. Source code is fundamentally different, because that's in the scope of our core business. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Thu, May 06, 2004 at 03:01:29AM -0400, Nathanael Nerode wrote: > Michael Banck wrote: > > In contrast, having the possibilty to modify $APPLICATION's stock > > 'File->Open' icon in its native form, i.e. gimp layers or whatever seems > > to be of less importance by several orders of magnitude, as long as we > > can *somehow* fix it by e.g. replacing it with another one, or fixing it > > by gimping it up or so. I mean, very few of us are graphic designers or > > so. > Well, I suppose the graphic designers among Debian should comment. :-) How many are there? How often do you have to modify graphics when packaging stuff? > > Same goes with fonts. > Likewise. You'd find even less people who'd design fonts. And I don't know how many would just modify a given font or rather create a new one from scratch. > > Even less so with "You've got mail" sounds or > > so, what's the use in having the Cubase samples for that or something? > > We could still edit the waveform somehow, even if that would be a bit > > more tedious > Ow. A lot more tedious. Sure. But how often do you have to modify sounds when packaging stuff? Compared to modifying Makefiles or C source code? I agree that programs shipping sounds for the sake of *creating* music (like samples for a tracker) should be capital F free so that people making music can use them in a useful way. But I don't believe the same holds for a 'You've got mail' sound from e.g. Evolution. Perhaps the crucial part is to look whether the file in question can be reasonably/typically used to create new art/software as opposed to just accompain a bigger package. Source code is fundamentally different, because that's in the scope of our core business. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to the Constitution: Add a new foundation document
On Mon, May 03, 2004 at 08:49:08AM -0500, Manoj Srivastava wrote: > On 03 May 2004 00:26:49 -0700, Thomas Bushnell, BSG <[EMAIL PROTECTED]> said: > > > I think this draft is very good, and I am most pleased to second it. > > So I second this proposed foundation document. > > Unfortunately, I can't verify the signature on this email. Is > it just a failing on my end? I could verify the sigs of other emails > in this list (from Aaron M. Ucko, for example) Just for the record, I was able to: gpg: Signature made Mon May 3 09:26:43 2004 CEST using DSA key ID BE9F70EA gpg: Good signature from "Thomas Bushnell, BSG <[EMAIL PROTECTED]>" Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Amendment to the Constitution: Add a new foundation document
On Mon, May 03, 2004 at 08:49:08AM -0500, Manoj Srivastava wrote: > On 03 May 2004 00:26:49 -0700, Thomas Bushnell, BSG <[EMAIL PROTECTED]> said: > > > I think this draft is very good, and I am most pleased to second it. > > So I second this proposed foundation document. > > Unfortunately, I can't verify the signature on this email. Is > it just a failing on my end? I could verify the sigs of other emails > in this list (from Aaron M. Ucko, for example) Just for the record, I was able to: gpg: Signature made Mon May 3 09:26:43 2004 CEST using DSA key ID BE9F70EA gpg: Good signature from "Thomas Bushnell, BSG <[EMAIL PROTECTED]>" Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to the Constitution: Add a new foundation document
On Sun, May 02, 2004 at 01:15:33PM -0500, Manoj Srivastava wrote: > On consultation with the other sponsors, I have decided to > add a sunset clause to the proposed "Transition Guide", so that the > specific references to Sarge are ex-purged after it is released. Great. I've just got one question: Have you considered merging the essence of this document into the constitution? This would save us from adding another foundation document, but it might enlarge the constitution somewhat depending on how terse we could formulate this. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Amendment to the Constitution: Add a new foundation document
On Sun, May 02, 2004 at 01:15:33PM -0500, Manoj Srivastava wrote: > On consultation with the other sponsors, I have decided to > add a sunset clause to the proposed "Transition Guide", so that the > specific references to Sarge are ex-purged after it is released. Great. I've just got one question: Have you considered merging the essence of this document into the constitution? This would save us from adding another foundation document, but it might enlarge the constitution somewhat depending on how terse we could formulate this. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to the Constitution: Add a new foundation document
On Fri, Apr 30, 2004 at 05:40:11PM -0400, Joey Hess wrote:
> "Manoj Srivastava <[EMAIL PROTECTED]>Organization:srivasta"@debian.org wrote:
> > There is precedence for this gap in ratifying a foundation and
> > implementing the dictats of that document; as Joey Hess reminded me:
>
> I think that this document needs some serious editing before it is
> suitable as any official statement from the Debian project, let alone a
> foundation document. In particular, note the use of "me" above; I
> noticed other minor problems while reading it but do not have time for a
> thurough edit.
>
> I prefer not to have my name in any foundation document of the Debian
> project, as it could have unforseen consequences later.
This was exactly my feeling when skimming over it. I heartily welcome
the addition of such a document, but it should be completely neutral and
self-contained.
Manoy wrote:
> We affirm that whenever a change in the Social Contract takes place,
> the activities required to provide ongoing and proactive support for
> versions of Debian that have already been released shall continue in
> the period where we are working towards compliance. This includes,
> but is not necessarily limited to, providing security updates, bug
> fixes, preparing for the release of the next (compliant) release,
> adopting new packages, and making point releases to refresh already
> released versions of Debian.
> In the specific case of the GR 2004_003, since that current release,
> code named "Sarge", is very close to release, and the previously
> released version is quite out of date, our commitment to our users
> dictates that the "Sarge" release should go on as planned, even while
> we are trying to reach compliance with the Social Contract. This
> exemption for "Sarge" applies to security releases, and point releases
> as well.
I'd like to have some clarification here: The last change of the SC was
relatively uncontroversial WRT application to past releases except as
proof-of-point ('so we have to remove woody from the archive, too, I
guess, huh?'), while the prime part of the argueing was about the
effects on the forthcoming release.
The first paragraph above mainly talks about past releases and then
mentions the currently work-on release in passing ('preparing for the
next release...') and the second paragraphs specifically mentions Sarge.
Now, I believe there should be a turn-over point where we say the we
freeze a release WRT the Social Contract, much like we freeze it for
policy changes. Otherwise the current situation might come up again,
i.e. a change in the SC very late in the release cycle results in
turmoil. On the other hand, if the SC is changed just after a release,
it is reasonable to assume that we will be able to implement the changes
until the next release, so having a general 'The currently developped
release shall not be affected by the change' is not necessary.
However, it is very hard to determine and carve in stone the 'point of
no return' for a release, especially as we are still experimenting with
the way we do releases. But I guess we could have the release manager
officially declare a point somewhere in the middle of the release cycle
which marks the change from 'developping randomly' to 'working towards
the release'. At this point, changes to the SC would only be applied to
the next stable release after the one worked on by the time. This
declaration could be accompanied by the policy freeze or whatever other
the devices the RM will have at his fingertips at that time.
This would make it more reliable for everybody to judge the implications
of the changes, and lift off the burden of decision after a vote off the
shoulders of the Release Manager.
What do you all think of this?
Michael
--
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html
Re: Amendment to the Constitution: Add a new foundation document [Typographical fixes]
On Fri, Apr 30, 2004 at 05:16:57PM -0500, Manoj Srivastava wrote: > In the specific case of General Resolution 2004_003, since that release > currently in preparation, code named "Sarge", is very close to release, > and the previously released version is quite out of date, our commitment > to our users dictates that the "Sarge" release should go on as planned - > even while we are in the process of reaching compliance with the new > Social Contract. This exemption for "Sarge" applies to security releases > and point releases as well. I'm very uneasy about adding specific text to foundation documents. Is your proposal meant as an addition to the GRs that want to exempt Sarge from the change to the SC? I really like your proposal in general but I believe it should be voted on *after* we exempted Sarge from the current SC, and be independant of it. Also, it should be stripped of all personal and only presently applicable texts, like the references to Raul, Joey and Sarge. regards, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Amendment to the Constitution: Add a new foundation document
On Fri, Apr 30, 2004 at 05:40:11PM -0400, Joey Hess wrote:
> "Manoj Srivastava <[EMAIL PROTECTED]>Organization:srivasta"@debian.org wrote:
> > There is precedence for this gap in ratifying a foundation and
> > implementing the dictats of that document; as Joey Hess reminded me:
>
> I think that this document needs some serious editing before it is
> suitable as any official statement from the Debian project, let alone a
> foundation document. In particular, note the use of "me" above; I
> noticed other minor problems while reading it but do not have time for a
> thurough edit.
>
> I prefer not to have my name in any foundation document of the Debian
> project, as it could have unforseen consequences later.
This was exactly my feeling when skimming over it. I heartily welcome
the addition of such a document, but it should be completely neutral and
self-contained.
Manoy wrote:
> We affirm that whenever a change in the Social Contract takes place,
> the activities required to provide ongoing and proactive support for
> versions of Debian that have already been released shall continue in
> the period where we are working towards compliance. This includes,
> but is not necessarily limited to, providing security updates, bug
> fixes, preparing for the release of the next (compliant) release,
> adopting new packages, and making point releases to refresh already
> released versions of Debian.
> In the specific case of the GR 2004_003, since that current release,
> code named "Sarge", is very close to release, and the previously
> released version is quite out of date, our commitment to our users
> dictates that the "Sarge" release should go on as planned, even while
> we are trying to reach compliance with the Social Contract. This
> exemption for "Sarge" applies to security releases, and point releases
> as well.
I'd like to have some clarification here: The last change of the SC was
relatively uncontroversial WRT application to past releases except as
proof-of-point ('so we have to remove woody from the archive, too, I
guess, huh?'), while the prime part of the argueing was about the
effects on the forthcoming release.
The first paragraph above mainly talks about past releases and then
mentions the currently work-on release in passing ('preparing for the
next release...') and the second paragraphs specifically mentions Sarge.
Now, I believe there should be a turn-over point where we say the we
freeze a release WRT the Social Contract, much like we freeze it for
policy changes. Otherwise the current situation might come up again,
i.e. a change in the SC very late in the release cycle results in
turmoil. On the other hand, if the SC is changed just after a release,
it is reasonable to assume that we will be able to implement the changes
until the next release, so having a general 'The currently developped
release shall not be affected by the change' is not necessary.
However, it is very hard to determine and carve in stone the 'point of
no return' for a release, especially as we are still experimenting with
the way we do releases. But I guess we could have the release manager
officially declare a point somewhere in the middle of the release cycle
which marks the change from 'developping randomly' to 'working towards
the release'. At this point, changes to the SC would only be applied to
the next stable release after the one worked on by the time. This
declaration could be accompanied by the policy freeze or whatever other
the devices the RM will have at his fingertips at that time.
This would make it more reliable for everybody to judge the implications
of the changes, and lift off the burden of decision after a vote off the
shoulders of the Release Manager.
What do you all think of this?
Michael
--
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to the Constitution: Add a new foundation document [Typographical fixes]
On Fri, Apr 30, 2004 at 05:16:57PM -0500, Manoj Srivastava wrote: > In the specific case of General Resolution 2004_003, since that release > currently in preparation, code named "Sarge", is very close to release, > and the previously released version is quite out of date, our commitment > to our users dictates that the "Sarge" release should go on as planned - > even while we are in the process of reaching compliance with the new > Social Contract. This exemption for "Sarge" applies to security releases > and point releases as well. I'm very uneasy about adding specific text to foundation documents. Is your proposal meant as an addition to the GRs that want to exempt Sarge from the change to the SC? I really like your proposal in general but I believe it should be voted on *after* we exempted Sarge from the current SC, and be independant of it. Also, it should be stripped of all personal and only presently applicable texts, like the references to Raul, Joey and Sarge. regards, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The new Social Contract and releasing Sarge
On Fri, Apr 30, 2004 at 02:10:46AM +1000, Anthony Towns wrote: > On Wed, Apr 28, 2004 at 04:08:37AM +0200, Jeroen van Wolffelaar wrote: > > Dear developers, > > -release isn't a discussion list. D'oh, could you please put on your release manager hat and address the issues pertaining to the Sarge release, rather than lamenting who interpeted you in what wrong way or violated mailing list policies? We all have the time to feel personally insulted later on, but now we all *want to get Sarge out of the door*. So pretty please, with sugar on top, tell us what the fuck you want to have as a decision from us to get going. For instance, I'd like to know what you think about the proposed GRs, especially Kamion's. Thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: The new Social Contract and releasing Sarge
On Fri, Apr 30, 2004 at 02:10:46AM +1000, Anthony Towns wrote: > On Wed, Apr 28, 2004 at 04:08:37AM +0200, Jeroen van Wolffelaar wrote: > > Dear developers, > > -release isn't a discussion list. D'oh, could you please put on your release manager hat and address the issues pertaining to the Sarge release, rather than lamenting who interpeted you in what wrong way or violated mailing list policies? We all have the time to feel personally insulted later on, but now we all *want to get Sarge out of the door*. So pretty please, with sugar on top, tell us what the fuck you want to have as a decision from us to get going. For instance, I'd like to know what you think about the proposed GRs, especially Kamion's. Thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Thu, Apr 29, 2004 at 09:53:57AM -0500, Steve Langasek wrote: > > For example, people say that our logo was non-free. > > It's non-free due to restrictions on use, distribution, and > modification, not due to a lack of source. OK, I didn't research very well, being short of time. > There is certainly a current of opinion among developers that separate > source forms are less meaningful for images than for programs, though > it's also not universally accepted. There are quite a few modifications > one can usefully make to a bitmapped image, compared to relatively few > changes you can make to a binary executable. Well, yeah. But somehow I feel we're losing sight of what's important here. Having the full source code (and not something obfuscted beyond recognition) for a computer program so we are able to fix bugs and, if necessary, fork it, seems to be essential to what we're doing, namely providing the world with a operating system that rocks (and is free, yada, yada). In contrast, having the possibilty to modify $APPLICATION's stock 'File->Open' icon in its native form, i.e. gimp layers or whatever seems to be of less importance by several orders of magnitude, as long as we can *somehow* fix it by e.g. replacing it with another one, or fixing it by gimping it up or so. I mean, very few of us are graphic designers or so. Same goes with fonts. Even less so with "You've got mail" sounds or so, what's the use in having the Cubase samples for that or something? We could still edit the waveform somehow, even if that would be a bit more tedious. But all those do not block us from making a Free OS that rocks, as opposed to not having (i) the source and (ii) the documentation. Sure, there are some valid applications for the above examples. For instance, I believe we should make as much source available as possible for Debian-specific graphics/artwork/sounds/fonts. Like e.g. a Debian-specific GNOME/KDE splash screen or desktop wallpaper, so that other groups inside of Debian have the least hassle to adopt that type of media to their needs. IMHO, we should be pragmatic here in the limits the social contract and the DFSG allow. Be liberal in what you accept and conservative in what you give. We should be ruled by the concern whether included that particular array of bits will (i) improve our distribution, (ii) improve the Free Software community and (iii) do not impose unreasonable restriction on the aggregated package. I'm not sure whether the other developers think alike and if so, whether we should clarify on this or whether that is the standard reading of the social contract. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Thu, Apr 29, 2004 at 09:53:57AM -0500, Steve Langasek wrote: > > For example, people say that our logo was non-free. > > It's non-free due to restrictions on use, distribution, and > modification, not due to a lack of source. OK, I didn't research very well, being short of time. > There is certainly a current of opinion among developers that separate > source forms are less meaningful for images than for programs, though > it's also not universally accepted. There are quite a few modifications > one can usefully make to a bitmapped image, compared to relatively few > changes you can make to a binary executable. Well, yeah. But somehow I feel we're losing sight of what's important here. Having the full source code (and not something obfuscted beyond recognition) for a computer program so we are able to fix bugs and, if necessary, fork it, seems to be essential to what we're doing, namely providing the world with a operating system that rocks (and is free, yada, yada). In contrast, having the possibilty to modify $APPLICATION's stock 'File->Open' icon in its native form, i.e. gimp layers or whatever seems to be of less importance by several orders of magnitude, as long as we can *somehow* fix it by e.g. replacing it with another one, or fixing it by gimping it up or so. I mean, very few of us are graphic designers or so. Same goes with fonts. Even less so with "You've got mail" sounds or so, what's the use in having the Cubase samples for that or something? We could still edit the waveform somehow, even if that would be a bit more tedious. But all those do not block us from making a Free OS that rocks, as opposed to not having (i) the source and (ii) the documentation. Sure, there are some valid applications for the above examples. For instance, I believe we should make as much source available as possible for Debian-specific graphics/artwork/sounds/fonts. Like e.g. a Debian-specific GNOME/KDE splash screen or desktop wallpaper, so that other groups inside of Debian have the least hassle to adopt that type of media to their needs. IMHO, we should be pragmatic here in the limits the social contract and the DFSG allow. Be liberal in what you accept and conservative in what you give. We should be ruled by the concern whether included that particular array of bits will (i) improve our distribution, (ii) improve the Free Software community and (iii) do not impose unreasonable restriction on the aggregated package. I'm not sure whether the other developers think alike and if so, whether we should clarify on this or whether that is the standard reading of the social contract. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Wed, Apr 28, 2004 at 05:17:41PM -0700, Thomas Bushnell, BSG wrote: > For images, fonts, and sounds, he makes an exception for the source > code requirement. For many of these, there is no sensible source code > anyway, and so DFSG 2 doesn't require it. That is, the image is > itself the source code. That's a statement I would like to know whether it is accepted by all the other developers? I think I agree (without having thought this through a lot), but I was not aware that this was the standard way of interpreting things, certainly not after the recent dicussions. For example, people say that our logo was non-free. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: First Draft proposal for modification of Debian Free Software Guidelines:
On Wed, Apr 28, 2004 at 05:17:41PM -0700, Thomas Bushnell, BSG wrote: > For images, fonts, and sounds, he makes an exception for the source > code requirement. For many of these, there is no sensible source code > anyway, and so DFSG 2 doesn't require it. That is, the image is > itself the source code. That's a statement I would like to know whether it is accepted by all the other developers? I think I agree (without having thought this through a lot), but I was not aware that this was the standard way of interpreting things, certainly not after the recent dicussions. For example, people say that our logo was non-free. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 06:10:24PM +0100, Colin Watson wrote: > I propose this amendment replacing my previous one: > > Points 1. and 2. above are removed and replaced with: > > 1. that the following text be appended to the first clause of the > Social Contract: > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Debian 3.1 (codenamed sarge) will > not meet this standard in those areas, we promise to rectify this in > the following release. > > The first clause of the Social Contract as amended will read as > follows: > > Debian will remain 100% free > > We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its > components will be free according to these guidelines. We will > support people who create or use both free and non-free works on > Debian. We will never make the system require the use of a non-free > component. > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Debian 3.1 (codenamed sarge) will > not meet this standard in those areas, we promise to rectify this in > the next full release. > > 2. that the paragraph added to the Social Contract by this Resolution > shall be removed from the Social Contract upon the next full release > of Debian after Debian 3.1 (codenamed sarge), without further cause > for deliberation. I second this. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html signature.asc Description: Digital signature
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 06:10:24PM +0100, Colin Watson wrote: > I propose this amendment replacing my previous one: > > Points 1. and 2. above are removed and replaced with: > > 1. that the following text be appended to the first clause of the > Social Contract: > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Debian 3.1 (codenamed sarge) will > not meet this standard in those areas, we promise to rectify this in > the following release. > > The first clause of the Social Contract as amended will read as > follows: > > Debian will remain 100% free > > We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its > components will be free according to these guidelines. We will > support people who create or use both free and non-free works on > Debian. We will never make the system require the use of a non-free > component. > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Debian 3.1 (codenamed sarge) will > not meet this standard in those areas, we promise to rectify this in > the next full release. > > 2. that the paragraph added to the Social Contract by this Resolution > shall be removed from the Social Contract upon the next full release > of Debian after Debian 3.1 (codenamed sarge), without further cause > for deliberation. I second this. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html signature.asc Description: Digital signature
Re: Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 08:16:48PM +0100, Colin Watson wrote: > On Wed, Apr 28, 2004 at 09:07:02PM +0200, Guido Trotter wrote: > > Since, as others have pointed out, woody from the clarified SC point of > > view is no better than sarge, delaying sarge itself to make it "perfect" > > woudn't make any justice to our users. > > > > It's quite better if we actually release sarge (which breaches the > > social contract no more than woody does) and then fix the issues and > > release sarge+1 as soon as possible SC-compliant. > > I initially felt this way and tried making this argument to Anthony on > IRC, but he wasn't having any of it: as I understand it (not wishing to > put words into his mouth), he feels that making a new release knowing > that it violates the social contract is qualitatively different from > putting up with the old release that met the promises in the old > contract but not the new one. > After some discussion, I have to say I was convinced. So does this have any bearings on your proposed GR, or did that conversation happen some time ago? > Ultimately, it's the release manager who gets most say in this one. Which is why I hope AJ will speak up on this soon. AJ, could you perhaps comment on the proposed GRs or just state what your preferred way of action would be in order to not delay the sarge release? thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
(Shuffling around the text due to l33t rhetorical abilities...) On Wed, Apr 28, 2004 at 06:49:32PM +0100, Colin Watson wrote: > On Wed, Apr 28, 2004 at 06:58:49PM +0200, Michael Banck wrote: > > Thus, I would prefer a more general GR which states roughly the > > following: > > > > "Changes to the Social Contract become binding for the release after the > > one currently being worked on and are not applicable to already released > > versions of Debian. However, the developers are being urged to implement > > these changes in the currently developed release, if possible." > > This seems to be roughly what Steve Langasek's proposal does. Well, he is only concerned with this specific GR and the Sarge release. I'd think it be worthwhile to have something more general. [...] > I think both these points you've raised are addressed in the modified > amendment (er ...) that I posted some minutes ago. What do you think of > that? I think it's the best one so far. But I still have two problems with it: 1) I believe that changing the SC should be a very infrequent thing. Moreover, I don't know whether I like having temporal passages in it. Your point of having it sitting in /usr/share/doc is valid, of course, but I /guess/ that it would be more important to get the point accross to our current and possible future users through mass-media, which could be done with a similar GR, but without modifying the SC again as well. 2) What are we going to do next time? I guess we're all a bit more alert to these matters now, but IMHO it makes sense to clarify this. I don't know what you others think and I couldn't find an obvious place in the constitution off-hand (however, I did not check thoroughly) where to put this, but having a 'does not have to affect current and past releases' clause for those kinds of changes looks appealing to me right now. That said, if nobody else thinks my points are worthy to consider, I'll support your modified amendment. In the end, our opinions seem to be rather orthogonal, we can still have a look how to prevent this mess next time when we've cleaned up a bit. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 08:16:48PM +0100, Colin Watson wrote: > On Wed, Apr 28, 2004 at 09:07:02PM +0200, Guido Trotter wrote: > > Since, as others have pointed out, woody from the clarified SC point of > > view is no better than sarge, delaying sarge itself to make it "perfect" > > woudn't make any justice to our users. > > > > It's quite better if we actually release sarge (which breaches the > > social contract no more than woody does) and then fix the issues and > > release sarge+1 as soon as possible SC-compliant. > > I initially felt this way and tried making this argument to Anthony on > IRC, but he wasn't having any of it: as I understand it (not wishing to > put words into his mouth), he feels that making a new release knowing > that it violates the social contract is qualitatively different from > putting up with the old release that met the promises in the old > contract but not the new one. > After some discussion, I have to say I was convinced. So does this have any bearings on your proposed GR, or did that conversation happen some time ago? > Ultimately, it's the release manager who gets most say in this one. Which is why I hope AJ will speak up on this soon. AJ, could you perhaps comment on the proposed GRs or just state what your preferred way of action would be in order to not delay the sarge release? thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
Colin, On Wed, Apr 28, 2004 at 04:59:00PM +0100, Colin Watson wrote: > While I would certainly prefer this to "further discussion", I would > like to propose the following amendment. (Alert eyes will note that it's > Option C from Jeroen's post yesterday; I drafted the text that forms the > basis of that Option anyway. I talked to Jeroen, who says he's currently > busy with real-life tasks.) > > Points 1. and 2. above are removed and replaced with: > > 1. that the following text be appended to the first clause of the > Social Contract: > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Sarge will not meet this standard > in those areas, we promise to rectify this in the following release. > > The first clause of the Social Contract as amended will read as > follows: > > Debian will remain 100% free > > We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its > components will be free according to these guidelines. We will > support people who create or use both free and non-free works on > Debian. We will never make the system require the use of a non-free > component. > > We apologize that the current state of some of our documentation and > kernel drivers does not live up to this part of our Social Contract. > While Debian 3.1 (codenamed sarge) will not meet this standard in > those areas, we promise to rectify this in the next full release. Well, first off: Your appended text and the revised first clause don't match identically. (binary-only firmware is only in the former, 3.1 (codenamed sarge) only in the latter, for example). But more to the point: While I see that your amendment has its merits, I'm a bit nervous about changing the actual text of the SC *now* and, obviously, again after Sarge releases (or do we keep it until sarge+1 is out? Or forever?). I would consider the text rather ugly and a historical cludge at that point and voting again next month (haha) to revert it would be tiresome. Now, in real-world politics, laws usually have a date when they are placed into action a certain time after they've been voted on. Further, laws that change how things are being implemented (see, e.g. exhaust norms for new cars in California) are usually granted quite a while (sometimes, years) until they become binding. Thus, I would prefer a more general GR which states roughly the following: "Changes to the Social Contract become binding for the release after the one currently being worked on and are not applicable to already released versions of Debian. However, the developers are being urged to implement these changes in the currently developed release, if possible." We should add some syntactic sugar to make it retroactively applicable to the last GR, of course. Michael PS: In any event, I'd appreciate it if AJ would speak up and tell us the preferred way he would like us to deal with this situation. I know 'Three's a charm' but I'd rather not apply this to GR's changing the SC. -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
(Shuffling around the text due to l33t rhetorical abilities...) On Wed, Apr 28, 2004 at 06:49:32PM +0100, Colin Watson wrote: > On Wed, Apr 28, 2004 at 06:58:49PM +0200, Michael Banck wrote: > > Thus, I would prefer a more general GR which states roughly the > > following: > > > > "Changes to the Social Contract become binding for the release after the > > one currently being worked on and are not applicable to already released > > versions of Debian. However, the developers are being urged to implement > > these changes in the currently developed release, if possible." > > This seems to be roughly what Steve Langasek's proposal does. Well, he is only concerned with this specific GR and the Sarge release. I'd think it be worthwhile to have something more general. [...] > I think both these points you've raised are addressed in the modified > amendment (er ...) that I posted some minutes ago. What do you think of > that? I think it's the best one so far. But I still have two problems with it: 1) I believe that changing the SC should be a very infrequent thing. Moreover, I don't know whether I like having temporal passages in it. Your point of having it sitting in /usr/share/doc is valid, of course, but I /guess/ that it would be more important to get the point accross to our current and possible future users through mass-media, which could be done with a similar GR, but without modifying the SC again as well. 2) What are we going to do next time? I guess we're all a bit more alert to these matters now, but IMHO it makes sense to clarify this. I don't know what you others think and I couldn't find an obvious place in the constitution off-hand (however, I did not check thoroughly) where to put this, but having a 'does not have to affect current and past releases' clause for those kinds of changes looks appealing to me right now. That said, if nobody else thinks my points are worthy to consider, I'll support your modified amendment. In the end, our opinions seem to be rather orthogonal, we can still have a look how to prevent this mess next time when we've cleaned up a bit. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
Colin, On Wed, Apr 28, 2004 at 04:59:00PM +0100, Colin Watson wrote: > While I would certainly prefer this to "further discussion", I would > like to propose the following amendment. (Alert eyes will note that it's > Option C from Jeroen's post yesterday; I drafted the text that forms the > basis of that Option anyway. I talked to Jeroen, who says he's currently > busy with real-life tasks.) > > Points 1. and 2. above are removed and replaced with: > > 1. that the following text be appended to the first clause of the > Social Contract: > > We apologize that the current state of some of our documentation and > kernel drivers with binary-only firmware does not live up to this > part of our Social Contract. While Sarge will not meet this standard > in those areas, we promise to rectify this in the following release. > > The first clause of the Social Contract as amended will read as > follows: > > Debian will remain 100% free > > We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its > components will be free according to these guidelines. We will > support people who create or use both free and non-free works on > Debian. We will never make the system require the use of a non-free > component. > > We apologize that the current state of some of our documentation and > kernel drivers does not live up to this part of our Social Contract. > While Debian 3.1 (codenamed sarge) will not meet this standard in > those areas, we promise to rectify this in the next full release. Well, first off: Your appended text and the revised first clause don't match identically. (binary-only firmware is only in the former, 3.1 (codenamed sarge) only in the latter, for example). But more to the point: While I see that your amendment has its merits, I'm a bit nervous about changing the actual text of the SC *now* and, obviously, again after Sarge releases (or do we keep it until sarge+1 is out? Or forever?). I would consider the text rather ugly and a historical cludge at that point and voting again next month (haha) to revert it would be tiresome. Now, in real-world politics, laws usually have a date when they are placed into action a certain time after they've been voted on. Further, laws that change how things are being implemented (see, e.g. exhaust norms for new cars in California) are usually granted quite a while (sometimes, years) until they become binding. Thus, I would prefer a more general GR which states roughly the following: "Changes to the Social Contract become binding for the release after the one currently being worked on and are not applicable to already released versions of Debian. However, the developers are being urged to implement these changes in the currently developed release, if possible." We should add some syntactic sugar to make it retroactively applicable to the last GR, of course. Michael PS: In any event, I'd appreciate it if AJ would speak up and tell us the preferred way he would like us to deal with this situation. I know 'Three's a charm' but I'd rather not apply this to GR's changing the SC. -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 12:47:58PM -0400, Raul Miller wrote: > More specifically, if glibc requires a binary component (a current > version of the glibc binaries) for its source to be built, then glibc > isn't distributable under the GPL. I've heard that there are a couple of hundred other packages which need a current version of libc binaries to build. They are called 'C programs'. We've even invented stuff like Build-Depends for them. Stop the presses! File RC bugs! Michael (Incidently, I've built glibc_2.3.2ds1-12 packages on hurd-i386 yesterday. The current version of glibc on hurd-i386 is 2.3.1-5 which is not so recent alltogether. Further, the glibc package does not even have a versioned Build-Depends on libc6-dev) -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 12:47:58PM -0400, Raul Miller wrote: > More specifically, if glibc requires a binary component (a current > version of the glibc binaries) for its source to be built, then glibc > isn't distributable under the GPL. I've heard that there are a couple of hundred other packages which need a current version of libc binaries to build. They are called 'C programs'. We've even invented stuff like Build-Depends for them. Stop the presses! File RC bugs! Michael (Incidently, I've built glibc_2.3.2ds1-12 packages on hurd-i386 yesterday. The current version of glibc on hurd-i386 is 2.3.1-5 which is not so recent alltogether. Further, the glibc package does not even have a versioned Build-Depends on libc6-dev) -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote: > On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote: > > So, if the technical committee would like to comment on this issue, > > take the decision out of my hands, or overrule any decision I might > > otherwise make, now would be a good time. > > The technical committee can't override the constitution (nor foundation > documents) any more than you can. > > However it might be worthwhile introducing a "Sarge Exception", making > an explicit grandfather clause applicable only to sarge, and earlier > distributions, so we can release the it. This is philosophically ugly, > but then some people (perhaps RMS) think the same of debian as a whole. > > The language of that GR might run something like: In the past, we > have had some disagreements between ourselves about what it is we're > trying to do and what should go in a free distribution. We intend to > fix those issues, going forwards, however to release the version of > the distribution which we were about to release, it's going to have to > include some components which might have been acceptable under our old > social contract but which are definitely not acceptable under the new. > We resolve to distribute the "Sarge Distribution" with packages licensed > as they are currently licensed, even though these license conflict > with the updated social contract. We'll also be providing in "Sarge" > a document listing at least one such conflict for each of these packages. Well, I'd second this, if it was put forth. > As an aside... or as a possibly related issue, consider glibc -- here > is a piece of software which is licensed as free (though RMS might say > that the LGPL licensed components aren't as free as he'd like), but > which in practice is still distributed in almost-binary form (you can't > build current versions of glibc on linux without having extremely current > binaries because the version skew is so great). In essence, the preferred > form for working with this software must include its binaries... anyways, > I've not thought this all the way through, but parts of glibc are GPL'd > software and there's some possibility that without the sarge exception > we wouldn't be able to distribute glibc (or maybe any of the GPL licensed > parts of the tool chain) in its current form. Huh??? This procedure is called bootstrapping... I don't believe this is related to the issue in any way and just dilutes your (valid, IMHO) point above. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 02:32:34PM +0200, Martin Schulze wrote: > Francesco P. Lovergine wrote: > > Issue a 'man emacs' for instance > > What am I supposed to read there? Mine doesn't say that it's using > the FDL but since its date says it's from 1995 December 7, I doubt > it does. You're supposed to appreciate that although the Emacs manpage might satisfy our requirements for inclusion in main, it is useless in practice when compared to the GFDL manual/info page. So even if the glibc functions might be documented in manpages in a satisfactory way, this is probably not true for the rest of the GNU packages. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote: > On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote: > > So, if the technical committee would like to comment on this issue, > > take the decision out of my hands, or overrule any decision I might > > otherwise make, now would be a good time. > > The technical committee can't override the constitution (nor foundation > documents) any more than you can. > > However it might be worthwhile introducing a "Sarge Exception", making > an explicit grandfather clause applicable only to sarge, and earlier > distributions, so we can release the it. This is philosophically ugly, > but then some people (perhaps RMS) think the same of debian as a whole. > > The language of that GR might run something like: In the past, we > have had some disagreements between ourselves about what it is we're > trying to do and what should go in a free distribution. We intend to > fix those issues, going forwards, however to release the version of > the distribution which we were about to release, it's going to have to > include some components which might have been acceptable under our old > social contract but which are definitely not acceptable under the new. > We resolve to distribute the "Sarge Distribution" with packages licensed > as they are currently licensed, even though these license conflict > with the updated social contract. We'll also be providing in "Sarge" > a document listing at least one such conflict for each of these packages. Well, I'd second this, if it was put forth. > As an aside... or as a possibly related issue, consider glibc -- here > is a piece of software which is licensed as free (though RMS might say > that the LGPL licensed components aren't as free as he'd like), but > which in practice is still distributed in almost-binary form (you can't > build current versions of glibc on linux without having extremely current > binaries because the version skew is so great). In essence, the preferred > form for working with this software must include its binaries... anyways, > I've not thought this all the way through, but parts of glibc are GPL'd > software and there's some possibility that without the sarge exception > we wouldn't be able to distribute glibc (or maybe any of the GPL licensed > parts of the tool chain) in its current form. Huh??? This procedure is called bootstrapping... I don't believe this is related to the issue in any way and just dilutes your (valid, IMHO) point above. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 02:32:34PM +0200, Martin Schulze wrote: > Francesco P. Lovergine wrote: > > Issue a 'man emacs' for instance > > What am I supposed to read there? Mine doesn't say that it's using > the FDL but since its date says it's from 1995 December 7, I doubt > it does. You're supposed to appreciate that although the Emacs manpage might satisfy our requirements for inclusion in main, it is useless in practice when compared to the GFDL manual/info page. So even if the glibc functions might be documented in manpages in a satisfactory way, this is probably not true for the rest of the GNU packages. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 11:46:43AM +0200, Martin Schulze wrote: > Speaking of the GFDL, only those documents released under the GNU FDL > are non-free that make use of invariant sections for anything else > than its license, right? > > Hence, every document released under the GNU FDL needs to be checked > for every version, but the FDL doesn't render documentation non-free > inherently, right? It doesn't render it free inherently, either, which > is very bad since a new version could become non-free unexpectedly. Not according to Manoj's (still horribly formatted) position statement: "The GNU FDL, as it stands today, does not meet the Debian Free Software Guidelines. There are significant problems with the license, as detailed above; and, as such, we cannot accept works licensed unde the GNU FDL into our distribution." Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 11:46:43AM +0200, Martin Schulze wrote: > Speaking of the GFDL, only those documents released under the GNU FDL > are non-free that make use of invariant sections for anything else > than its license, right? > > Hence, every document released under the GNU FDL needs to be checked > for every version, but the FDL doesn't render documentation non-free > inherently, right? It doesn't render it free inherently, either, which > is very bad since a new version could become non-free unexpectedly. Not according to Manoj's (still horribly formatted) position statement: "The GNU FDL, as it stands today, does not meet the Debian Free Software Guidelines. There are significant problems with the license, as detailed above; and, as such, we cannot accept works licensed unde the GNU FDL into our distribution." Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
On Tue, Mar 30, 2004 at 07:59:09AM +1000, Craig Sanders wrote: > On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote: [...] > you bigots lost the vote (you didn't even come close) - can't you please just > shut up and go away? do you really have to try to continue the "discussion", > by any desperate means possible? Nathanael is not even in the NM-queue and thus was not eligible to vote, so please don't confuse him with the rest of us bigots, mmkay? ;) Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: GR: Alternative editorial changes to the SC
On Tue, Mar 30, 2004 at 07:59:09AM +1000, Craig Sanders wrote: > On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote: [...] > you bigots lost the vote (you didn't even come close) - can't you please just > shut up and go away? do you really have to try to continue the "discussion", > by any desperate means possible? Nathanael is not even in the NM-queue and thus was not eligible to vote, so please don't confuse him with the rest of us bigots, mmkay? ;) Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
On Mon, Mar 29, 2004 at 04:27:58AM -0500, Nathanael Nerode wrote: > I think my comment was actually appropriate and to-the-point. I beg to differ, but *shrug* Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: GR: Editorial amendments to the social contract
On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: > Raul Miller wrote: > > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: > >> No, trust me, we parsed this one very carefully and took an excessive > >> amount of time on this in debian-legal. There are two possible > >> interpretations, but both come out to an "and". > > That's so bogus I don't know where to start. > Start by learning English better? I would be *really* grateful if you could limit /this/ discussion to something civil. So either drop your usual insults or drop -vote from your mailbox. Thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: GR: Editorial amendments to the social contract
On Mon, Mar 29, 2004 at 04:27:58AM -0500, Nathanael Nerode wrote: > I think my comment was actually appropriate and to-the-point. I beg to differ, but *shrug* Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: > Raul Miller wrote: > > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: > >> No, trust me, we parsed this one very carefully and took an excessive > >> amount of time on this in debian-legal. There are two possible > >> interpretations, but both come out to an "and". > > That's so bogus I don't know where to start. > Start by learning English better? I would be *really* grateful if you could limit /this/ discussion to something civil. So either drop your usual insults or drop -vote from your mailbox. Thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SC changes
On Fri, Mar 26, 2004 at 10:57:17PM -0800, Don Armstrong wrote: > On Fri, 26 Mar 2004, Thomas Bushnell, BSG wrote: > > Of course there are interactions between, but there are several > > discrete proposals in each of the two version of changes, and I > > might like some and not others. I would hate to have to vote > > against the ones I like just because they are tied to ones I greatly > > dislike. > > Why not propose amendments to the proposal that reflect your viewpoint > then? Sure, I guess that would be no problem. But I don't get why everybody pulls the 'make your own amendment' card right away. We're in the discussion period, right? So I don't see a problem with asking Andrew whether he'd be willing to do modify his proposal, if he sees the merit of othere people's comments. If he does not like it, amendments can still be formulated, but there's no need to clutter the ballot without need, in my humble opinion. Michael PS: I'm all for pulling the 'you should have made your own amendment' card for people who don't like the ballot *after* the vote has started ;) -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: SC changes
On Fri, Mar 26, 2004 at 10:57:17PM -0800, Don Armstrong wrote: > On Fri, 26 Mar 2004, Thomas Bushnell, BSG wrote: > > Of course there are interactions between, but there are several > > discrete proposals in each of the two version of changes, and I > > might like some and not others. I would hate to have to vote > > against the ones I like just because they are tied to ones I greatly > > dislike. > > Why not propose amendments to the proposal that reflect your viewpoint > then? Sure, I guess that would be no problem. But I don't get why everybody pulls the 'make your own amendment' card right away. We're in the discussion period, right? So I don't see a problem with asking Andrew whether he'd be willing to do modify his proposal, if he sees the merit of othere people's comments. If he does not like it, amendments can still be formulated, but there's no need to clutter the ballot without need, in my humble opinion. Michael PS: I'm all for pulling the 'you should have made your own amendment' card for people who don't like the ballot *after* the vote has started ;) -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Call for votes: General resolution for the handling of the non-free section
On Fri, Mar 26, 2004 at 07:01:41PM +0100, Dale C. Scheetz wrote: > There is no contradiction between declaring Debian to be totally about > Free Software, and the maintaining of a section called non-free. The > non-free packages are examples of software that fails to meet our > definition of free, which the rest of the world considers "free enough". Uhm, 'the rest of the world' considers binary-only drivers 'free enough'? > The fact that we can "legally" distribute this code makes that > distribution completely "OK" by the rest of the software community not > committed to software freedom as Debian defines it. I don't think RedHat or SuSE ship any significant package from non-free in their default distribution, apart from the binary-only drivers of course. > We provide examples of the right way to build Debian packages in many > different places, although I find the existing code base to be full of > both good and bad examples, our documentation is mostly self consistant. What does this have to do with the non-free debate? > Negative examples tend to improve our understanding faster than positive > ones. Being able to point to packages with "poor" licensing conditions > has always been helpful when trying to determine what is wrong with some > other license. Why would pointing to packages at non-free.org be worse in this regard? I'd say it would be even better, as they are clearly marked as having a poor license. > I don't have much time to devote to Debian these days, but that doesn't > mean that I don't still find it very important. Yeah, tuning into this discussion is the best you can do with your little time in order to help Debian! > The Contract and Guidelines were written specifically to block political > modification of the goals and principles of Debian. If Debian is to > survive, this attempt to modify our principles must fail. When the Guidelines were written, you needed non-free software to actually upload a package into the archive, to the best of my knowledge. Non-free software was not a commodity back then, it was very hard to get any work done without it I guess. These times have changed. Today, the 'almost-free' packages in non-free are mostly insignificant for most users. In contrast, by far the most important ones are the binary-only drivers nowadays. non-free has changed. I don't see why Debian should not reevaluate its support. Well, we did, and we agreed to support non-free for the time being, so I don't understand why you're making such a fuss about it. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: First Call for votes: General resolution for the handling of the non-free section
On Fri, Mar 26, 2004 at 07:01:41PM +0100, Dale C. Scheetz wrote: > There is no contradiction between declaring Debian to be totally about > Free Software, and the maintaining of a section called non-free. The > non-free packages are examples of software that fails to meet our > definition of free, which the rest of the world considers "free enough". Uhm, 'the rest of the world' considers binary-only drivers 'free enough'? > The fact that we can "legally" distribute this code makes that > distribution completely "OK" by the rest of the software community not > committed to software freedom as Debian defines it. I don't think RedHat or SuSE ship any significant package from non-free in their default distribution, apart from the binary-only drivers of course. > We provide examples of the right way to build Debian packages in many > different places, although I find the existing code base to be full of > both good and bad examples, our documentation is mostly self consistant. What does this have to do with the non-free debate? > Negative examples tend to improve our understanding faster than positive > ones. Being able to point to packages with "poor" licensing conditions > has always been helpful when trying to determine what is wrong with some > other license. Why would pointing to packages at non-free.org be worse in this regard? I'd say it would be even better, as they are clearly marked as having a poor license. > I don't have much time to devote to Debian these days, but that doesn't > mean that I don't still find it very important. Yeah, tuning into this discussion is the best you can do with your little time in order to help Debian! > The Contract and Guidelines were written specifically to block political > modification of the goals and principles of Debian. If Debian is to > survive, this attempt to modify our principles must fail. When the Guidelines were written, you needed non-free software to actually upload a package into the archive, to the best of my knowledge. Non-free software was not a commodity back then, it was very hard to get any work done without it I guess. These times have changed. Today, the 'almost-free' packages in non-free are mostly insignificant for most users. In contrast, by far the most important ones are the binary-only drivers nowadays. non-free has changed. I don't see why Debian should not reevaluate its support. Well, we did, and we agreed to support non-free for the time being, so I don't understand why you're making such a fuss about it. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why a debian project leader?
On Tue, Mar 23, 2004 at 03:29:47PM -0800, mbc wrote: > No, formal consensus usually has the following steps: > > - broad discussion of the issue at hand > - once the discussion moves toward a solution, someone makes a proposal > - the facilitator calls for consensus, and asks for questions and concerns > - if there are strong concerns, the proposal goes back to the discussion > phase to figure out how to address the concerns in the proposal > - those taking part have the option to agree, stand aside, or block You should subscribe to -devel then. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: why a debian project leader?
On Tue, Mar 23, 2004 at 03:29:47PM -0800, mbc wrote: > No, formal consensus usually has the following steps: > > - broad discussion of the issue at hand > - once the discussion moves toward a solution, someone makes a proposal > - the facilitator calls for consensus, and asks for questions and concerns > - if there are strong concerns, the proposal goes back to the discussion > phase to figure out how to address the concerns in the proposal > - those taking part have the option to agree, stand aside, or block You should subscribe to -devel then. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q: guidelines for post-campaign period?
On Tue, Mar 23, 2004 at 02:51:42PM -0500, Raul Miller wrote: > On Tue, Mar 23, 2004 at 12:29:28PM -0600, Manoj Srivastava wrote: > > > A long campaigning period still does not result in perfect > > > information. Given that I have to make a decision in the face of > > > incomplete information, the possibility of getting relevant > > > information ought not to be dismissed. > > On Tue, Mar 23, 2004 at 07:59:48PM +0100, Michael Banck wrote: > > In that case I wonder why no rebuttals were posted and why the IRC > > debate was called off, if obviously there is more need for information > > and discussion. > > Judgement call? > > Maybe those judgement calls could have been better, but "we've got plenty > of campaign information on debian-vote, we don't need to add another > forum" is not at all equivalent to "let's stop using debian-vote for > this kind of traffic". Anyway, I don't want to imply that I'm unhappy with the current process or even Manoj. I was just pointing out my opinion. If others think it's worthy to keep on going, that's fine with me. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Q: guidelines for post-campaign period?
On Tue, Mar 23, 2004 at 12:29:28PM -0600, Manoj Srivastava wrote: > On Tue, 23 Mar 2004 11:36:46 -0500, David B Harris <[EMAIL PROTECTED]> said: > > > Some people want to make an informed decision, but don't have time > > to read hundreds of pages worth of mailing list discussion. > > > A long voting period withought campaigning allows for people to read > > over the material, stew on it for a while, and make an informed > > decision. > > A long campaigning period still does not result in perfect > information. Given that I have to make a decision in the face of > incomplete information, the possibility of getting relevant > information ought not to be dismissed. In that case I wonder why no rebuttals were posted and why the IRC debate was called off, if obviously there is more need for information and discussion. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Q: guidelines for post-campaign period?
On Tue, Mar 23, 2004 at 02:51:42PM -0500, Raul Miller wrote: > On Tue, Mar 23, 2004 at 12:29:28PM -0600, Manoj Srivastava wrote: > > > A long campaigning period still does not result in perfect > > > information. Given that I have to make a decision in the face of > > > incomplete information, the possibility of getting relevant > > > information ought not to be dismissed. > > On Tue, Mar 23, 2004 at 07:59:48PM +0100, Michael Banck wrote: > > In that case I wonder why no rebuttals were posted and why the IRC > > debate was called off, if obviously there is more need for information > > and discussion. > > Judgement call? > > Maybe those judgement calls could have been better, but "we've got plenty > of campaign information on debian-vote, we don't need to add another > forum" is not at all equivalent to "let's stop using debian-vote for > this kind of traffic". Anyway, I don't want to imply that I'm unhappy with the current process or even Manoj. I was just pointing out my opinion. If others think it's worthy to keep on going, that's fine with me. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q: guidelines for post-campaign period?
On Tue, Mar 23, 2004 at 11:34:45AM -0500, Raul Miller wrote: > Could I ask why you "not generating new material" during the voting > period is a good thing? Because, obviously, people who already voted would have to check every day to see whether some new twist in the campaign has arisen that would lead to a change in their opinion. After all, it's called 'campaigning period' and 'voting period'. Not 'some campaigning' and 'more campaigning, and also voting'. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
