Re: Changing how we handle non-free firmware
On Mon, Aug 22, 2022 at 06:20:15PM +0200, Bart Martens wrote: > With this GR proposal there would no longer be an installer without those > non-free bits. Would you consider proposing an alternative ballot option, instead of repeatedly stating your dislike of this one? Debian's voting system allows anyone to propose a ballot option that has their position represented, and Steve explicitly invited it. This will lead to a ballot which represents the various positions in the project and allows anyone to rank them. This is a rather beautiful way to turn the conflict of different opinions into value, rather than hostility. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Thu, Feb 17, 2022 at 10:07:18AM +0100, Enrico Zini wrote: > I support this effort, especially after the heat I've seen in the > systemd and RMS GRs, were social dynamics went far beyond the democratic > curiosity of polling where people stand, and strong peer pressure was > considered a valid mean to an end. Given a possible upcoming GR about firmware, I'm wondering if someone working for a large hardware manufacturer might not have more chances to feel free to vote according to their own personal opinions, if the votes weren't publicly disclosed. I'm thinking that Debian as a project might have has scaled up to a level where the outcomes of votes have higher impact than when our process was initially designed. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Sun, Feb 13, 2022 at 02:28:44PM -0700, Sam Hartman wrote: > This starts informal discussion of a proposed general resolution to > amend the constitution. I am not seeking sponsors at this time. > Comments including support or alternatives are welcome. I think this is > mature enough to seek review from the secretary. I support this effort, especially after the heat I've seen in the systemd and RMS GRs, were social dynamics went far beyond the democratic curiosity of polling where people stand, and strong peer pressure was considered a valid mean to an end. I am aware of instances where the vote being public was the major factor that influenced the decision to vote, and the order of options in the ballot, and I find it scary. I am aware of people who for various reasons (that might not be the usual reasons one thinks of) don't enjoy my level of privilege on their online activities and reputation, and I do want their voice to be heard in Debian votes, unfiltered from peer pressure. I like that a number of options have been brainstormed in the discussion: secret ballots, ballots secret on request, ballots public on request, ballots disclosed only to Debian Members, public ballots. I like a GR with a range of options. Thank you for driving this! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: New option for the RMS/FSF GR: reaffirm the values of the majority
On Sat, Apr 03, 2021 at 11:51:29PM +0100, Simon McVittie wrote: > It seems highly likely that the message to which I'm replying was not > sent or authorized by Enrico, and that its sender is trying to mislead > Debian members by impersonating a prominent and respected developer. I can confirm it was not an impersonation attempt. My previous subkeys are due to expire on 2021-06-03 and I've recently generated new ones. They should be properly signed by my master key and I have uploaded them to keyserver.ubuntu.com and keyring.debian.org Using GPG became more complicated recently with the keyserver network collapsing, and on a different venue I'd welcome a serious reassessment of our technical practices of certifying trust :( My proposal was a honest attempt at encoding in a straightforward proposal the gist that I was perceiving from what seemed to me like the majority of posts on -vote. I was honestly interested to see if that represented the feelings of our community at large. If those are indeed the feelings of the majority of a community I'm part of, it is extremely important for me to know. Even so, my proposal, although serious, was motivated mainly by frustration, disappointment, and disgust. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
New option for the RMS/FSF GR: reaffirm the values of the majority
Hello, I think the ballot is missing an option to capture the energy that I've perceived on -vote in the last few days. Title: Reaffirm the values of the majority == CHOICE TEXT BELOW == Debian commits to give priority, resources, and energy, to those who actually get the work done in the distribution. We explicitly refuse to acknowledge irrelevant political issues such as misogyny, ableism, transphobia and all other similar concerns that have nothing to do with the technical work that is the focus of our distribution. We also commit to respecting and preserving the good name of the people who write and maintain the software that we use daily. Should they become the target of accusations that may tarnish their well earned reputation, we will stand behind them and refuse to hold them accountable for anything except the quality of their technical contributions. === Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Announcing new decision making procedures for Debian
Hello Debian Members, For some time, we have been having systemic issues that make GR discussions painful. GRs themselves shouldn't be painful, and don't need to be. Having a chilling effect to using GRs hurts Debian, and as a project we need a way to poll for consensus on project choices and directions more often than not. To overcome the current problems with GR discussions, we introduce a replacement weighted democratic system. The new procedure is this: * A developer proposes an issue with a signed message on debian-vote@lists.debian.org . * Anyone can express their consent or dissent by replying to the message. * When the discussion eventually dies down, the Debian Secretary will review all messages and pronounce the winner. This method makes the fair assumption that the energy spent in writing messages to the discussion is related to the amount of insight a person has on an issue, and how much they care about it. In particular: * The more messages a person writes, the more the person cares, and the more their opinion will be taken into account: people who only write every once in a while, clearly don't think the issue is important enough to deserve their real effort. * The more strongly worded replies are, the more the person cares, and the more their opinion will be taken into account: people who waste time with long, polite, well reasoned messages, clearly didn't care enough to get emotional about an issue. * The longer a person keeps writing, the more the person cares, and the more their opinion will be taken into account: people who give up, clearly didn't care enough to make themselves heard. To avoid confusion, we'll maintain the same acronym as before. The new system will be called Debian Grandiose Reflection. The first GR using this scheme will concern the introduction of this voting scheme for the future. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
On Fri, Mar 26, 2021 at 02:31:28PM -0700, Luke W Faraone wrote: > Myself, I signed this letter based on both public information and the > numerous times I've heard, unprompted, stories from women and > female-presenting people who have had uncomfortable / creepy experiences > with Stallman, in the Debian / free software community, the MIT > community, and elsewhere. > > I have heard first-hand stories from women who were new to the Free > Software movement and, at a conference, were excited to meet its leader > -- only to be hit on by Richard and invited back to continue the > conversation at a residence. These people did not stay in the Free > Software movement, and our community is poorer for it. > > None of those incidents would have turned into a police report, and I'm > not demanding that you rely on it. But it comes up so frequently at > conferences, student clubs, and bar chats from so many different people > that I have little reason to doubt its veracity. > > It's also interesting to note that over 12 former FSF staff, who worked > directly with Richard, also saw it fit to sign the letter. This! Thank you! I have regularly been among people sharing horror stories of what happened when they hosted RMS at some event or another. In my experience there is an unwritten, alternative "RMS Rider", that you should know before hosting/handling him, with things like "don't you *ever* leave RMS alone with a woman!", "avoid mentioning this list of words", "a number of basic expectations of human decency don't apply, and you should be prepared for that". As long as he was in a somewhat official position of guru/leadership, I was part of a community that tried its best to *handle* him, and to *minimize his damage*. I understand that many people close to him tried to talk to him, and that Stallman is about as famous for speaking as for not listening. I believe that all this has held Free Software back significantly. We had finally moved on from having a significant amount of the community energy spent on *handling Stallman*. And now he's supposed to be back "and I'm not planning to resign a second time"? Stallman can certainly *speak* about Free Software. Stallman cannot *lead* the Free Software movement, or any influential part of it. We had moved on, and we had mostly gotten away with it[1]. I don't want to go back. Enrico [1] Possibly we don't deserve it. As a community we had enabled him to be indecent on others for decades! -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
On Thu, Mar 18, 2021 at 09:16:15PM +0200, Jonathan Carter wrote: > I don't think that lack of interest is the problem here, but I do think > that Debian contributors tend to be already starved for time, and trying > to get them to do more is like trying to tap water out of an empty well. > For some, a financial incentive might work if they're not currently > working full time, and especially if they need money, but the median > Debian developer seem capable of sustaining themselves reasonably well. Thinking at how we set our bar for membership in building a reputation within the project, I imagine we implicitly select people who are able to sustain themselves reasonably well without Debian's help. I'm not sure it's something I'd want to change. I see being an employer as a radically different thing than being a volunteer-based project. In practice, I see more than these two options. On the "employer" side, our ecosystem does include employers who pay people to do Debian-related work. While Debian Developer's bills are currently mostly outside of what Debian can or wants to worry about, the Debian ecosystem does include the possibility of doing Debian work and having bills paid. There is also a "contractor" side: without developing the infrastructure to hire people ourselves, we are able to (and do) contract employers (or self-employed people) to do things we need. I'm writing this to suggest that although we can't (and probably shouldn't) take responsibility for Developers' bills, we could have some limited level of control over the financial angle which we might decide to use, to encourage our community to develop towards specific strategic directions we might care about. For example, on the 'employer' side: - Are the possibilities of making a living with Debian work available enough and advertised enough? - While not hiring pepole directly, could Debian encourage Debian as a professional career? - Could (and do we want to) offer infrastructure for that? For example: - a channel for employers active in Debian's ecosystem to post job offers - a channel for advertising Debian contributions that happen during paid time of some employer - a list of important that are currently not getting solved, and that an employer might want to pick up, and get credit for And on the 'contractor' side: - Are the possibilities of contracting external work exploited enough? - Are they clear enough? - Do we need some procurement guidelines? - Do we need procurement know-how and support? (I sometimes have problems for which I could use external help, but I don't know how to find and choose a professional that provides it). I'm not expecting you and Sruthi to answer these questions now: I think that questions to prospective DPLs should be more about vision. To turn this all into an actual question: should Debian consider things like that to be within its problem space? If all goes well and you have a magic wand and everything, how do you see the Debian ecosystem dealing with money problems a few years into the future? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Question to Brian: Why do you need to be DPL to set up foundations?
On Thu, Mar 19, 2020 at 08:53:13PM -0400, Brian Gupta wrote: > I will reiterate this before the election, but people do have choices when > voting. > > 1) If you want Foundations, and want me as DPL, please rank me the highest. > > 2) If you want Foundations, but don't want me as DPL, please just put your > favorite candidate(s) above me, but please do place me above "None of the > Above". > > 3) If you don't want Debian Foundations rank me below "None of the Above". > > The only option I am asking people not to consider is electing me as DPL > without a mandate to work on the Foundations. If you are opposed to the > formation of Debian Formations, I'd ask that you please rank me below > "None of the Above". I am very uncomfortable with the idea of embedding a GR vote in the relative placement of options in a DPL elections. I would like to rank people in a DPL election based on how I would like people to be DPL. That is what I understand our voting system is supposed to do, and what in my experience it has been doing reasonably well. I fear that piggybacking extra meaning into it as you seem to propose, would compromise the quality of the results both of the foundations GR embedded in the election, and in the DPL election itself. As an example of a voting options that I am considering ad that does not fit with your proposals above, I would very likely vote for you above NOTA for a pure DPL election, and I would very likely vote in favour of a GR option to create a Debian Foundation. I would however rank you below NOTA if you insisted in conflating the two, as I cannot endorse what I see as a misuse of our voting system. You would however incorrectly interpret my vote as a vote against the idea of a Debian Foundation, underestimating support for something you care about. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Question to all: Outreach
On Wed, Mar 18, 2020 at 12:03:13PM +0200, Jonathan Carter wrote: > On 2020/03/18 11:58, Enrico Zini wrote: > > Note that another option available to address this, which has been used > > before and isn't used as often as it could, is to ask DAM to have a look > > at the missing membership problem. > > Excuse my ignorance, could you explain what this means? Do you mean that > DAM could be asked to create a more formal level of contributor status > that's not quite yet a project member? I mean that it's DAM's job to help make a person who has a need to be a project member, a project member. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Question to all: Outreach
On Wed, Mar 18, 2020 at 11:36:24AM +0200, Jonathan Carter wrote: > My honest answer? Yes, it would be nice if all the delegates could be > project members, I understand your concern, but often it's best to be > willing to work with people who are willing to do the work. Note that another option available to address this, which has been used before and isn't used as often as it could, is to ask DAM to have a look at the missing membership problem. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Proposal to overturn init systems premature GR
On Tue, Dec 03, 2019 at 04:15:02PM +, Ian Jackson wrote: > I think we can use the constitutional process to delay this, to make I feel that the air in -vote has been getting very heavy in the last day or so, and I was quite happy that Sam opted to cut the pain short and go for a vote. I agree that all the useful options seem to be on the ballot, and I look forward to see what comes out. I would prefer that we didn't start something that looks like meta-discussing options, and meta-discussing whether to meta-discuss options, and so on. Nitpicking on the constitutional process like this looks to me like an interesting move in some competitive board game. I would prefer to see less competition, and more cooperative focus on trying to make Policy unstuck while trying to keep pain to a minimum. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Proposal: Focus on systemd
On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote: > I'd like submit the following proposal: > Proposal: Focus on systemd to promote standardization and cross-distribution > cooperation Seconded. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Question: What would you like to see {more,less} of?
On Thu, Apr 05, 2018 at 10:52:42PM +0100, Chris Lamb wrote: > Indeed, I can imagine them being influenced negatively just as often > as positively; nobody likes to be felt like they are being bossed > around, after all. I wouldn't mind being led, though, especially when the consensus on a direction seems unclear. I guess that's why the election is for a Debian Project Leader, and not for a Debian Project Boss :P Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Question: What would you like to see {more,less} of?
On Fri, Mar 30, 2018 at 04:04:22PM +0100, Chris Lamb wrote: > Therefore, what would you like to see *more* of from a Project > Leader? What would would you like to see less of? Hello Chris, thanks for asking. I'd like the DPL to provide more vision for the project, by occasionally publicly expressing an opinion on the current state of Debian and where you'd like it to go. I wouldn't want the DPL to express their opinion with the expectation that everyone should agree or follow their lead, but more with the idea of giving a sense of direction, to unlock situations that are stalled because there isn't one clear way forward. Sometimes there is a growing itch that might be scratched in several ways, but it's unclear which of those ways is The Debian Way. If I were in the position of doing something about scratching such an itch, I'd probably not do anything because, I don't know, maybe what I'm thinking about is the way forward, maybe nobody cares. With a DPL opinion/vision/hope expressed somewhere, one could say "'s what the DPL said, and it sounds sensible to me, I'll do that", and it might help congealing a sense of direction and purpose. In general, I think that having a prior DPL opinion on a topic helps preventing an issue to escalate to a flamewar if/when it finally becomes urgently relevant. When the energy builds up and there is no clear way forward, I think the energy gets focused on arguing about the way forward[1]. When instead there is a general idea of a way forward, I think it's more likely that the energy gets focused on making it happen. Enrico [1] when in danger or in doubt, run in circles, scream and shout -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Q to both candidates: preventing burnout by other contributors
On Wed, Mar 29, 2017 at 07:19:31PM +0100, Chris Lamb wrote: > However, I still think that by continually and reliably calling it out > in general, even in cases where it is unlikely to worsen, means that > our culture will — in time — change for the better. I've seen calling out mentioned a number of times. Sometimes I feel like the escalation involved in calling out makes sense, and sometimes I feel like an escalation would be unnecessary or unwarranted. For those times, I am fascinated by the idea of "calling people in": https://www.theodysseyonline.com/calling-in-verses-calling-out http://everydayfeminism.com/2015/01/guide-to-calling-in/ https://ofcourseitsaboutyou.com/2014/01/23/calling-out-vs-calling-in-how-activist-techniques-can-be-used-to-decrease-lateral-violence-and-bullying-in-nursing/ Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list
On Fri, Sep 02, 2016 at 11:27:31AM +0300, Lars Wirzenius wrote: > * Whatever else people come up. Require that whoever starts a thread on -private that doesn't have [VAC] in the subject, explicitly states the privacy concerns on the message[1], and disclose accordingly. This could be implemented via other subject tags other than [VAC]. [CUSTOM] could refer to a non-standard situation explained in the mail. Replies to the thread follow the same disclosure policy as the message that started the thread, unless they change the subject tag. The only reply allowed to a message without subject tag is to request a resend with the subject tag. [1] For example: - [KEY] keysigning request: can be forwarded to DDs living in that area - [RETIRE] retiring from Debian: the act of retirement will be disclosed anyway by a keyring change, the reason can be disclosed only if specifically stated - [PERSONAL] private life (of self or another person): only to be disclosed to official biographers - [SEC] security sensitive early discussion: disclose once the threat level is clear - [SNITCH] message contains information acquired from private conversation with X and Y: disclose only after they ACK it - [FUU] message written unthinkingly by instinct, and posted on -private to avoid making a fool of oneself on lists that are publicly archived forever: do not forward message to list and ask a friend to have a quiet word in front of a drink Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Not A GR Proposal: merge debian-private into debian-curiosa
Hello, There are two lists in Debian without a clear topic: debian-private and debian-curiosa, and the only difference between the two lists is on who can subscribe to them and whether they are publicly archived. Since point 3 of the Social Contract says "We will not hide problems", it can be argued (though not by me) that debian-private is just debian-curiosa plus a violation of the social contract, and that this situation must be rectified. I therefore do not propose the following General Resolution: === BEGIN NON-GR TEXT === Title: merge debian-private into debian-curiosa. 1. Any GR mentioning debian-private, starting from the 2005 General Resolution titled "Declassification of debian-private list archives" and up to the time this General Resolution is approved, are repealed. 2. The debian-private mailing list is closed, and replaced by an alias to debian-curiosa. 3. All new Debian Developers will be automatically subscribed to debian-curiosa instead of debian-private. 4. All debian-private archives currently being privately kept on master.debian.org will be merged into the public archives of debian-curiosa. === END NON-GR TEXT === I do not propose this GR, because I believe that although our work does not have a right to privacy, our members do, and there have been, there are, and there will be cases in which an aspect of the personal life of one or more of our members will be up for discussion, so we do need a private list. However, I want to make the point that anyone who finds it effective to rely on the outcome of a GR to enforce the privacy of debian-private, and does not trust for that purpose the judgement of a current or future majority of active DDs, should probably consider not ever disclosing anything private on any piece of infrastructure controlled by Debian. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Broader vision
Hello Mehdi, in your platform there is a section "Vision" that deals with several important practical aspects of Debian. I see the DPL as a person that we choose for a year to give the project a broad sense of direction, to inspire, to keep people's perception of Debian up to date, to tell tales of what Debian has become, to tell tales of the wonders that are about to come. As a thought experiment, suppose that you managed to delegate all the everyday tasks of approving expenditures, facilitating practical decisions, even answering regular lea...@debian.org email, to good and skillful people you can trust. You are then left with the one thing that you cannot really delegate: to inspire. You are on the biggest stage in the project. Everything you are going to say will instantly appear on LWN and at the top of Hacker News, you are going to give keynotes in the most important conferences around the world, participate in strategic meetings where the future of IT is discussed, to see if and how Debian wants to be in it. How do you see Debian right now? How do you imagine Debian to be in one year, when you will be summarizing the recent history in your campaign for re-election? How do you imagine Debian to be in the distant future of IT, say, three years from now? Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 12:50:36PM +0200, Enrico Zini wrote: In nm.debian.org's nightly maintenance I run a lot of code that computes differences between these data sources, so we have the capability of tracking things, and the possibility of manually tweaking nm.debian.org to really fit the bill. But since we have also a need for manual tweaks, it gets out of date. [...] more to be done before this is complete. There's a vague plan to get this done during DebConf if not before. And indeed that'd be the way forward as I see it: reduce the need for manual intervention as much as possible, so that routine takes care of itself, and manual intervention is only needed for corner cases, which are hopefully few and far apart in time. I have now managed to implement some auto-import of changes from the machine-readable commits of the keyring-maint git repo. 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. I'm under no illusion that it will automatically stay this way, as my experience says that there is a fractal amount of corner cases involved. However, as long as automation and further improvements to our procedures mean that the routine is dealt with automatically, the remaining corner cases should be possible to process by hand with, hopefully, more curiosity than effort. It could still all fall to pieces next time there is a mass-corner-case (like a giant key removal commit) that the automation cannot deal with and that can only be fixed by a Small Matter Of Programming, or an accumulation of corner cases that I/we didn't have the energy to deal with and that pile up into more and more daunting piles of changes to process, so this is not a solved problem. It is however, much more solveder than before[1], and we have a plan, at DebConf, to see how to make it better. So, to answer the Secretary's question, I believe that there are currently 988 Debian Developers. We release (numbers) when they are ready. Life is good, or at least, much more gooder. Enrico [1] not having earnt a degree from Oxbridge universities, I do not risk losing it if I write stuff like that :P -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 10:00:56AM +0100, Jonathan McDowell wrote: As far as I know relying on the keyring and ldap has always been incorrect. The number was always off by a few. I've never quite understood why LDAP isn't accurate, but I couldn't figure out a simple query and even '((gidNumber=800)(!(shadowExpire=1))(objeass=debianDeveloper))' gives 988 entries of which some are incorrect. [...] The astute will notice that this leaves 981 keys, whereas I counted 983 keys in the keyrings. It turns out there are 2 DDs who have removed 1024 bit keys but who have locked LDAP accounts (issue with SSH key on one, DSA locked on the other as comments). Anyway. The 2 things to take away are a) yes, it's depressingly hard to work out how many voting members Debian has and b) the answer is 986 at present. Indeed. We have multiple user databases, each with its own sets of corner cases. We cannot currently univocally identify a person by account name (DMs and Debian Contributors do not have one), by alioth account name (a person can have many), by GPG key (a DD can have none, in case they just revoked a stolen one), by full name (hi Brian Nelson(s) and Luca Bruno(s)), by email (it changes). LDAP login can be disabled when one becomes emeritus or temporarily after a case of abuse. DSA can create guest accounts. In nm.debian.org's nightly maintenance I run a lot of code that computes differences between these data sources, so we have the capability of tracking things, and the possibility of manually tweaking nm.debian.org to really fit the bill. But since we have also a need for manual tweaks, it gets out of date. It's was my understanding that DAM says that nm.debian.org is authoritative. That is the eventual goal but at present various pieces of information are manually updated. Enrico and keyring-maint have been working on making it easier for nm.d.o to track keyring changes but there's still more to be done before this is complete. There's a vague plan to get this done during DebConf if not before. And indeed that'd be the way forward as I see it: reduce the need for manual intervention as much as possible, so that routine takes care of itself, and manual intervention is only needed for corner cases, which are hopefully few and far apart in time. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: I get the numbers from nm.debian.org, both at https://nm.debian.org/api and https://nm.debian.org/public/findperson/ Sadly this list is trivially proved inaccurate; the list for Debian Developer, Uploading includes stew who was moved to emeritus back in January: https://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=b768c0a3506631ddeacf4c80ba8f3be6995e8a8f and finger s...@db.debian.org correctly returns no active fingerprint for the user. Copying Enrico who can no doubt comment more about the expected accuracy of nm.debian.org; AIUI it's still a work in progress in terms of being entirely up to date all the time. nm.debian.org is supposed to be the authoritative source, but Debian did not grow with having a single membership database, so in practice it needs to be kept manually in sync with changes coming from LDAP and the keyrings. Examples of membership related changes that can happen without nm.debian.org knowing are DSA adding a guest account, keyring-maint creating a DM (the current workflow skips FD entirely), keyring-maint replacing a key, keyring-maint removing a compromised key. Keeping it in sync manually is work, and I'm the only one who has been doing it. I've recently fallen behind, because syncing DMs from keyring changes is nontrivial[1] work and a lot new DMs piled up, and there is a large amount of 1024-4096 key changes pending, too. Now that keyring-maint has introduced machine-parsable and signed git logs, the sync with keyring can be automated somehow. It's a Simple Matter Of Programming, I already got started, but I'm the only one writing code. After that is done, we're left with the problem of DMs: the current workflow skips nm.debian.org entirely, so the data sources for new DMs are the keyring and RT, and none of them has information about alioth account names, which would be needed for sso.debian.org to work, so new DMs currently require extra manual intervention to be able to log into sites like nm.d.o and contributors.d.o, or DebConf. Also, if we want to be strict and have DAM really responsible and authoritative for new accounts, some of the syncing from DSA and keyrings need manual approval anyway, otherwise keyring-maint and DSA people will be able to create/remove developers without DAM knowing. I do not think that is a risk that we have at the moment, though, but it's a thought. There are ideas flying around. One is that DMs have a name in LDAP, or that the workflow for DM starts by filling in a form on nm.debian.org, which would simplify *a lot* of things, since most of the procedure for becoming DMs is made of mechanical steps. If we're not in a super hurry, we can make this all happen during Debconf at the latest. Or during a DebCamp sprint: we can organise a sprint about that, if there are other people interested in working on it. [1] nm.debian.org needs to have the first/middle/last name split that LDAP has, so I need to work out that split from full names in key UIDs, among other things, which is nontrivial: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Some stats on gr_initcoupling
On Wed, Nov 19, 2014 at 07:54:47PM +0800, Paul Wise wrote: On Wed, Nov 19, 2014 at 7:31 PM, Thijs Kinkhorst wrote: As far as I know Debian does not have a routinely executed exit procedure where inactive DD's are being removed from the set. So looking at the relation between voters and eligible voters doesn't lend itself to interpretation about the interest in this vote by active DD's. To me it would make sense to have such a routine procedure. For security/keyring-management purposes, but also because the constitution takes the total number of developers into account for quorum-related purposes. As mentioned on IRC, DAM used to do WaT (Where are They) runs every so often but haven't done in a long time. Indeed WaT are lagging behind. There were some talking about merging contributors.debian.org and MIA databases at DebConf and get things more streamlined MIA-wise, but I haven't yet managed to follow suite. This said, note that an inactive DD who votes regularly would not be included as a WaT run, because a vote gets counted as activity. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Team health and actions
Hello, here's my question to the candidates[1]: Please name three teams in Debian: 1. a team that works well and in a sustainable way, and how a DPL can bring thankfulness and appreciation; 2. a team that works well but not in a sustainable way, and how a DPL can help bringing sustainability; 3. a team that does not work well, and how a DPL can address the problem. By this I don't mean to imply that a DPL should appreciate and help each team in Debian: let us all be saved from nosy and micromanaging leaders. Still, I see the DPL as a kind of spokesperson-facilitator for the project, and I like the idea of exploring that job description. Ciao, Enrico [1] the DPL campaign seems to be the only time in Debian where you can ask someone to do something and be reasonably confident that they'll do it[2], and I wanted to enjoy this unusual feeling of power for once. [2] I confess: my original idea for this question was please set up a new data source in https://contributors.debian.org/ for a team you know well :) -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org -- 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/20140328082601.ga8...@enricozini.org
Re: GR: Selecting the default init system for Debian
On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote: My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. I would gladly vote an option that says: technically, we trust what the TC says; politically, we are concerned about some of our upstreams' choices. A technical endorsement need not also be a political one. I would like to keep the technical and political issues as distinct as possible, though. I am not interested in spending time evaluating each option to form a technical opinion on what the best choice would be, and I'm extremely happy that the TC are doing that for me. I do have personal opinions on some of the upstreams' choices, but I believe that they should not get in the way of a technical decision. A constructive thing that we may do as a project to address the political side of the matter, is to add to our technical decision a list of things that we wish our upstreams would do to make all our lives easier in the future. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: [all candidates] DPL salary
On Thu, Mar 14, 2013 at 08:50:33AM +0100, Stefano Zacchiroli wrote: Due to time and travel demands, there are blockers in being DPLs. Most of them are work related. Within that category of blockers, some could be solved by a salary but many (according to your judgement) could not. If we agree on this, it means that we are losing many potential good DPL candidates due to those blockers. The broader question is than: what can we do to loose those blockers and profit more from the abilities that we do have in our community? To the problems with paying a DPL, I want to add another one: how does a DPL know they're earning their keep? If I were elected DPL and given a salary, I'd feel compelled to do stuff, or to care too much, even when perhaps the best thing to do would be to do nothing and just trust others to do their job. We've definitely come to expect too much from a DPL, and we need to break that up. It cannot be that we only have one person in the project who holds the big picture, motivates everyone, monitors everything, and does accounting. The way out I can see is delegation. Delegation makes you more involved, gives you responsibilities, holds you up to them. A delegated person can be expected to have a vision of the future of their field, to know what is going on, to ask for help when help is needed, to suggest successors and step down if they become inactive. A delegator's responsibility is to help maintain a high standard among delegates, which doesn't only mean to undelegate them if they don't do a good job, but also to thank them for a job well done, ask for bits from $TEAM posts, have a chat every once in a while about the state of things and give feedback from the outside. A DPL who delegates means more people get involved and responsible. A DPL who is good at all that also sets a nice example for others to follow. We need that: doing delegation right is something that is hard to learn. Count me among the ones who'd eagerly thirst to see a good delegator at work, and take notes. So, besides knowing how to delegate, a DPL would mostly need to be someone who knows who does what in Debian, or knows who to ask in order to find out. And who can tell when they're about to reach their limit, or their day has been difficult enough already, and delegate the right person to take care of that yet another urgent thing that popped up at lea...@debian.org just while they were about to go wear some gloves and clean their bathroom. Or, if you reall want to invest money on this, perhaps we could consider paying someone to do the DPL's housework instead :) Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: [Call for seconds] GR: diversity statement for the Debian Project
On Mon, May 07, 2012 at 08:32:41PM +0200, Francesca Ciceri wrote: 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. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2011: Call for nominations
On Fri, Mar 11, 2011 at 11:27:10AM +0100, Stefano Zacchiroli wrote: /me, fearing more and more that he'll have to throw mud at himself If you end up being the whole candidate, it could be interesting to turn 'talk about the platform' into a 'talk about how to improve on last year (if at all possible)'. ...which might not be just limited to 'things Zack can do better', but also 'things the rest of Debian can do better in order make the DPL do better'. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2011: Call for nominations
On Thu, Mar 10, 2011 at 01:10:18AM +0100, Amaya wrote: Thanks for having me in mind, but I want zack to win again :9 and the mudslinging party at the nomination proccess puts me off, sorry. Thanks for pointing out the mudslinging part. I've always thought it's a completely unnecessary waste of energy that we could really do without. I don't think the DPL election needs more than people presenting their intended agenda and chances to commit to it, and questions asked to clarify details. The rebuttal part I find particularly funny, as it tends to be either I mostly agree with what you say, although I see priorities differently or You're a nutter candidating as a joke but I have to waste half an hour in a strange ritual in which I find some formal diplomatic way to say it. The role of DPL has probably become more clearly defined over time: give talks and interviews, ping people, put people in touch with people. Because of that, I think the process of picking what active member of the project we will particularly listen to for the next year, could do with a lot less drama than we're used to. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Sun, Sep 19, 2010 at 11:33:24AM +0200, Stefano Zacchiroli wrote: The Debian project aims at producing the best free operating system. To that end, the project benefits from various types of contributions, including, but not limited to: package maintenance, translations, infrastructure and website maintenance, porting, bug triaging and fixing, management activities, communication, testing, legal advice, quality assurance, etc. The Debian project acknowledges that: * To pursue Debian goals, package maintenance as well as a wide range of other technical and non-technical contributions are all valuable. * Active contributors of non-packaging work, who share Debian values and are ready to uphold Debian Foundation Documents, deserve the opportunity to become Debian Developers. The Debian project, therefore, invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers, albeit without upload access to the Debian archive. * Establish procedures to evaluate and accept contributors of non-packaging work as Debian Developers. * Initiate the appropriate technical measures to enable contributors of non-packaging work, who get accepted as Debian Developers, to participate in Debian decision making and to access Debian infrastructure. Seconded. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Naming of non-uploading DDs
On Wed, Sep 15, 2010 at 02:40:56PM +0200, Lucas Nussbaum wrote: So, you say that both old and newer DDs sometimes lack packaging skills. This sounds like an acknowledgement of the failure of TS, and the NM process in general, to make sure that DDs have the necessary skills? Please, as requested at the start of the thread, let's stick to the point of this specific GR and not turn this into a broad discussion about NM. I appreciate you have lots of strong opinions about the NM process, although your understanding of it as has become nowadays might not be fully up to date. If you feel compelled to start a broad discussion about NM now, please feel free to do so on debian-newma...@l.d.o. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: GR: welcome non-packaging contributors as Debian project members
On Tue, Sep 14, 2010 at 05:53:46PM +0900, Stefano Zacchiroli wrote: --- The Debian project aims at producing the best free operating system. To that end the project benefits from various types of contributions, including but not limited to: package maintenance, translations, infrastructure and website maintenance, porting, bug triaging and fixing, management activities, communication, testing, legal advice, quality assurance, etc. The Debian project acknowledges that: * To pursue Debian goals, package maintenance as well as a wide range of other technical and non-technical contributions are all valuable. * Active contributors of non-packaging work, which share Debian values and are ready to uphold Debian Foundation Documents, deserve the opportunity for becoming Debian project members. The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers without upload rights to the Debian archive. These new developers shall be recognized as Debian Contributors (DC). * Establish procedures to evaluate and accept Debian Contributors. * Initiate the appropriate technical measures to enable Debian Contributors to participate in Debian decision making and to access Debian infrastructure. --- Seconded. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 02:09:18PM -0300, Margarita Manterola wrote: What are you referring to here when you write Code of Conduct? Do you mean the Debian Community Guidelines (as I guess), or rather http://www.debian.org/MailingLists/#codeofconduct ? Yes, the Community Guidelines. As I've always understood that the idea of these Guidelines is to eventually replace or enhance the CoC, I consider them a draft for a new CoC. I think that they should be validated by a vote, so that we can know if the community as a whole agrees with them or not. However, I don't know why Enrico hasn't submitted such a vote. I didn't because they are more like a list of useful suggestions to improve online communication, kind of like a HOWTO, rather than a policy to be followed. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Draft ballot DFSG #2 applies to all programmatic works
On Fri, Sep 29, 2006 at 11:35:48AM -0500, Manoj Srivastava wrote: Make sure you have read the proposal in detail. A little plea for the next GR discussion season: when people discuss a GR, please keep in mind that the discussion will become material that people would like to read before deciding what to vote. http://www.debian.org/vote/2006/vote_004 says: Please note that this does not include preludes, prologues, any preambles to the resolution, post-ambles to the resolution, abstracts, fore-words, after-words, rationales, supporting documents, opinion polls, arguments for and against, and any of the other important material you will find on the mailing list archives. Please read the debian-vote mailing list archives for details. I do not have time nor motivation to go through the huge debian-vote mailing list archives of the last month. It would be useful if the main proponents of either result would work together (offline? on the wiki?) on a single short text that would summarise both positions in a way that they both think is fair. A few suggestions for trying to have a better list archive next time can found in http://people.debian.org/~enrico/dcg/ , and more specifically in http://people.debian.org/~enrico/dcg/ch02.html Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: Seconded. Overview: The Linux kernel source contains device drivers that ship with firmware files provided by the hardware manufacturer. They are uploaded during the driver initialization to the corresponding hardware device. Some of these binary image files are provided as a hexdump of register bank settings, others consist in fact of compiled binary code which is executed on the hardware device. Any device driver in the Linux kernel is freely available in source format and licensed under the GPL2. For many device drivers with attached firmware, the firmware image is freely distributable along with the corresponding driver. The most common source format for firmwares is the hexdump char array. It is almost impossible to distinguish between register dumps and binary code without asking the device manufacturer who provided the firmware. Removing every firmware which is distributed as hexdump only will cripple the kernel to an extent where it becomes unusable for most of our users, because popular network and scsi devices are among the drivers in question. Without these drivers, the user's system might not be installable at all. The current situation: We achieved a lot of progress compared with the situation in 2.6.8 (the kernel that shipped with sarge). We were able to convince upstream that a firmware loader is a good thing, and that firmware and kernel code should be separated. This firmware loader was added in 2.6.13, and meanwhile, more than 40 drivers have been converted to the new infrastructure. However, this is not yet finished, and some important drivers still use the old method. There will be a day where we can drop the remaining legacy, but we are not there yet. Also, though the firmware loader allows us to put the firmware where it belongs to (main or non-free, depending on the case), the installer can as of now only take udebs from main. Fixing this is not too hard, but it is doubtful whether we can fix this in time for etch, and we do not want to depend on that (and even then, we still would have non-free firmware, see above). But since there is lots of hardware which needs firmware for correct operation, the installer would not work for mainstream hardware otherwise. There are two ways how to deal with it: 1. Accept these issues as transitional issues for now; or 2. Delay etch for some serious time. In our social contract, we promised that the users and the free software community are our priorities. We firmly believe that our users profit very much from releasing etch in time, and that this is important enough that we can accept the transitional status with having a few firmware images left in main that should belong somewhere else. Of course, everyone who wants to make the number of such firmware images as small as possible is welcome to help converting old firmware loaders to the new standard, and working on the Debian installer. We are happy if this issues become smaller or even vanishes, but we do not want this to be a release blocker. So, we propose this GR: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. We want to emphasize that the success of this GR is considered as necessary by the kernel and release team for successfully delivering etch in time (and to allow us a successful planning of that). ...and get Lars tatooed! :) Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote: 4. Finally, if in the context of the release of etch, we need to compromise our ideals and accept programmatic works without source, we should do so by specifically exempting them from DFSG 2 for the purpose of releasing etch by a GR which needs to meet the 3:1 requirement instead of attempting to define ourselves into such a position, especially when source code is clearly a desirable thing to have from our users and our perspective. Thanks Don. I like the proposal, however I'm not seconding it. My position is: sourceless firmware sucks, but at the moment we happen to need it, just like sourceless BIOSes. In this view, I see two problems with your GR: 1. It needs a separate vote to affirm we happen to need it. 2. It would make the exception etch-specific, just like we previously made a sarge-specific exception, and now we have to vote on the same issue again. I understand that the urgent issue is are we ok in having sourceless firmware in etch?, and I think it's a waste of time to vote a GR that doesn't address that. Then, if an exception is to be defined, I'd it to be defined not in terms of some future release we can't predict, but in term of until we can't possibly do without. Unfortunately, my attempt[1] at wording this latter point didn't get it right, and I can't come out with anything better. [1] http://lists.debian.org/debian-vote/2006/08/msg00053.html Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: Hi Steve, I second most of the proposal, however: [...] 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. I'd personally prefer the 4th point to read: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program until it will become practical to do so. This would make it clear that we don't pretend to make fine-line statements on what is a program and what is not; also, it would not rule out the vision of some of us who'd like to see source code for most firmware as well, maybe not in etch, or etch+1, or etch+n, but possibly in etch+n+1. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Question for Ted Walther.
#debian-dpl-debate, last night: 01:44 +TedWalther JeroenVW: also, I've started keeping IRC logs, which include your own prejudiced attitudes. 01:46 +JeroenVW TedWalther: can you prove one quote where I'm discriminating based on religion? Permission to quote granted hereby 01:47 +TedWalther JeroenVW: not in the timeframe of this debate. we can do it later though This list, today: Would you please now produce, in public, to this list, the evidence you stated to have against each person running for DPL, unedited, with information on how developers can find the examples in question in context wherever possible. I suggest you hang out on #debian-devel on IRC for a few weeks and observe. If you have access to logs, then view what happened over the past couple years. I don't have days to spend combing through old logs and stripping out little bits and deciding what bits of context to keep and which to throw away. The information is all out there. The things I mentioned are very real, and very systemic. The behavior is done casually and persistently. For those who read Debian lists through Slashdot, what we're seeing here is a DPL candidate accusing Jeroen, promising to provide evidence, and then being vague when asked to do it. Ciao, Enrico curious to see what the krooger index of Debian instanity[1] will be this year. [1] number of people ranking krooger above NOTA. -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Question for the DPL Teams
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? (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? I joined because I was asked. Generally speaking, I'm happy to help whoever asks me, if I feel it's something I can do. (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? I already have the tickets to Debconf6. I can certainly flip a coin, but when I do there's usually a 33% chance that I fail to catch it and it falls straight to the ground and gets lost in the grass. As a result, the outcomes of a coin toss of mine are 33% head, 33% tail, 33% None of the above/Further discussion. (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? Some things that come to my mind are: - run the IRC session with 24/7 backlog and be able to read discussion that happened when I wasn't online. - bring experience from last year, plus the aftermath of what, in hindsight, could have been done better, and grow from that - pray $deity that the DPL won't go through the same difficult personal events that Branden had to go through (5) How would you rate the importance of your participation on the DPL team compared to your other roles in Debian? I consider it more important to work on debtags and the rest of my packages than to be part of the DPL team. That's because I think that the DPL (and optional team) are a useful extra to all the work that happens in Debian, but the main thing in Debian is the technical work that we all do everyday. (6) Has your DPL team had any meetings already, for which minutes could be published? Not that I've seen. There's an IRC channel where people are gathered, but there's been no formal meeting TTBOMK. My feeling is that there won't be much to do, let alone meetings, unless Jeroen gets elected. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Questions for Jeroen van Wolffelaar and Andreas Schuldei
On Tue, Mar 07, 2006 at 11:40:40PM +, Matthew Garrett wrote: I think this is a poor response. There were several issues that the DPL team could have dealt with and didn't - it shouldn't have taken access to [EMAIL PROTECTED] to realise that, for instance, people had concerns over ftp-master communication, consensus within the project, appropriate reactions to anti-social behaviour and so on. Well, you can't say that I didn't try: http://people.debian.org/~enrico/dcg/ It just hasn't been marketed as a DPL team effort, because it's mainly been my work, it started before the DPL team and will continue after it. But input from being inside the DPL team was indeed useful to bring some parts of it together. Actually it hasn't been marketed much at all, since parts of it still need substantial work. The parts that are most important to me (like the 4 main points) are already there, though. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Reflections about the questions for the candidates
decisions that should have been made suddenly appear clear and easy. The good thing is that we've been having that discussion and we're having that discussion now and there is interesting aftermath coming out. I hope that it can be useful to allow the next DPL to better cope with this kind of things. On Sun, Mar 05, 2006 at 09:49:29AM +0100, Thijs Kinkhorst wrote: I find it very strange that the DPL(team) explicitly calls for all input, then ignores that input, and then complains on -vote that they did not get enough opportunity to tell what they were doing. On Sun, Mar 05, 2006 at 01:16:19AM -0800, Steve Langasek wrote: Uh, for one thing, [EMAIL PROTECTED] != DPL Team. It was Branden's decision to not auto-forward the leader address to the DPL team, so that anyone could feel comfortable contacting leader@ about confidential matters; the flipside is that responsiveness to that address was definitely contingent on Branden's personal availability. I confirm what Steve said. I checked in my dpl team mail archive and there's only one mail from Thijs Kinkhorst, sent to leader@ and jvw@ and bounced (by Jeroen) to the team FYI. It's also the only mail that I have in that archive that doesn't have an answer. On Sun, Mar 05, 2006 at 02:27:36AM +, Martin Michlmayr wrote: Actually, in a recent chatting one of the past DPLs told me that he tried at some point, but the feedback he got was roughly who cares?. Since we talked recently, I'm wondering if you're referring to me. If so, I didn't express myself clearly. Let me know if you're referring to me and I'll try to elaborate what I meant. Yup, that was from my memories of our conversation at FOSDEM: I'm sorry if I have misuderstood or misrepresented you. On Sun, Mar 05, 2006 at 10:44:17AM +0200, Lars Wirzenius wrote: And yes, a couple of times I did ask, although on IRC and not via e-mail. Having to drag out information gets tiresome so I only did it a couple of times. Did you get answers when you asked on IRC? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: DPL reports [was: Re: Reflections about the questions for the candidates]
On Sun, Mar 05, 2006 at 11:05:04AM -0500, Kevin B. McCarty wrote: Hi Kevin. I'm not sure that I understand the reasons why the efforts couldn't be reported, at least to debian-private. Are they one or more of the following, and if so, which? Among your categories, the ones that most apply are: - Not wanting to offend or cause problems for specific Debian developers - Not wanting to discuss efforts before they were likely to come to fruition in some cases, however, it went as far as we had a hard time not to start yelling out insults ourselves, go figure if this hits -private. One of the big roles of the DPL seem to be to address that sort of communication that people for some reason aren't carrying out on their own, and that can't take place on a public (or semipublic) list because lots of people are frustrated about the issues involved and would make a somewhat hostile discussion environment. Or the key people just wouldn't answer on -private for fear that people would inflame, the discussion would turn out useless and their time would be better spent on more practical work. I apologize for perhaps seeming to pry so much. The very vague statements you made about things that can't be disclosed really piqued my curiosity. No problem at all. It sucks to have important discussions happening behind the scenes, actually; besides being generally unfair, one also loses a fair amount of peer support and contributions of good ideas. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Reflections about the questions for the candidates
Hello all, last year I had some fun following the election campaign and the questions to the candidates. This year I'm surprised to discover myself slightly irritated by it. I've been asking myself why, and realised that all these good and polite questions are asked *only* during campaigning. It can be that some questions that are good during campaigning might not be asked during the rest of the year because they might seem irrelevant. It can be that some questions are asked also during the rest of the year, but rarely get an answer because the people who could cluefully answer them are usually busy in something more important. Or because out of frustration they are asked rather impolitely, or targeted at the wrong person. So, what's interesting about campaigning is that for a limited period of time, questions are asked politely and correctly articulated, and the candidates take a break from the usual hacking and commit to answer absolutely all the questions that they get asked[1]. People ask directly and nicely, people answer. Fascinating pattern, should be reapplied! But there's more than that. In the last year as part of the DPL Team, people have been criticising the last year for the lack of reports. But I don't remember a single one sending in a mail like Dear DPL[-Team], what happened last week?. It would have been a pleasure to answer such a question with something like Hi, thanks for asking. It was mainly reasoning about the Security Team, plus approving expenditure of $300 for flying person X to conference Y. That would have been as easy to write in a casual answer as it would have been hard to write wrapped in the officiality of a report: DPL Report for last week 1. Security team Did lots of reasoning about the Security Team. Just like last week, things are tricky, but this week someone came up with a better idea. 2. Budget - Approved expenditure of $300 for flying person X to represent Debian in conference Y. Thanks X for your outstanding work in this field, please make a report when you're back. -- End of DPL report for last week -- It would have been pointless to come out with such trivial reports. Actually, in a recent chatting one of the past DPLs told me that he tried at some point, but the feedback he got was roughly who cares?. It's also worth noting that if something big gets done, then it's likely not to go in a DPL report either, as it'd be usually not in the name of the DPL or of the DPL Team. This is because the job of the DPL is to help getting the work done, but not to get the work done: if a DPL would be enough to get all the work done, otherwise we wouldn't need the thousand DDs plus hundreds of almost-DDs, sponsored maintainers, helpful people and so on that make Debian shine day after day. So, the idea I'm throwing in is to take a little bit of these questions past the campaigning time, and come out from time to time with something like: 'Dear DPL, what do you think are the biggest issues in Debian at the moment, and what ways out do you see?' There's lots of fantasy and smartness going into questions posted to -vote. Part of that smartness could be reused. Ciao, Enrico [1] If we want to test this assertion, I have a polygen grammar that can generate a large amount of questions. :) -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: First call for votes for the GFDL position statement
On Sat, Feb 25, 2006 at 05:21:00PM -0600, Debian Project Secretary wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 25a628e9-d88e-40b7-8e1c-888cff421ea5 [ 1 ] Choice 1: GFDL-licensed works are unsuitable for main in all cases [ 2 ] Choice 2: GFDL-licensed works without unmodifiable sections are free [ 3 ] Choice 3: GFDL-licensed works are compatible with the DFSG [needs 3:1] [ 4 ] Choice 4: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: First call for votes for the GFDL position statement
On Mon, Feb 27, 2006 at 01:42:51PM +0100, Enrico Zini wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Ops, mistake. Which in a way was good because I noticed a mistake in my choice. So I now resubmitted the vote, with corrections, to the right address :) Ciao, Enrico who had thought he had waken up already, but found out that he hadn't -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Question for Andreas Schuldei and Branden Robinson
On Tue, Mar 08, 2005 at 09:36:41AM +0100, Sven Luther wrote: On Mon, Mar 07, 2005 at 08:39:22PM +0100, Enrico Zini wrote: I can't think of a precedent of boycott, so I'll make one up. Let's say for example that James Troup, a key person in Debian who is employed full-time by Canonical, has the idea of making Ubuntu better by making Debian worse, and starts boicotting Debian by blocking packages in the NEW queue. You could take the whole pure64 mess as example :) Since it was strongly vetoed against in debian by the infrastructure guardians, but ubuntu does it just fine. Or other nice ideas like the source-only uploads which are done in ubuntu, but rejected in debian. I am not saying that these are boycott or influence results. So what are you saying then, that my example was not good enough? ;) Besides joking, I understands your frustration. Luckily those examples, both mine and yours, are just some of the everyday problems that Debian has to solve as part of its growing up and moving on. I think those are areas where we should focus our efforts, but I think that creating conspiration theories outside of debian-curiosa is not the best way. A better way, I think, could be starting to collect and organize facts, so that the same things are not discussed over and over again. Is there, for example, a reasoned wiki page with, say, the TODO-list of reasons why pure64 thing is still a mess? Or a wiki page with the reasoned TODO-list of reasons why we aren't doing source-only uploads? That can be used to remember shouters of the problems still to be solved before shouting again, and to remember the shouted what problems have already been solved and that the shouters are not only shouting. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
subscribe
subscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
