Re: Changing how we handle non-free firmware
Hi Steve, And thanks for your work on this. Steve McIntyre <93...@debian.org> (2022-08-18): > Hi a11! > > I'm proposing to change how we handle non-free firmware in > Debian. I've written about this a few times already this year [1, 2] > and I ran a session on the subject at DebConf [3]. > > TL;DR: The way we deal with (non-free) firmware in Debian isn't > great. For a long time we've got away without supporting and including > (non-free) firmware on Debian systems. We don't *want* to have to > provide (non-free) firmware to our users, and in an ideal world we > wouldn't need to. However, it's no longer a sensible path when trying > to support lots of common current hardware. Increasingly, modern > computers don't function fully without these firmware blobs. > > Since I started talking about this, Ansgar has already added dak > support for a new, separate non-free-firmware component - see > [4]. This makes part of my original proposal moot! More work is needed > yet to make use of this support, but it's started! :-) > > I believe that there is reasonably wide support for changing what we > do with non-free firmware. I see several possible paths forward, but > as I've stated previously I don't want to be making the decision > alone. I believe that the Debian project as a whole needs to make the > decision on which path is the correct one. > > I'm *not* going to propose full text for all the possible choices > here; as eloquently suggested by Russ [5], it's probably better to > leave it for other people to come up with the text of options that > they feel should also be on the ballot. > > So, I propose the following: > > = > > We will include non-free firmware packages from the > "non-free-firmware" section of the Debian archive on our official > media (installer images and live images). The included firmware > binaries will *normally* be enabled by default where the system > determines that they are required, but where possible we will include > ways for users to disable this at boot (boot menu option, kernel > command line etc.). > > When the installer/live system is running we will provide information > to the user about what firmware has been loaded (both free and > non-free), and we will also store that information on the target > system such that users will be able to find it later. The target > system will *also* be configured to use the non-free-firmware > component by default in the apt sources.list file. Our users should > receive security updates and important fixes to firmware binaries just > like any other installed software. > > We will publish these images as official Debian media, replacing the > current media sets that do not include non-free firmware packages. > > = > > A reason for defaulting to installing non-free firmware *by default* > is accessibility. A blind user running the installer in text-to-speech > mode may need audio firmware loaded to be able to drive the installer > at all. It's going to be very difficult for them to change this. Other > people should be able to drive the system (boot menus, etc.) to *not* > install the non-free firmware packages if desired. > > We will *only* include the non-free-firmware component on our media > and on installed systems by default. As a general policy, we still do > not want to see other non-free software in use. Users may still enable > the existing non-free component if they need it. > > We also need to do the work to make this happen: > > * in d-i, live-boot and elsewhere to make information about firmware >available. > > * add support for the non-free-firmware section in more places: >ftpsync, debian-cd and more. > > and I plan to start on some of those soon. Seconded. And I'm happy to help in any way I can for d-i at least. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Margarita Manterola (2016-07-08): > The Debian Constitution is very well written, in a way that is almost > completely > ungendered. The only gendered word left is the Chairman of the Technical > Committee. There is no reason for this position to be gendered. Ungendered > alternatives for Chairman are Chair and Chairperson. While both work, Chair is > simpler and shorter. > > I'm therefore proposing the following General Resolution: > > === BEGIN GR TEXT === > > Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > > All appearances of the word Chairman shall be replaced with the word Chair. > > === END GR TEXT === > > This change can be applied by a simple sed command (s/Chairman/Chair/g). I'm > attaching the diff between the current constitution document and the output of > said sed command to make it explicit that no other changes are intended. > > -- > Regards, > Marga > --- constitution.wml 2016-02-25 08:03:04.0 +0100 > +++ constitution.new.wml 2016-07-08 15:18:41.857474553 +0200 > @@ -37,7 +37,7 @@ > >The Project Leader; > > - The Technical Committee and/or its Chairman; > + The Technical Committee and/or its Chair; > >The individual Developer working on a particular task; > > @@ -69,7 +69,7 @@ > > > A person may hold several posts, except that the Project Leader, > -Project Secretary and the Chairman of the Technical Committee must > +Project Secretary and the Chair of the Technical Committee must > be distinct, and that the Leader cannot appoint themselves as their > own Delegate. > > @@ -460,10 +460,10 @@ > > > > -Appoint the Chairman of the Technical Committee. > +Appoint the Chair of the Technical Committee. > > > - The Chairman is elected by the Committee from its members. All > + The Chair is elected by the Committee from its members. All > members of the committee are automatically nominated; the > committee votes starting one week before the post will become > vacant (or immediately, if it is already too late). The members > @@ -476,10 +476,10 @@ > > > > -The Chairman can stand in for the Leader, together with the > +The Chair can stand in for the Leader, together with the > Secretary > > -As detailed in §7.1(2), the Chairman of the Technical > +As detailed in §7.1(2), the Chair of the Technical > Committee and the Project Secretary may together stand in for the > Leader if there is no Leader. > > @@ -561,10 +561,10 @@ > > Details regarding voting > > -The Chairman has a casting vote. When the Technical Committee > +The Chair has a casting vote. When the Technical Committee > votes whether to override a Developer who also happens to be a > member of the Committee, that member may not vote (unless they are > -the Chairman, in which case they may use only their casting > +the Chair, in which case they may use only their casting > vote). > > > @@ -627,10 +627,10 @@ > > > > -Can stand in for the Leader, together with the Chairman of the > +Can stand in for the Leader, together with the Chair of the > Technical Committee. > > -If there is no Project Leader then the Chairman of the > +If there is no Project Leader then the Chair of the > Technical Committee and the Project Secretary may by joint > agreement make decisions if they consider it imperative to do > so. > @@ -658,7 +658,7 @@ > > If there is no Project Secretary or the current Secretary is > unavailable and has not delegated authority for a decision then the > -decision may be made or delegated by the Chairman of the Technical > +decision may be made or delegated by the Chair of the Technical > Committee, as Acting Secretary. > > The Project Secretary's term of office is 1 year, at which point > @@ -671,7 +671,7 @@ > Developers. > > When acting together to stand in for an absent Project Leader the > -Chairman of the Technical Committee and the Project Secretary should > +Chair of the Technical Committee and the Project Secretary should > make decisions only when absolutely necessary and only when consistent > with the consensus of the Developers. Seconded, thanks. KiBi. signature.asc Description: Digital signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
Nicolas Dandrimont (2016-07-07): > In 2005, the body of Debian Developers passed a General Resolution[1] > requiring > the creation of a declassification team for the debian-private mailing list. > For the past ten years, the implementation of this GR has never materialized, > despite an explicit call for volunteers[2] by the DPL in 2010. > > [1] https://www.debian.org/vote/2005/vote_002 > [2] https://lists.debian.org/debian-project/2010/05/msg00105.html > > Over the years, several important discussions have happened on the > debian-private mailing list that needed to stay private. Oftentimes, when a > discussion has carried on for a while, some participants have reminded others > that the discussion should be summarized in a public thread on either the > debian-devel or the debian-project mailing lists. > > While we agree with the intentions behind the original GR, we believe it is > now > time to acknowledge that the declassification of debian-private will never > happen, and that we should instead strongly encourage developers to move > discussions to public channels as soon as the sensitivity of the discussion > subsides. > > We therefore propose the following General Resolution: > > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === > > Thanks for your consideration, > -- > Nicolas Dandrimont (with thanks to all who helped writing this) Seconded. KiBi. signature.asc Description: Digital signature
Re: Rebuilding translations when needed (was: translation-check's maxdelta oddities)
Hi, Holger Wansing (2016-01-11): > Holger Wansing wrote: > > I have just committed this for the german d-i errata: > > > > > > --- errata.wml 28 Oct 2015 20:18:01 - 1.117 > > +++ errata.wml 5 Dec 2015 22:08:26 - > > @@ -1,6 +1,7 @@ > > #use wml::debian::template title="Debian-Installer - Errata" > > #use wml::debian::recent_list > > #include "$(ENGLISHDIR)/devel/debian-installer/images.data" > > +#depends "$(ENGLISHDIR)/devel/debian-installer/errata.wml" > > #use wml::debian::translation-check translation="1.220" mindelta="1" > > maxdelta="1" > > # $Id: errata.wml,v 1.117 2015/10/28 20:18:01 holger-guest Exp $ > > # Original-Translator: Frank Lichtenheld , 2003-11-11 > > > > > > Let's see what happens with the next d-i alpha/beta release... > > (and what the build log looks like tomorrow :-) German builds fine > > here locally though.) > > This did not work. > The german page still shows > "Errata für Stretch Alpha 4" and no "Attention: outdated translation. Read > the original." > > Interestingly: the french site does everything right: "Alpha 5" and the > "Attention: outdated translation. ... " > There was no commit for french! As there was no for german. That's what I noticed yesterday, but I didn't take time to double check and report back. I'm a bit lost here… Mraw, KiBi. signature.asc Description: Digital signature
Rebuilding translations when needed (was: translation-check's maxdelta oddities)
Hi, [ Initially a debian-boot vs. debian-www topic but I think vote.debian.org might be having a similar issue. ] Holger Wansing (2015-10-31): > Cyril Brulebois wrote: > > Could it be that images.data's being updated doesn't lead to a rebuild > > of the relevant translations? And that those are only rebuilt when their > > files actually get updated? That would explain why building them locally > > led to the expected results, while the website getting updated would > > still have the old contents? > > > > (I'm not sure how dependencies between files are declared/detected, and > > I don't think I'll find time tonight to check this out, hence just > > throwing the idea for the time being.) > > Hmm, looking at the swedish variant of that page, it seems that Kibi's > assumption might be correct: > > The corresponding swedish wml file correctly contains the entity > , but the website shows "Stretch Alpha 3". > > There was no commit for the swedish errata file since the release of > Alpha 4, and it seems the swedish translation of errata was not newly > build since then. > > I have no clue what to do about this though... There's some fun going on with votes right now too. https://www.debian.org/vote/index.fr.html has: | En attente de sponsors | Résolution générale : mise à jour de la procédure standard de Résolution (i.e. waiting for seconds) while https://www.debian.org/vote/index.en.html has: | Voting Open | General Resolution: Update Standard Resolution Procedure The wml_p1_ipp manpage makes me think the following construct might help get translations rebuilt even if their actual source didn't change: |Special `Depends' Variant |You can easily write fragments of Makefiles with the -M flag (see below) to keep tracks of which |files the output file depends on, When "ipp" is invoked as a piece of "WML", the final output file |may depend on other files. You can tell "ipp" about these hidden dependencies by using the |"#depends" variant , e.g. | | #depends 'foo.dat' | #depends "*/*.dat" | #depends | |The contents of the file is not inserted, only information about dependencies are updated. Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
Enrico Zini (2015-05-24): > I have also implemented audit tracking of all changes to Person records > on nm.debian.org, which in turn allowed me to change the nightly > maintenance scripts to do more aggressive imports of changes from > keyrings and LDAP. > > I have also done quite a bit of manual work fixing every inconsistency > that could not be fixed automatically. > > For the first time ever, keyrings, LDAP and nm.debian.org should now all > be perfectly aligned. I saw *WOW* to that, and thanks to everyone > involved, because I think that membership is a rather important area > where to have all databases in sync. Good job, Enrico, and thanks! Mraw, KiBi. signature.asc Description: Digital signature
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
Stefano Zacchiroli (2014-12-01): > === > The Constitution is amended as follows: > > --- > --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 > +++ constitution.2-S.txt 2014-11-21 16:56:47.328071287 +0100 > @@ -299,8 +299,20 @@ > Project Leader may appoint new member(s) until the number of > members reaches 6, at intervals of at least one week per > appointment. > -5. If the Technical Committee and the Project Leader agree they may > +5. A Developer is not eligible to be (re)appointed to the Technical > + Committee if they have been a member within the previous 12 months. > +6. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. > +7. Term limit: > + 1. On January 1st of each year the term of any Committee member > +who has served more than 42 months (3.5 years) and who is one > +of the two most senior members is set to expire on December > +31st of that year. > + 2. A member of the Technical Committee is said to be more senior > +than another if they were appointed earlier, or were appointed > +at the same time and have been a member of the Debian Project > +longer. In the event that a member has been appointed more > +than once, only the most recent appointment is relevant. > >6.3. Procedure > > --- > > As a transitional measure, if this GR is passed after January 1st, 2015, > then the provision of section §6.2.7.1 is taken to have occurred on January > 1st, 2015. > === Seconded. (Signed this time, sorry for the noise.) Mraw, KiBi. signature.asc Description: Digital signature
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
Stefano Zacchiroli (2014-12-01): > === > The Constitution is amended as follows: > > --- > --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 > +++ constitution.2-S.txt 2014-11-21 16:56:47.328071287 +0100 > @@ -299,8 +299,20 @@ > Project Leader may appoint new member(s) until the number of > members reaches 6, at intervals of at least one week per > appointment. > -5. If the Technical Committee and the Project Leader agree they may > +5. A Developer is not eligible to be (re)appointed to the Technical > + Committee if they have been a member within the previous 12 months. > +6. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. > +7. Term limit: > + 1. On January 1st of each year the term of any Committee member > +who has served more than 42 months (3.5 years) and who is one > +of the two most senior members is set to expire on December > +31st of that year. > + 2. A member of the Technical Committee is said to be more senior > +than another if they were appointed earlier, or were appointed > +at the same time and have been a member of the Debian Project > +longer. In the event that a member has been appointed more > +than once, only the most recent appointment is relevant. > >6.3. Procedure > > --- > > As a transitional measure, if this GR is passed after January 1st, 2015, > then the provision of section §6.2.7.1 is taken to have occurred on January > 1st, 2015. > === Seconded. Mraw, KiBi. -- 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/20141201124507.gb31...@mraw.org
Re: Reducing the discussion and the voting period to 1 week
Lucas Nussbaum (2014-10-22): > On 17/10/14 at 10:01 +0200, Lucas Nussbaum wrote: > > But designing and tuning alternative proposals might take time, so I > > would prefer to wait a few days before reducing the discussion period, > > to ensure that we vote with a sensible ballot. I will decide in the > > middle of next week about that. > > I think that the current set of options would be a sensible ballot, and > I'm not aware of any discussions to add another option, so I'm inclined > to shorten the discussion period. For all I know/remember from the mails I read, it seems there was an agreement that this GR wouldn't affect jessie in any way. While I can sympathize with trying to reach a conclusion sooner than later, possibly sparing quite some mails[1], I'm not sure why there would be any need for any "rush". Can't we just let the usual timing apply? 1. https://lists.debian.org/debian-vote/2014/10/msg00319.html KiBi. signature.asc Description: Digital signature
Re: Tentative summary of the amendments
Didier 'OdyX' Raboud (2014-10-22):
> Le mercredi, 22 octobre 2014, 13.34:27 Ian Jackson a écrit :
> > Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> > > I too find it wrong to interpret Ian's text as a war between
> > > systemd and sysvinit - that's anything but "basically fine"!
> >
> > It's only a war between systemd and sysvinit insofar as some of
> > systemd's proponents are trying to abolish everything except
> > systemd, which encompasses abolishing sysvinit.
>
> Can you _please_ point to such attempts or retract your unfounded FUD?
What about no?
Whether Ian is conducting a crusade for freedom/against tight coupling,
or is just unhappy about having "lost" the TC vote, or just acting in
good faith according to his deepest belief… doesn't matter much. Trying
to pin point who said exactly what, whether that's FUD, or just inexact,
or twisted, or whatever… doesn't matter much either.
There were several *thousands* of mails on that topic, it seems far
enough to me.
A GR process has been started, let's let people come up with their
amendments, let's vote and be done with it until the next episode.
KiBi.
signature.asc
Description: Digital signature
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Charles Plessy (2014-10-22): > > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the procedures > for decision making and conflict resolution are working adequately and thus > a General Resolution is not required. > > Seconded. KiBi. signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy (2014-10-19): > --- > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the question > has already been resolved and thus does not require a General Resolution. > > --- Seconded. KiBi. signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna (2014-10-18): > ** Begin Alternative Proposal ** > > 0. Rationale > > Debian has decided (via the Technical Committee) to change its > default init system for the next release. The Technical Committee > decided not to decide about the question of "coupling" i.e. whether > other packages in Debian may depend on a particular init system. > > This GR reaffirms the Debian Social Contract #4, in such a way > that Debian acknowledges the choices made by both the software > developers (also known as upstream developers) and the Debian > package maintainers to provide the best free software to our users. > > Upstream developers considering specific free software (including, > but not limited to, a particular init system executed as PID 1) > fundamental to deliver the best software releases, are fully entitled > to require, link, or depend on that software, or portions of it. > > Debian maintainers' work is aiming to respect the Debian Social > Contract, in such a way to provide our users the best free software > available. > > Debian maintainers are fully entitled to provide modifications to > the free software packages they maintain as per DFSG #3, if they > judge this necessary to provide the best software releases. > On the other hand, Debian maintainers are fully entitled to adhere > to upstream's decisions to require, link, or depend on specific free > software (including, but no limited to, particular init system executed > as PID 1), if they consider it necessary to prevent delivering broken, > buggy, or otherwise incomplete software packages. > > The Debian Project states that: > > 1. Exercise of the TC's power to set policy > > For jessie and later releases, the TC's power to set technical > policy (Constitution 6.1.1) is exercised as follows: > > 2. Specific init systems as PID 1 > > Debian packages may require a specific init system to be executed > as PID 1 if their maintainers consider this a requisite for its proper > operation by clearly mark this in package descriptions and/or > by adding dependencies in order to enforce this; and no patches > or other derived works exist in order to support other init systems > in such a way to render software usable to the same extent. > > 3. Evidence of defects (bugs) > > We strongly reaffirm Debian maintainers are not deliberately hiding > problems (Social Contract #3). No technical decisions shall be > overruled if no proper evidence of defects, issued in the Debian Bug > Tracking system, is found. Fear, uncertainty, and doubt are not > considered as evidence of defects. > > This resolution is a Position Statement about Issues of the Day > (Constitution 4.1.5), triggering the General Resolution override clause > in the TC's resolution of the 11th of February. > > The TC's decision on the default init system for Linux in jessie stands > undisturbed. > > However, the TC resolution is altered to add the additional text above > in sections #1, #2 and #3. > > ** End Proposal ** Seconded. KiBi. signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
gregor herrmann (2014-10-16): > On Thu, 16 Oct 2014 19:24:52 +0200, Stefano Zacchiroli wrote: > > > > As Matthew said, I don't think further lengthy discussion of the > > > issues is likely to be productive, and therefore hope we can bring > > > this swiftly to a vote. This is particularly true given the impact on > > > the jessie release. > > Speaking of which, > > before deciding anything (including seconding it or not) about this > > proposal, I'd like to know what impact a positive outcome of this GR > > would have on the work load of teams whose efforts we badly need to put > > the Jessie release in shape. > > Secon^WAgreed. > > And let me add a question: > What does this GR actually mean in practice? Is it about specific > problems? If yes, which ones (bug numbers)? If not, what else? My personal hunch would be: https://lists.debian.org/debian-devel/2014/10/msg00308.html Mraw, KiBi. signature.asc Description: Digital signature
Re: Both DPL candidates: handling social conflict
Sorry for the slight hijack but: | Date: Thu, 20 Mar 2014 19:29:19 +0100 | From: Neil McGovern | To: debian-vote@lists.debian.org | Subject: Re: Both DPL candidates: handling social conflict | X-Mailer: Apple Mail (2.1874) ^^^ Seriously? Mraw, KiBi. signature.asc Description: Digital signature
Re: GR proposal: code of conduct
Kurt Roeckx (2014-03-06): > On Thu, Mar 06, 2014 at 07:09:49PM +, Ian Jackson wrote: > > Hmm. Looking at my original message in my MUA it says > > Content-Type: text/plain; charset=iso-8859-1 > > which is not right. Perhaps your MUA has done a latin-1 to utf-8 > > encoding, meaning that your copy of the signed file is in a form of > > WTF-8. If so then presumably if my message _had_ been in latin-1 with > > codepoints above 128, it would have been mishandled in the same way ? > > As far as I can tell the problem is that you're not using MIME and > the same problem people have when voting using non-ASCII > characters. Conveniently published not so long ago: http://debian-administration.org/users/dkg/weblog/108 https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ Mraw, KiBi. signature.asc Description: Digital signature
Re: To all candidates: which way out of the project ?
Charles Plessy (20/03/2013): > In Debian, we stay member until we die or quit (or very exceptionally, are > expelled). […] Or spotted as being MIA. This might help: http://wiki.debian.org/Teams/MIA Mraw, KiBi. signature.asc Description: Digital signature
Re: [to all candidates] Accessible software in Debian
Vincent Cheng (18/03/2013): > Slightly off-topic, but since you bring up GNOME 3 as a specific > example of how Debian has regressed in terms of accessibility...how > exactly has GNOME regressed? It still has AFAIK the same set of > accessibility features [1] as it did previously with GNOME 2, and it > is easily accessibly via an icon on the top bar of the shell (you > can't even get rid of it without an extension), and the > gnome-accessibility package is pulled in by a number of other gnome > meta-packages in Debian. Admittedly I myself don't use any of those > features, but I'm curious to know why you consider GNOME 3 not as > accessible as GNOME 2 was (i.e. are they any specific features dropped > in GNOME 3)? For starters, GDM is not accessible: http://bugs.debian.org/694937 Mraw, KiBi. signature.asc Description: Digital signature
Re: Call for vote - Diversity statement for the Debian Project
Amaya (19/05/2012): > The Reply-To isn't set. So what email address should my vote be sent > to? > > Thanks, and excuse the silly question. The vote isn't open yet. Wait for a ballot on dda/dv, from the secretary. ;) Mraw, KiBi. signature.asc Description: Digital signature
Re: [Call for seconds] GR: diversity statement for the Debian Project
Francesca Ciceri (07/05/2012): > TEXT TO BE VOTED STARTS HERE > > The Debian Project welcomes and encourages participation by everyone. > > No matter how you identify yourself or how others perceive you: we > welcome you. We welcome contributions from everyone as long as they > interact constructively with our community. > > While much of the work for our project is technical in nature, we value > and encourage contributions from those with expertise in other areas, > and welcome them into our community. > > TEXT TO BE VOTED ENDS HERE Seconded, with many thanks to Francesca. Mraw, KiBi. signature.asc Description: Digital signature
Re: Question to all Candidates: Who would you vote for?
Hi. Margarita Manterola (24/03/2010): > > Suppose that you would not run for DPL: Who would you vote and > > why? > > I would, and will, vote for all of them. I won't disclose the > particular order, but they'll all be above NOTA. That's a very interesting detail, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Re: Question for all candidates: Care of Core infrastructure
Marc Haber (15/03/2010): > Maybe we failed to provide such a "two-liner", which in fact is, > unfortunately, much more complicated than one might think naively. > Additionally, example code for policy-rc.d is (almost?) nonexistent. Maybe running reportbug would be more efficient than talking about it on -vote@, don't you think? Mraw, KiBi. signature.asc Description: Digital signature
Re: [Amendment] Reaffirm the GR process
(Dropping -devel…) Bill Allombert (23/03/2009): > Hello developers, > > I am hereby proposing the amendement below to the General resolution > entitled "Enhance requirements for General resolutions". > > PROPOSAL START > > General Resolutions are an important framework within the Debian > Project, which have served us well since the first GR vote in 2003, > with 804 developers, nearly has much as today slightly over 1000 > developers. > > Therefore the Debian project reaffirms its attachement to the constitution > and the current General Resolutions process. > > PROPOSAL END Something's wrong, according to <20090322235056.gk4...@halon.org.uk>. Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2009: Call for nominations
Stefano Zacchiroli (02/03/2009): > PS oh gosh, I didn't realize how embarrassing can be to send the >"nominate myself" post until now :) I can guess, especially when one is the first to do so, showing to the whole world how power-greedy one is! :p Mraw, KiBi. signature.asc Description: Digital signature
Re: Results of the Lenny release GR
Robert Millan (12/01/2009): > And I lost count on how many times I repeated that, but will do as > long as necessary. We don't need that kind of behaviour *again*. Mraw, KiBi. signature.asc Description: Digital signature
Re: I hereby resign as secretary
Josselin Mouette (18/12/2008): > Le jeudi 18 décembre 2008 à 08:44 -0600, Manoj Srivastava a écrit : > > 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. > > Regardless of what you did as the Secretary, I fail to see any reason > to forcefully remove you from the project, and I strongly oppose any > procedure started in this direction. This should remain a last measure > for extreme cases. I couldn’t have said that in any better way. Mraw, KiBi. signature.asc Description: Digital signature
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
John H. Robinson, IV (15/12/2008): > I support the right or priviledge of a researcher to run a poll on the > topic of their choosing. I further support the right or priviledge of > a Debian Developer to run a poll on a topic associatied with Debian. > > I support this specific poll. > > Keep up the work. Ditto; thanks dato! Mraw, KiBi. signature.asc Description: Digital signature
Re: Results for Project membership procedures
devo...@vote.debian.org (15/12/2008):
> digraph Results {
> ranksep=0.25;
> "Ask the DAMs to postpone the changes until vote or consensus.\n4.49" [
> style="filled" , fontname="Helvetica", fontsize=10 ];
> "Ask the DAMs to postpone the changes until vote or consensus.\n4.49" ->
> "Further Discussion" [ label="164" ];
> "Invite the DAM to further discuss until vote or consensus, leading to a new
> proposal.\n4.27" [ style="filled" , color="powderblue", shape=egg,
> fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
> "Invite the DAM to further discuss until vote or consensus, leading to a new
> proposal.\n4.27" -> "Ask the DAMs to postpone the changes until vote or
> consensus.\n4.49" [ label="13" ];
> "Invite the DAM to further discuss until vote or consensus, leading to a new
> proposal.\n4.27" -> "Further Discussion" [ label="160" ];
> "Ask the DAMs to implement the changes.\n0.51" [ style="filled" ,
> color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
> "Further Discussion" -> "Ask the DAMs to implement the changes.\n0.51" [
> label="85" ];
> "Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
> fontname="Helvetica", fontsize=10 ];
> }
For those of you who aren't used to graphviz, you can render the graph
using: dot -Tpng results.dot -o results.png
Works with s/png/svg/g as well.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: First call for votes for the Lenny release GR
Thomas Weber (15/12/2008): > http://lists.debian.org/debian-vote/2008/11/msg00046.html Let's quote for people following at home: | >So, we now have a discussion period of two weeks, though I would | > prefer to actually start the vote Sunday 00:00:00 UTC (on November | > 23th, or, if the DPL desires to shorten the discussion period, november | > 16th). | | We've had more than enough discussion about this - please start ASAP. Thomas Weber (15/12/2008): > I read this message as "get over with it as fast as possible", which > is what Manoj is doing here. What was asked is shortening the discussion period, rather than the voting period. Mraw, KiBi. signature.asc Description: Digital signature
Re: First call for votes for the Lenny release GR
Debian Project Secretary (13/12/2008): > >FIRST CALL FOR VOTES FOR THE Lenny Release General Resolution >= === = === === = === === == > > Voting period starts 00:00:01 UTC on Sunday, December 14th, 2008 > Votes must be received by 23:59:59 UTC on Saturday, December 21st, 2008 ^^^ Can we please have a reference to the mail/thread about shortening the voting period? Thanks already. Mraw, KiBi. signature.asc Description: Digital signature
Re: Final call for votes: GR: Project membership procedures
Robert Luberda (14/12/2008): > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > 5efca670-0e7b-480e-9899-ecce3446e087 > > [ 3 ] Choice 1: Ask the DAMs to postpone the changes until vote or > > consensus. > > [ 2 ] Choice 2: Invite the DAM to further discuss until vote or consensus, > > leading to a new proposal. > > [ 1 ] Choice 3: Ask the DAMs to implement the changes. > > [ 4 ] Choice 4: Further discussion > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- And you can't even blame the secretary (team), since the Reply-To was set, this time. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bundled votes and the secretary
Hello DPL, I'd like to point you to the following mail by Raphaël on -vote. It is also available at [1]. 1. http://lists.debian.org/debian-vote/2008/12/msg00038.html Raphael Hertzog <[EMAIL PROTECTED]> (11/12/2008): > Manoj, I still object to voting all at once and I'm convinced that you > will manage to hurt the project by doing that. Ditto. > Honestly, at this point, I would really wish that you retired as > secretary because there have been too many conflicts between you and > various DD while your secretarial work shouldn't be the source of any > conflict. You just have to count the points on each side but you > don't. You insist on deciding alone if something is a change to the > DFSG (when the text doesn't modify it explicitely) while I believe > that only the project at large is able to decide of something like > that. That's why I'd like to put you (leader@) in the loop. You'll find Raphaël's comments below. Could you please comment on the secretary's behaviour? Is he only doing his job, and the right way? Or is there something going very wrong? Thanks for your time. Mraw, KiBi. > That said, here are my comments anyway: > > On Wed, 10 Dec 2008, Manoj Srivastava wrote: > > 41b0a520-c6c1-4e7b-8c49-74ee85faf242 > > [ ] Choice 1: Reaffirm the Social Contract > > "Delay Lenny until all DFSG violations known at 1. Nov 2008 are fixed" > > At least be clear what the choice means. Otherwise it looks like you are > hiding the meaning and trying to get you personal preference (yes you > explained several times that you would probably vote for such an option). > > > [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] > > We're not changing the DFSG. So there's no need for 3:1. > > > [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] > > I followed the discussions but I don't even know why we have this > alternative which looks like the same than 2. > > > [ ] Choice 4: Empower the release team to decide about allowing DFSG > > violations [3:1] > > The full text doesn't use the word DFSG violation. > Maybe: > "Let the release team decide if each known freeness problems should be > blockers" > > > [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise > > The proposition doesn't speak of the GPL in any special way. Neither does > it explain what is required to prove that source code exist for the blob. > So this subject is not appropriate either. > > In fact, I would think it doesn't solve at all the problem of GPL > firmwares. > > > [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1] > > Peter explicitely told that he doesn't want to modify the DFSG. > > Cheers, > -- > Raphaël Hertzog signature.asc Description: Digital signature
Re: Discussion: Are you tal^Wtrolling to me?
Josselin Mouette <[EMAIL PROTECTED]> (17/11/2008): > > > I'm not really pleased with the trolls that arise on the subject > > > prior to every release. > > > > May I ask who are those "trolls" you refer to? > > Maybe Robert Millan? Given his asking “who” rather than “what”, looks like a rather nice candidate. Mraw, KiBi. signature.asc Description: Digital signature
Re: call for seconds: on firmware
Peter Palfrader <[EMAIL PROTECTED]> (14/11/2008): > I'm hereby proposing the following general resolution: > > | Firmware is data such as microcode or lookup tables that is loaded into > | hardware components in order to make the component function properly. > | It is not code that is run on the host CPU. > | > | Unfortunately such firmware often is distributed as so-called blobs, > | with no source or further documentation that lets us learn how it works > | or interacts with the hardware in question. By excluding such firmware > | from Debian we exclude users that require such devices from installing > | our operating system, or make it unnecessarily hard for them. > | > | Therefore the Debian project resolves that > | a) firmware in Debian does not have to come with source. While we do > | prefer firmware that comes with source and documentation we will not > | require it, > | b) we however do require all other freedoms that the DFSG mandate from > | components of our operating system, and > | c) such firmware can and should be part of our official installation media. Seconded. Mraw, KiBi. signature.asc Description: Digital signature
Re: Call for seconds - DC concept (was: Possible amendment for Debian Contributors concept)
Peter Palfrader <[EMAIL PROTECTED]> (29/10/2008): > I hereby propose this alternate option/amendment and am asking for seconds. > > | The Debian Project recognizes that many contributors to the project are > not > | working withing established frameworks of Debian and thus are not > provided by > | the project with as much help as might be possible, useful or required, > nor > | opportunities to join the project. > | > | We thank Joerg Jaspert for exploring ideas on how to involve contributors > more > | closely with and within the project so that they can get both recognition > and > | the necessary tools to do their work. > | > | We realize that the proposal posted to the debian-devel-announce > mailinglist is > | not yet finalized and may not have the support of a large part of our > | community. We invite the DAM and all the contributors to further develop > their > | ideas in close coordination with other members of the project, and to > present a > | new and improved proposal on the project's mailinglists in the future. > | > | Significant changes should only be implemented after consensus within > | the project at large has been reached, or when decided by a general > | resolution. Seconded. Mraw, KiBi. signature.asc Description: Digital signature
Time to create some accounts? (Was: NM Report for Week Ending 06 Apr 2008)
Dear Account Manager(s), On 07/04/2008, NM Front Desk wrote: > Weekly Report on Debian New Maintainers > === > > For week ending 06 Apr 2008. > > Weekly Summary Statistics > = > 0 applicants became maintainers. although some applicants received their DAM approval in the last 4 months, no account got created in the meanwhile (the “0 applicants became maintainers” message has been received each and every week since 16 Dec 2007). I was wondering whether it would be possible for you to think about creating them, so that people could eventually vote for the DPL election this year (2008 at the time of this writing). Thank you for your commitment to the huge and never-ending task of managing the Debian accounts. -- Cyril Brulebois PS: I hope you don't mind a possible duplicate mail, but experience has proven mails sent to some member(s) of the DAM team sometimes get lost. pgpbCK0KEV6GI.pgp Description: PGP signature
Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency
On 17/03/2008, MJ Ray wrote: > Is creating accounts really now a sub-two-minute task? If so, that's > great, but I believed there was still often a lot of multi-step > independent double-checking in that task. If not so, is that sooo long that there are only a couple of runs each *year*? -- Cyril Brulebois pgp1kNoffFrgL.pgp Description: PGP signature
Re: On RC/RG bugs…
Please respect list policies and don't duplicate mails. On 17/03/2008, Thomas Bushnell BSG wrote: > I thought all RC bugs were supposed to have severity "serious" or > higher. Has that been changed? RC != RG. > > You don't read debian-devel-announce, do you? > > Of course I do. What I said was that I must have missed the > announcement. Then please refer (again) to e.g.: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > And what exactly does this have to do with the technical committee? No idea. It looks like it all started with [EMAIL PROTECTED], and since you're still wondering about RC/RG bugs, I'm answering these questions. -- Cyril Brulebois pgp8ZZbMd4K90.pgp Description: PGP signature
On RC/RG bugs…
On 17/03/2008, Thomas Bushnell BSG wrote: > Actually, I'm very good about uploading fixes for RC bugs promptly. > The bugs I think you are referring to were marked severity > "important". Perhaps the bugs were tagged incorrectly? Severity != tag. And the severity is correct. > I must have missed the change in the release goals to require GCC 4.3 > when it came out. If the bug had been tagged "serious" I would have > uploaded the fix as soon as possible. You don't read debian-devel-announce, do you? -- Cyril Brulebois pgpPu53fo9L3x.pgp Description: PGP signature
Re: Question for all candidates: inter-dependancy of works the growing Debian project.
On 13/03/2008, Paul Wise wrote: > Untrue, you just need to get your package whitelisted since non-free > packages may not be legal to autobuild. You need to contact aba IIRC. > Not sure why you don't know about this, nor where the best place to > store this information is, perhaps the NM templates should cover it. FTR, d-d-a: <[EMAIL PROTECTED]>. -- Cyril Brulebois pgpkVft0uk8ef.pgp Description: PGP signature
Re: Raphael Hertzog: When to commit into repositories of teams?
On 09/03/2008, Andreas Barth wrote: > as campaigning has started, I would like to know from Raphael Hertzog > his opinion under which circumstances he considers it ok to commit > into revision control repositories of a team where the person leading > the team is active and asks to not commit. Hi, may I ask whether you have examples in mind, and how you would define “is active”? Cheers, -- Cyril Brulebois pgpGO2p7JUKKX.pgp Description: PGP signature
Re: Constitutional amendment: reduce the length of DPL election process
Kalle Kivimaa <[EMAIL PROTECTED]> (02/08/2007): > Actually, *if* each and every developer formally seconds the > resolution, I think the secretary could forego the actual voting > procedure as blatantly obvious. ``Seconding a GR'' = ``Voting in favour of a GR''? I don't think so. Cheers, -- Cyril Brulebois pgph0rm5SbdZa.pgp Description: PGP signature
Re: Getting patches applied. emulated buildd's are good (was: kFreeBSD is "fantastic")
Drew Scott Daniels <[EMAIL PROTECTED]> (08/03/2007): > guillem's [0] list of bugs [1] shows the main problem for the kfreebsd > porters. 93 "important" (probably release-critical for kfreebsd) with > patches available! 105 bugs with patches not applied. To be fair, 20+ were opened in the last 3 days, and some are already pending or closed (thanks!). But I agree that having some patches sleeping during months (or years) isn't that funny for porters... > Perhaps we can recommend marking bugs as -patch if the patch is no > good? Maybe a user tag or some way of having patches marked as needing > more review? I think if we did these, we'd still see that good patches > aren't being applied but at least we'd be able to help more quickly > identify where work is needed. As a first guess, one could use “patch moreinfo” to ask for help or peer review, though asking the porter/patch submitter for explanations, and eventually the -bsd list, should be sufficient. But I agree that there might be better semantics (set of) (user)tags. Cheers, -- Cyril Brulebois pgp9s8Y3hjprZ.pgp Description: PGP signature
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
Jeroen van Wolffelaar <[EMAIL PROTECTED]> (27/02/2007): > I'd rather have a DPL that can prioritize and spend his time on what > would benefit the project the most [...] Like talking about ponies? -- Cyril Brulebois pgpsMgHYKjhFF.pgp Description: PGP signature
