Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, Apr 18, 2021 at 06:58:49PM +0100, Barak A. Pearlmutter wrote: > If the winning option in an election is part of a preference cycle, > then it (by definition) has the property that there exists some other > option that a majority of the voters preferred. In some elections that > is unavoidable: we need to pick one DPL, and if they're in a cycle so > be it; if there's a tie we can just toss a coin. But in others, like > the RMS GR, it seems like it would be a rather bad property and we'd > be better off treating it as FD and trying again later. > For info, we use cloneproof Schwartz sequential dropping to resolve these ties. The simple version is that we work out the cycle, and then drop the lowest margin, in this case the 1, so "Debian will not issue a pubilc statement" would still win. A full description is at https://en.wikipedia.org/wiki/Schulze_method Neil signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
Please, as a previous vote runner, can we only have 5 seconders rather than the (currently) 82 DDs who have signed it so far? On Wed, Mar 24, 2021 at 01:54:16PM -0700, Steve Langasek wrote: > Text of GR > > The Debian Project co-signs the statement regarding Richard Stallman's > readmission to the FSF seen at > https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md. > > The text of this statement is given below. > > Richard M. Stallman, frequently known as RMS, has been a dangerous force in > the free software community for a long time. He has shown himself to be > misogynist, ableist, and transphobic, among other serious accusations of > impropriety. These sorts of beliefs have no place in the free software, > digital rights, and tech communities. With his recent reinstatement to the > Board of Directors of the Free Software Foundation, we call for the entire > Board of the FSF to step down and for RMS to be removed from all leadership > positions. > > We, the undersigned, believe in the necessity of digital autonomy and the > powerful role user freedom plays in protecting our fundamental human rights. > In order to realize the promise of everything software freedom makes > possible, there must be radical change within the community. We believe in > a present and a future where all technology empowers – not oppresses – > people. We know that this is only possible in a world where technology is > built to pay respect to our rights at its most foundational levels. While > these ideas have been popularized in some form by Richard M. Stallman, he > does not speak for us. We do not condone his actions and opinions. We do > not acknowledge his leadership or the leadership of the Free Software > Foundation as it stands today. > > There has been enough tolerance of RMS’s repugnant ideas and behavior. We > cannot continue to let one person ruin the meaning of our work. Our > communities have no space for people like Richard M. Stallman, and we will > not continue suffering his behavior, giving him a leadership role, or > otherwise holding him and his hurtful and dangerous ideology as acceptable. > > We are calling for the removal of the entire Board of the Free Software > Foundation. These are people who have enabled and empowered RMS for years. > They demonstrate this again by permitting him to rejoin the FSF Board. It > is time for RMS to step back from the free software, tech ethics, digital > rights, and tech communities, for he cannot provide the leadership we need. > We are also calling for Richard M. Stallman to be removed from all > leadership positions, including the GNU Project. > > We urge those in a position to do so to stop supporting the Free Software > Foundation. Refuse to contribute to projects related to the FSF and RMS. > Do not speak at or attend FSF events, or events that welcome RMS and his > brand of intolerance. We ask for contributors to free software projects to > take a stand against bigotry and hate within their projects. While doing > these things, tell these communities and the FSF why. > > We have detailed several public incidents of RMS's behavior. Some of us > have our own stories about RMS and our interactions with him, things that > are not captured in email threads or on video. We hope you will read what > has been shared and consider the harm that he has done to our community and > others. > > End Text of GR I second this GR. Neil -- signature.asc Description: PGP signature
Re: What are your thoughts on discourse?
On Wed, Mar 18, 2020 at 10:05:58PM +0200, Jonathan Carter wrote: > (since it's a test site I guess that might be invalid one day) It is very, very likely to be invalid in the coming weeks/months. I shall endeavour to copy any replies to the topic over to this list for posterity. Neil signature.asc Description: PGP signature
Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?
On Thu, Mar 19, 2020 at 12:57:55AM +0800, Martin Michlmayr wrote: > * Louis-Philippe Véronneau [2020-03-18 12:52]: > > Would you care to elaborate on what "the Yorba determination" is? I > > couldn't find anything online about this... > > There was a time when the IRS didn't approve any new 501(c)(3) > applications for open source related organizations and basically put > them on ice. > > I thought this got resolved though in the meantime (years ago). > > https://blogs.gnome.org/jnelson/2014/06/30/the-new-501c3-and-the-future-of-free-software-in-the-united-states/ > https://opensource.org/node/840 > The two links from Martin are probably the best background reading. the tldr versions is: making FOSS is not enough to gain 501c3 status by itself. Neil -- signature.asc Description: PGP signature
Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?
Hi Brian, On Wed, Mar 18, 2020 at 12:53:10AM -0400, Brian Gupta wrote: > > I understand coming up with a solid business plan for a "Debian > > Foundation" is not something that can be done in a few weeks. > > You are correct. It's going to take 6-12 months of work to create the > foundation, > and that includes drafting by-laws. > Just to confirm here, are you proposing the creation of a new 501(c)(3) public charity? If so, how have you considered the impact of the Yorba determination (which took 4 years) on the ability of Debian to create a new 501(c)(3)? Thanks, Neil signature.asc Description: PGP signature
Re: Question Under Proposal D: Compile Time Option
On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote: > On 11/29/19 11:32 PM, Sam Hartman wrote: > > Imagine that we have a program that has compile time support for systemd > > and for other mechanisms. It provides enhanced functionality when built > > against systemd, but when so built, it cannot run without systemd. > > > Is this a real life case (if so, please name the package...), or just a > pure fictional one, just because you love debating? > Or a hypothetical one, but one which could be fairly reasonable to expect. This GR seems to be trying to put in place a statement on what exactly we mean by support, and so considering things which may reasonably happen in the future is something that we should do. I don't find your phrasing as a binary choice useful, and ascribing motives to Sam seems disingenuous. Neil -- signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Fri, Jul 15, 2016 at 11:14:45AM +, Thaddeus H. Black wrote: > (However, if this copy, too, does not appear in the web archive, then > I will ask listmas...@lists.debian.org or file a bug as appropriate.) > Your (new) mail does now appear publically accessible to all who search for it in the list archives. Your opinion is on record. > Margarita: > > The only gendered word left is the Chairman of the > > Technical Committee. > > Good. I am glad that one word is still left. The > English language does not want "ungendering." > > Your General Resolution will probably pass by a 10:1 > margin, but I mean to vote no. > Personally, I hope that it passes with a 100:1 margin, and encourage all voters to approve this GR with an overwhelming majority. Neil signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Fri, Jul 08, 2016 at 03:27:56PM +0200, Margarita Manterola wrote: > === 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 === Seconded. Neil signature.asc Description: PGP signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, Jul 07, 2016 at 03:37:08PM +0200, Nicolas Dandrimont wrote: > === 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 === Seconded. Neil -- signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2016: Call for nominations
On Sun, Mar 06, 2016 at 06:53:12PM +0100, Lucas Nussbaum wrote: > On 05/03/16 at 23:33 +0100, Debian Project Secretary - Kurt Roeckx wrote: > > Hi, > > > > According to the constitution (5.2. Appointment), project > > leader elections should begin "six weeks before the leadership > > post becomes vacant, or (if it is too late already) immediately." > > Hi, > > We might have a small procedural problem here: AFAIK the term of > the Secretary expired on 2016-02-19[1], and the Secretary was not > re-appointed (secretary terms last one year according to the > constitution, see 7.2). > > Just to be on the safe side, we probably should have the DPL > quickly re-appoint the Secretary. > I did this on 3rd Feb, but it seems this didn't go to -project... Anyway, consider Kurt re-appointed. Neil -- signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2016: Call for nominations
On Sat, Mar 05, 2016 at 11:33:33PM +0100, Debian Project Secretary - Kurt Roeckx wrote: > The new project leader term starts on Friday the 17th of April, > 2016. The time line looks like: > > | Period | Start| End| > |+--+| > | Nomination | Sunday, March 6th, 2016 | Saturday, March 12th, 2016 | > | Campaign | Sunday, March 13th, 2016 | Saturday, April 2nd, 2016 | > | Vote | Sunday, April 3rd, 2016 | Saturday, April 16th, 2016 | > Just for avoidance of doubt, I do /not/ intend on re-standing for my post. I would encourage any candidates to put themselves forward. Neil signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Sat, Mar 21, 2015 at 05:50:06AM +, Anthony Towns wrote: On Fri, Mar 20, 2015 at 08:13:22PM +, Neil McGovern wrote: On Fri, Mar 20, 2015 at 08:58:35PM +0100, martin f krafft wrote: Why? What target level are you aiming for and what's the rationale? Hopefully https://lists.debian.org/debian-vote/2014/03/msg00308.html helps explain :) This says: ] I would be much more comfortable with about 40k in reserves to ] start with, rather than the 100k we have now, But that figure's awfully close to the $36k seed value from the DebConf 14 budget -- http://media.debconf.org/dc14/report/DebConf14_final_report.en.pdf How do these fit together? Does this imply that Debian should provide a much smaller seeed to debconfs (which might be okay if debconf sponsorships can be collected earlier, maybe), or something else? The 40k of reserves is basically for unidentified future spending needs, I've already assumed that DebConf seed funding can exist in 20150320183901.ga6...@halon.org.uk. If there's known funds we're committing to, then that's not a general reserve. I'd rather not spend the time to put together a full budget during the campaign period, especially as DDs don't have access to the full picture as far as I can tell, but I can do so if you think it would be valuable? Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Sat, Mar 21, 2015 at 09:13:10AM +0100, Lucas Nussbaum wrote: On 20/03/15 at 20:02 +, Neil McGovern wrote: On Fri, Mar 20, 2015 at 08:56:23PM +0100, martin f krafft wrote: also sprach Neil McGovern ne...@debian.org [2015-03-20 19:27 +0100]: I'd be more sympathetic to funding someone (perhaps via an internship, or gap year student who's going on to accountancy) to help set up a system so we can track it easier, but only if we woudn't be wasting their time with them simply pinging TOs for data, and not getting replies. Let's assume they'd be wasting time pinging TOs for data and not getting replies. What would you do in that case? If a TO can't give us useful data about income and expenditure in a timely manner, that's not acceptible. We should drop the TO unless improvements happen. As it has been mentioned before, SPI has been struggling with that for a long time now (since before my terms). They seem to be mostly caught up at the moment, or perhaps there's some other information you're seeking that has not been forthcoming? Does the above mean that, if elected, you will drop SPI from our TO? Which other TO would you then use to keep our funds in dollars? What about non-monetary assets? I think you've unintentionally set up a straw man here. However, answering in general, there's a number of organisations around the US who are able to offer similar services should an evaluation be required[0]. Neil [0] http://flossfoundations.org/foundation-directory -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Fri, Mar 13, 2015 at 12:08:02PM +0100, martin f krafft wrote: also sprach Lucas Nussbaum lu...@debian.org [2015-03-12 10:16 +0100]: All candidates: how will you reconcile that with the fact that the DPL currently only has a limited vision of what funds are available, and how they evolved over time? All candidates: what do you think about outsourcing some of the gruntwork related to accounting and treasury to professional agencies? The goal here would be to free up our volunteers to develop Debian and actually force us into more discipline. My general rule on expenditure is: 1) Is it important that it happens? 2) Is the cost sensible? 3) What problems will we have if we don't spend the money? 4) If it was my /personal/ bank account, would I want to spend that money? If that all passes, then sure, let's spend it. In this particular case, my main concern is that we don't have the input data available to a bookkeeper, or accounting agency. What we're doing isn't /that/ complicated in terms of finance, we don't have multiple cost centres, or particular investment portfolios. I'd be more sympathetic to funding someone (perhaps via an internship, or gap year student who's going on to accountancy) to help set up a system so we can track it easier, but only if we woudn't be wasting their time with them simply pinging TOs for data, and not getting replies. Neil -- signature.asc Description: Digital signature
Re: Q to Neil: PPA
On Sun, Mar 15, 2015 at 09:57:28AM +0100, martin f krafft wrote: Neil, in your platform, you advocate PPAs and modernising our build and infrastructure. What's the DPL's role in this? Or, put differently, couldn't you just start working on this without the DPL hat? Why not? What's the difference here? I think this to be two-fold. Firstly, by putting it explicitly in my platform it makes it clear that it's a high priority item for the project if I'm elected as DPL. If people don't view that as something important, than that's fine too - we have other candidates who I'm sure would love your first preference vote :) Secondly, the DPL position holds the ability to influence external parties more than others. The conversations we can have to try and get external interest in getting this (finally) off the ground is much easier as DPL than not. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: dropping SC §5
On Fri, Mar 13, 2015 at 05:01:57PM +0100, Stefano Zacchiroli wrote: Dear candidates, do you think the time is ripe for dropping section §5 of the Debian Social Contract [1], namely Works that do not meet our free software standards or should we wait more? I don't think it's time to drop this section. There's a balance to be struck between encouraging use of free software, and a more ideologically purist view that only free software should exist. In the latter case (one which the FSF has been characterised as supporting, possibly unfairly at times) then it's an absolute position. However, I think this does a disservice to the users, and free software in general. I would rather Debian is spread, and more people use free software that may require non-free works, than to reject them completely. This doesn't mean we shouldn't strive to make §5 obsolete! Great work has been done to try and remove non-free blobs from the kernel, for example. I would love to run Debian on all systems without the need for firmware on open hardware, but that day has not yet come. Until it does[0], we should keep section 5. Neil [0] I genuinely believe that this will happen, one day. But it certainly isn't going to be in the immediate future. -- signature.asc Description: Digital signature
Re: Q to all candidates: fundraising
On Fri, Mar 13, 2015 at 12:09:37PM +0100, martin f krafft wrote: Question(s) to all candidates: What is your perception of fundraising in and around Debian? Short of DebConf (and more recently Outreachy), we don't do anything of significance. If anything, what changes would you like to help implement? I don't think that Debian has ever really needed to raise funds in a significant way, for ongoing costs at least. Also see Gergely's answer for general ideas around fundraising, he's picked up on some of the main ideas I would look for in dedicated fundraising (matching, stretch goals etc all work well). Again though, if there's something that someone wants to do to improve what we do, then let's do that. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Fri, Mar 20, 2015 at 08:56:23PM +0100, martin f krafft wrote: also sprach Neil McGovern ne...@debian.org [2015-03-20 19:27 +0100]: I'd be more sympathetic to funding someone (perhaps via an internship, or gap year student who's going on to accountancy) to help set up a system so we can track it easier, but only if we woudn't be wasting their time with them simply pinging TOs for data, and not getting replies. Let's assume they'd be wasting time pinging TOs for data and not getting replies. What would you do in that case? If a TO can't give us useful data about income and expenditure in a timely manner, that's not acceptible. We should drop the TO unless improvements happen. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Fri, Mar 20, 2015 at 08:58:35PM +0100, martin f krafft wrote: also sprach Neil McGovern ne...@debian.org [2015-03-20 19:39 +0100]: However, let me be clear: I intend on spending /more/ than that surplus. I would like our reserves to be at a lower level than they are now. Why? What target level are you aiming for and what's the rationale? Hopefully https://lists.debian.org/debian-vote/2014/03/msg00308.html helps explain :) Also, you intend to spend more than surplus, which at the moment you could. What about next year's DPL, or the year after that? Future DPLs could chose to also fundraise, or spend in different areas. I'm not going to carry a large reserve now, because there may be future unspecified needs, especially when history has shown that we're not that these future needs don't seem to occur... Perhaps for clarity: This is /not/ a sustainable funding stream. We have reserves which I believe are too high for our income/expenditure, and I believe that should be spent to further the project. This isn't something that should be used for long term commitments with a unavoidable recurring cost. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Fri, Mar 13, 2015 at 08:06:26PM +0100, Stefano Zacchiroli wrote: On Fri, Mar 13, 2015 at 06:44:45PM +, Neil McGovern wrote: * Outreach. Every team complains (quite rightly!) about the lack of people to do the work. Yet we seem to be rather poor at actively recruiting people to come and do things for us. Outreachy is a great initiative, and I would love to see a Debian Apprentice scheme (though that's probably a bit of a stretch goal!) So, to be clear: would you authorize to use regular Debian funds to sponsor Debian participation into Outreachy (which costs ~6000 USD per intern), rather than going necessarily through dedicated fund raising campaigns at each edition? Not quite. I'd basically guarantee a minimum number of slots, but still expect the fund raising to take place. Essentially, Debian would be the backer in case there's not enough funds raised. Considering that there are 2 Outreachy sessions per years, how many slots per year do you think it would be sensible funding on general Debian funds? Speaking to Tom (who's running around and seems to be doing most of the leg work from what I can see), 2 per session, 4 total per year would be preferable. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: DebConf orga
On Fri, Mar 13, 2015 at 12:03:07PM +0100, martin f krafft wrote: What is your perception of DebConf and its organisation? If any, what changes would you like to implement? The history of the DebConf team is long and varied, and has changed quite a bit since I was involved. (Note: background follows, feel free to skip to [TLDR]) From DebConf 3 (I think) it was basically organised on an ongoing basis by one key person, Andreas Schuldei. It became apparent as DebConf grew bigger that this wasn't sustainable, and the team started to grow. At DebConf 6, the 'local' team concept started to arrive, but unfortunately it was basically just Gunnar Wolf, who did an incredible job considering it was just him, and he didn't even live in the same city as the venue! Although involved in DebConf 6, I was one of the local team and main orga team for DebConf 7. At that point, discussions started about if DebConf should be part of the main Debian project. At the time, there was some resistance to doing so, mainly due to fund raising and how we spend money. Fast forward a few years, and we have the DebConf chairs, and the DebConf team, which are different. This seems to have split the difference between the two. Organising DebConf is something that is a HUGE amount of work. There's considerations to bid again for Cambride in future, and I'm still wary about this after 2007! This leads to the inevitable burn out that's all too common from high stress positions in Debian. However, it seems at the moment the DebConf team have organised themselves to beta-test a newer way of working, with sub-teams and leads. I'm hopeful that this will work out, and enable a more long term team to emerge. [TLDR] So, in summary, I'm basically happy to leave it up to the delegated chairs to tell me if there's problems with the new set-up, and what they'd like changed if anything. Neil -- signature.asc Description: Digital signature
Re: Thoughts/questions for any candidate
Hi AJ, (A fair amount of snipping follows, but hopefully there's still the context :) On Fri, Mar 13, 2015 at 01:20:15AM +, Anthony Towns wrote: the DPL position is /the/ optimal place to be in Debian if you want to be innovative. Is it fair to expect cool new innovations within Debian if all the attention goes to someone who's not doing cool new stuff? So, specific question: do you also see this as problem worth attending to? Do you have any solutions in mind? (Possibly not directed at me, but I'll answer anyway) Similar to in any organisation, there's a (in my opinion) somewhat skewed emphasis on the leader/head of that organisation providing the progress. My view is that it's essential that the DPL highlights the extremely cool things that the rest of the project is doing. Huge kudos here to the publicity team for helping raise some of that, and highlighting the work that goes on around the project. Personally, I'd like more people involved here, but 'more people' is a constant cry from lots of places :) I believe that the DPL role can help show what Debian is doing as a project as a whole, but should also make sure that sufficient kudos is shared around to others. Slightly tangentially, I think it's a shame that the thanks.debian.net/thank-you.debian.net has disappeared, it's a great tool for sharing the appreciation of users and fellow developers in the project. Number two is something in that nature of how to share the DPL's workload. I think this is widely acknowledged as a challenge, eg: I have three thoughts on that. First is that (I believe) one of the biggest workloads for the DPL is conflict resolution/mediation. But there's recently been some talk about the tech ctte addressing that same issue eg [1], [2]. It's obviously an open question whether it will work or not, but I'd be interested to know if the DPL candidates are thinking of trying to help make it work, and (if/when it does) to refer folks to the ctte freeing up DPL-time for other things? Firstly, I'd try and encourage the two people to actually talk to each other, be it in person, via $favourite_telephony_video_conference or whatever. As I'm sure everyone is aware, there's substantial difficulties in portaging subtlety in text based communications, and a reminder that there's a person on the other side of an email address is often useful. The old adage is that It's hard to stay mad at someone you've been drinking with. That said, I'm not sure that the tech-ctte itself is the correct place. What a good mediation needs is: * Both parties to want to come to an agreement, not simply win their argument * Someone to help facilitate that who is trusted by both sides. Some times, the former doesn't happen, which leads to arbitration. For the latter though, we need people who are willing to do it, and would be seen as acceptable. Currently, that's a rather small pool (DPL is the default choice) but I would certainly be interested in handing over that to others who are interested and willing. We've had a number of people step down from the committee recently, and a few new people who have shown interest and great skill at coming to agreements. I'd like to first see if they'd be interested in helping out with this role. There have been lots of ideas on how to scale the DPL role. At some point, we need a DPL who'll take one of the previous ideas that worked a little, improve it only slightly (ie, so it's still recognisable), and turn it into a tradition that can keep improving. Any chance of that happening this year? Sure. I'm keen to try and make the DPL job more sustainable. That was my primary concern when deciding to run the first time, and also this time. However, the road to hell is paved with good intentions. So, I intend to offload whatever I can get away with from the DPL job. (A slight footnote: I think the DPL should still be accountable to make things happen, but not to do those things themselves. I'd like to try and devolve away tasks, but still make sure they're happening) Third is just this: there are two people who've just volunteered (more or less) a year of their life to helping enable other folks make Debian awesome who aren't going to be elected DPL. AFAICT you've all got compatible ideas and can work together okay. So, if you're DPL, how are you going to enable the two losing candidates to enable others and otherwise do awesome leadery things? If people want to do things that benefit Debian, then they should be able to get on with it. If that needs any help from the DPL in terms of delegations, or funds, or just a section in a bits mail to help draw attention to it, then let's do that. I want to enable people to try new things, we should embrace this in Debian. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Thu, Mar 12, 2015 at 11:07:21PM +0100, Martin Zobel-Helas wrote: Will you revoke 20131008134615.ga19...@xanadu.blop.info or do you think this authorization is useful? From what I can see, it seems sensible to have this in place. If DSA doesn't like it, or would like it changed of course, then we can do that too. Neil -- signature.asc Description: Digital signature
Re: Q to all candidates: spending money
On Thu, Mar 12, 2015 at 10:16:45AM +0100, Lucas Nussbaum wrote: Hi, In his platform, Neil wrote: I will spend some money we have horded. Debian currently holds approximately $200,000 at SPI alone. Our donators didn't give us money for it to be sat around in a bank account, we should spend it to make the project more successful. Neil: how will your approach to that be different from what was done in the past? On what additional things specifically do you plan to spend that money? This has been an issue for a while in Debian. See Steve's talk in 2009 in Spain: http://meetings-archive.debian.net/Public/debian-meetings/2009/debconf9/high/1058_Money.ogv (You also get to see a younger version of me running around with a microphone...) Some simple things I would be interested in: * Publicity/events. If we need a banner for a stall, lets get one. If we need some nice leaflets etc about Debian, we can get some printed. * Meetings. Sprints are great, and it's fantastic to see those being promoted for DebCamp. Our main conference each year is DebConf, and I would be happy to provide the float so that people can get travel sponsorship (for example) confirmed earlier. * Outreach. Every team complains (quite rightly!) about the lack of people to do the work. Yet we seem to be rather poor at actively recruiting people to come and do things for us. Outreachy is a great initiative, and I would love to see a Debian Apprentice scheme (though that's probably a bit of a stretch goal!) All candidates: how will you reconcile that with the fact that the DPL currently only has a limited vision of what funds are available, and how they evolved over time? Interestingly, in 2009, we had over 100k USD. We're quickly approaching double that. We have the large picture of how much we get in and spend, I don't think there's a risk of running out of money any time soon. Neil -- signature.asc Description: Digital signature
Re: increasing maximum ctte size
Even if it were as ready, I wonder if it wouldn't be better to have a separate GR. Voting once instead of twice is nice for everyone, but conflating two separate decisions in a single GR has been proven to be unwise in the past. And I'm especially wary of doing so with a constitutional change. Secretary: can you share your thoughts on this last point with us, what would be best from the ballot preparation POV? If you think you want this as a separate option, I would suggest an amendment to your original text and not accepting it. This way people could (with condorcet) choose between the two. Neil -- 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/c340dadd-fd1f-42af-ba0d-510346d6e...@halon.org.uk
Re: Maximum term for tech ctte members
On Mon, Nov 03, 2014 at 09:52:39PM +, Sam Hartman wrote: Sune == Sune Vuorela nos...@vuorela.dk writes: Sune I read the logs from the tech-ctte meeting, and my impression Sune was that - people in tech-ctte thinks that maximum terms are a Sune good idea - that they should push the thing forward (if no one Sune else does) - but they should wait with doing it until the Sune current GR is over nod. My concern is one of process, not any strong disagreement with opinions expressed. Neil's message (and note he's also not a TC member) represented things as a decision having been made in that TC meeting. Indeed, apologies, I was spending about 4 hours last night setting up the current vote. The intention was to try and re-assure that it's not been forgotton about! Personally, I agree that having multiple active discussion/second periods on debian-vote is problematic. For myself, I think midway through the voting period of the current GR will clear up this list enough that starting to collect seconds on a new GR seems fine, but I'm happy to delay beyond that if a significant number of people think that's valuable. I'd personally prefer it happening after this vote is concluded, but will endevour to set up a GR if that's what happens. Neil -- signature.asc Description: Digital signature
Re: Results for init system coupling
On Tue, Nov 04, 2014 at 02:43:13PM +, devo...@vote.debian.org wrote: This message is an automated, unofficial publication of vote results. Official results shall follow, sent in by the vote taker, namely Debian Project Secretary Whelp, that wasn't meant to happen. Apologies for the spam. Neil -- signature.asc Description: Digital signature
Call for Votes: General Resolution: Init system coupling
This is the first call for votes on the above GR. PLEASE NOTE: voting is not yet open. Voting period starts 00:00:00 UTC on Wednesday, November 5th, 2014 Votes must be received by 23:59:59 UTC on Tuesday, November 18th, 2014 The following ballot is for voting on init system coupling. This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions or problems contact secret...@debian.org. The details of the general resolution can be found at: http://www.debian.org/vote/2014/vote_003 NOTE: the ballot below is a very short summary of each option. Voters are strongly encouraged to read the full options at the URL above. Also, note that you can get a fresh ballot any time before the end of the vote by sending a signed mail to bal...@vote.debian.org with the subject gr_initcoupling. To vote you need to be a Debian Developer. HOW TO VOTE First, read the full text of the platform. To cast a vote, it is necessary to send this ballot filled out to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: gr_initcoupl...@vote.debian.org The form you need to fill out is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 5 choices in the form, which you may rank with numbers between 1 and 5. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. Do not enter a number smaller than 1 or larger than 5. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. To vote no, no matter what, rank Further Discussion as more desirable than the unacceptable choices, or you may rank the Further Discussion choice and leave choices you consider unacceptable blank. (Note: if the Further Discussion choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the Further Discussion choice by the voting software). Finally, mail the filled out ballot to: gr_initcoupl...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot: use the vote key appended below for encryption. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support alternative init systems as much as possible [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFRX47EBEACyQIoQ1G9G36g+5tgZU8yIXIII6uzAG+b9qCv83B6Y3nUTwugt EgP/6nStrZYunUyPir8e/V5GhPYXxt5bIfAx7+HVdmE5UGH88X3ZWyxblXU4Y7gs Orbo/5D178uIgpfaKkoCfDMfEnMdsj42IoKLidPuuF0YH+XcYNP7JXi3q8newdMk jgzpJBmykuyOFL/GhQht5bOz59irkWkfK9IFrrnzE6LFzEC3dAyYUjmI7DLT8M2m Lgpzzk72SclGHPguJH9rzTycoCk1XYVfmLYgDM/E5VvXgCmE4CyVG2urCf/qkOEp hLHFZv0NfIihrtT1YsK6+JslnUgwY4Sd0xHEjuZEo6P6tRjdLKdPvg+3dPldjf/b dtuwZyw4hUJsXYYwYN9l8OQrNfhPcI1+ONIi/Mgh7j2M0cHPx+mHQ4PmQivnLSeg IxutsIIXjNKoXDvs6SvTdS1S1GrHOJhi66y/oD6TkJ92ONIokRSKS01rK3RtQGNZ ty1MNDaEMYw3EalO8H4bouPTen1yD4NEfKHqJq1i6XfXvxI2WD2q6sbtq4pM0KYO AWWG/UEJTolr4GmhbfgGUYWMl1tQENZqqnXbLzXbrkvx8QO6ctmNjOXqiQLPcdyb D3QoOaETjYZbJBNQm82QNcN/AKZb1bFcxn+udyLndp51x4G2cn8HXftj9QARAQAB tDlJbml0IHN5c3RlbSBjb3VwbGluZyBHUiA8Z3JfaW5pdGNvdXBsaW5nQHZvdGUu ZGViaWFuLm9yZz6JAj4EEwECACgFAlRX47ECGwMFCQAVGAAGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJENMz7Ba0rT7DgEYP/REro0zlGHkyYFFvOlFGpmrFNbWE xkrPh5xS3ywVgnTiEF80xn0afcO3JfC/aOVSoJTFCk2ROerdf9oSzRH/pV67BDlX LWZxZvUtEAYMoOoJlnk5lxvtplGORRpb8kSq5bGCByjLFiHKOLwt+2SpiWIKlAxe JFaeccc8o5WraHDwkfQYjjAzKY9WIP7gap8tt2Od+n9Rdj/lqR9lo78mAo5VUzr0 WeyL5DYIdzguCLFBJrrPK9SrbB1XC29MKF9H7ESeoqAyHXb6v1f19gAcRqlEFOqB QungyCDAye95GujJktWl/SPzv7auzp7Y9iGAaU90gpxz1tf0ciXxebS4yayPjw0J
Re: Call for Votes: General Resolution: Init system coupling
On Tue, Nov 04, 2014 at 05:53:36PM +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support alternative init systems as much as possible [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- All, For avoidance of doubt, and as I've been asked on IRC, all options have a 1:1 majority requirement. Neil -- signature.asc Description: Digital signature
Re: Call for Votes: General Resolution: Init system coupling
On Tue, Nov 04, 2014 at 07:54:46PM +0100, Lucas Nussbaum wrote: Hi Neil, On 04/11/14 at 17:53 +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support alternative init systems as much as possible [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- I must say that I am quite surprised by you choice of summary for Choice 2. First, that's the only one not to include a verb. It could be understood as Packages *must* support alternative init systems as much as possible, which is clearly misleading. Also as much as possible is not part of the amendment. Choice 2 seems to be about 4 things: * The default init system on all arches should be supported, * maintainers should merge support for init systems, * sysvinit support should be maintained for all packages which worked before and any the release team should accept changes during the freeze which preserve or enhance this support This is obviously quite hard to put into one line. Second, after asking for an accurate summary, I replied in 20141017202805.ga10...@xanadu.blop.info (private mail to you+Ian, as was your initial query) with: support for alternative init systems is desirable but not mandatory. If you disagreed with the suggestion, why didn't you say so since Oct 17th? Quite frankly, there's been one hell of a lot of mail during this process, which I've done my best to read and digest. The other option in that mail which you suggested was also quite contentious. I'd be happy with you sending the entire thread to the list if you and Ian agree. That entire thread seemed to then devolve with various accusations, and then you confusing my suggestions for Ian's text for your own. If my suggestion is too long, you could have used any of the following, which are all shorter or the same size as the summary for Choice 3: - Support for alternative init systems is desirable, not mandatory - Maintainers are encouraged to support alternative init systems That doesn't appear to capture the paragraph starting For the Jessie release... accurately. I discussed the final summaries with Kurt before the CfV, and we think that this is about as accurate as we could do given the very short amount of space available. This is also the reason I added a separate paragraph encouraging people to go and read the full proposals. I think that it would be better to update the CfV. Given the above, I don't believe that this would help the process. I feel that the summaries are as accurate as they can be at this time. Also, it's a much more minor problem, but it seems that you missed my second for the fourth proposal in 20141022054027.ga30...@xanadu.blop.info. Updated thanks, should be live when the website updates. Neil signature.asc Description: Digital signature
Re: Call for Votes: General Resolution: Init system coupling
On Tue, Nov 04, 2014 at 07:11:45PM +, Ian Jackson wrote: I think this is still possible. It's a shame that this slightly odd pre-CFV (CFV posted before voting period opens) wasn't explicitly a draft, and posted only to -vote. This vote has currently used up about 15 hours of my time, plus the time to read -vote, and I really didn't want to wait up until gone midnight to post the CfV. For the draft ballot, although there's no requirement to do so, I do indeed think it's a good idea in general. I've added it to https://wiki.debian.org/Secretary/StartAVote which is also an attempt to document how to run a vote, which didn't exist before. Neil -- signature.asc Description: Digital signature
Re: Call for Votes: General Resolution: Init system coupling
On Tue, Nov 04, 2014 at 09:17:51PM +0100, Lucas Nussbaum wrote: I cannot parse the last bullet point, sorry (and any the release team?). Also, the proposal does not mention the release team. Reasonable changes to preserve or improve sysvinit support should be accepted through the jessie release. is not meant as an override of the release team: the maintainer should accept such changes, not necessarily the release team (normal rules for the freeze should apply). If I intended to override the release team here, I would obviously have made it explicit. Well, any enhancement for sysvinit support would certainly be against the freeze policy. However, as these are decisions which in theory the release team has not yet made (it's done on a case by case basis) then there's no decision to override yet, hence the 1:1 requirement. Additionally, after the Jessie release date, if a bug comes in that improves support for the stable version of a package, what is the maintainer supposed to do? I am sorry you did not use the discussion period to clarify this, it could have resulted in an improved proposal. I'm not sure it's really my position to try and amend your text in this case, I've not been asked to do so. It is, however, regrettable that I haven't had time to continue to discuss the summary lines. Would you be happy with me simply cancelling the entire vote to allow that discussion to take place? I'm not keen to adjust the ballot before midnight, I'd rather send out a new CfV if that's the case. If my suggestion is too long, you could have used any of the following, which are all shorter or the same size as the summary for Choice 3: - Support for alternative init systems is desirable, not mandatory - Maintainers are encouraged to support alternative init systems That doesn't appear to capture the paragraph starting For the Jessie release... accurately. That paragraph could be summarized as support wheezy-jessie upgrades nicely, as was detailed in e.g. 20141021131459.ga13...@xanadu.blop.info. This is not the core of the proposal. However, it's in the text. If you didn't want it to be part of the proposal, it should have not been there, or been as a summary outside of the resolution to be passed. The fact remains that it's in there, whether your intention or not. I discussed the final summaries with Kurt before the CfV, and we think that this is about as accurate as we could do given the very short amount of space available. This is also the reason I added a separate paragraph encouraging people to go and read the full proposals. [...] Given the above, I don't believe that this would help the process. I feel that the summaries are as accurate as they can be at this time. I strongly disagree, and urge you to reconsider. However, if you decide not to change the summary for this proposal to something that I would consider an accurate summary of it, I ask you to include a title at the start of my proposal (under Choice 2:, but before Debian has decided [...]), that should read: | Support for alternative init systems is desirable, not mandatory | That's only a compromise solution, and clearly not one I'm satisfied with -- I still think that this should be used as the summary. I think that the web pages and the ballot not matching would be the worst of all worlds to be honest. Unless I'm mis-understanding? Neil signature.asc Description: Digital signature
Re: Call for Votes: General Resolution: Init system coupling
On Tue, Nov 04, 2014 at 01:30:18PM -0800, Don Armstrong wrote: On Tue, 04 Nov 2014, Lucas Nussbaum wrote: On 04/11/14 at 17:53 +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support alternative init systems as much as possible [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Why not just make Choice 2: Packages should support sysvinit for jessie. Otherwise, if you all aren't able to agree, just: Long story short, we've come to an agreement on: Support for other init systems is recommended, but not mandatory I'll send out a new CfV once voting opens. Neil signature.asc Description: Digital signature
REISSUED CfV: General Resolution: Init system coupling
Note: this is a re-issued CfV, please use the ballot below or your vote will be rejected. Voting is now open. Voting period starts 00:00:00 UTC on Wednesday, November 5th, 2014 Votes must be received by 23:59:59 UTC on Tuesday, November 18th, 2014 The following ballot is for voting on init system coupling. This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions or problems contact secret...@debian.org. The details of the general resolution can be found at: http://www.debian.org/vote/2014/vote_003 NOTE: the ballot below is a very short summary of each option. Voters are strongly encouraged to read the full options at the URL above. Also, note that you can get a fresh ballot any time before the end of the vote by sending a signed mail to bal...@vote.debian.org with the subject gr_initcoupling. To vote you need to be a Debian Developer. HOW TO VOTE First, read the full text of the platform. To cast a vote, it is necessary to send this ballot filled out to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: gr_initcoupl...@vote.debian.org The form you need to fill out is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 5 choices in the form, which you may rank with numbers between 1 and 5. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. Do not enter a number smaller than 1 or larger than 5. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. To vote no, no matter what, rank Further Discussion as more desirable than the unacceptable choices, or you may rank the Further Discussion choice and leave choices you consider unacceptable blank. (Note: if the Further Discussion choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the Further Discussion choice by the voting software). Finally, mail the filled out ballot to: gr_initcoupl...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot: use the vote key appended below for encryption. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ ] Choice 1: Packages may not (in general) require a specific init system [ ] Choice 2: Support for other init systems is recommended, but not mandatory [ ] Choice 3: Packages may require specific init systems if maintainers decide [ ] Choice 4: General Resolution is not required [ ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFRX47EBEACyQIoQ1G9G36g+5tgZU8yIXIII6uzAG+b9qCv83B6Y3nUTwugt EgP/6nStrZYunUyPir8e/V5GhPYXxt5bIfAx7+HVdmE5UGH88X3ZWyxblXU4Y7gs Orbo/5D178uIgpfaKkoCfDMfEnMdsj42IoKLidPuuF0YH+XcYNP7JXi3q8newdMk jgzpJBmykuyOFL/GhQht5bOz59irkWkfK9IFrrnzE6LFzEC3dAyYUjmI7DLT8M2m Lgpzzk72SclGHPguJH9rzTycoCk1XYVfmLYgDM/E5VvXgCmE4CyVG2urCf/qkOEp hLHFZv0NfIihrtT1YsK6+JslnUgwY4Sd0xHEjuZEo6P6tRjdLKdPvg+3dPldjf/b dtuwZyw4hUJsXYYwYN9l8OQrNfhPcI1+ONIi/Mgh7j2M0cHPx+mHQ4PmQivnLSeg IxutsIIXjNKoXDvs6SvTdS1S1GrHOJhi66y/oD6TkJ92ONIokRSKS01rK3RtQGNZ ty1MNDaEMYw3EalO8H4bouPTen1yD4NEfKHqJq1i6XfXvxI2WD2q6sbtq4pM0KYO AWWG/UEJTolr4GmhbfgGUYWMl1tQENZqqnXbLzXbrkvx8QO6ctmNjOXqiQLPcdyb D3QoOaETjYZbJBNQm82QNcN/AKZb1bFcxn+udyLndp51x4G2cn8HXftj9QARAQAB tDlJbml0IHN5c3RlbSBjb3VwbGluZyBHUiA8Z3JfaW5pdGNvdXBsaW5nQHZvdGUu ZGViaWFuLm9yZz6JAj4EEwECACgFAlRX47ECGwMFCQAVGAAGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJENMz7Ba0rT7DgEYP/REro0zlGHkyYFFvOlFGpmrFNbWE xkrPh5xS3ywVgnTiEF80xn0afcO3JfC/aOVSoJTFCk2ROerdf9oSzRH/pV67BDlX LWZxZvUtEAYMoOoJlnk5lxvtplGORRpb8kSq5bGCByjLFiHKOLwt+2SpiWIKlAxe JFaeccc8o5WraHDwkfQYjjAzKY9WIP7gap8tt2Od+n9Rdj/lqR9lo78mAo5VUzr0 WeyL5DYIdzguCLFBJrrPK9SrbB1XC29MKF9H7ESeoqAyHXb6v1f19gAcRqlEFOqB QungyCDAye95GujJktWl/SPzv7auzp7Y9iGAaU90gpxz1tf0ciXxebS4yayPjw0J
Re: Maximum term for tech ctte members
Hi Sam, On Mon, Nov 03, 2014 at 07:00:46PM +, Sam Hartman wrote: This seems to have stalled and I'm disappointed to see that because I think this is an important issue. My recommendation is that you propose a resolution based on the comments you received. nontrivial ongoing discussion at that time, I am likely to propose a resolution based on your text. Obviously if between now and then someone makes it clear why we should delay or something like that I'll listen and consider the input. My interest in only to make sure this issue is not dropped. This was discussed at the last tech-ctte irc meeting, and it was agreed to defer this until the current GR has quietened down. See http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html Neil -- signature.asc Description: Digital signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On Tue, Oct 28, 2014 at 06:31:43PM +0200, Aigars Mahinovs wrote: On 28 October 2014 18:20, Russ Allbery r...@debian.org wrote: With all of those facilities, we've taken different approaches; with the mail transport agent, for example, we've defined an interface that all mail transport agents are required to implement, and MTA implementations that don't implement that interface aren't allowed to provide a mail transport agent. We did something similar with /bin/sh. With udev, on the other hand, we basically required everyone run udev; it's theoretically possible to boot a system without udev, but it's not tested and I think everyone would agree that it's not supported. For the compiler, all of Debian is built with GCC, but some teams do test builds with Clang and report bugs, which most maintainers merge and some don't. And with libc, we do not even allow for the possibility of replacing the system libc; you use glibc if you're using Debian on Linux, and that's the end of that. This is an interesting insight. It also can be used to identify possible solutions for the current issue: * if we go the MTA/sh route, then we define lowest common denominator interface of an init system and only init systems providing that (possibly with a systemd-shim) can be init systems in the archive and also applications can only depend on presence of these particular interfaces; * if we go udev/gcc/glibc route, then we just say that all other init systems are not supported, put systemd as essential and push all other init systems to extra or even out of the archive; With enough imagination it is possible to see the original GR proposal as implementing the first option in a obtuse way. I think there's possibly a slight logic gap here, and that's around applications can only depend on presence of these particular interfaces. As far as I'm aware, we don't actually say that anywhere. Applications can only /rely/ on those interfaces, but it's certainly possible for an application to have a Depends: on a particular shell. From Policy 10.4: If a shell script requires non-SUSv3 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked Essential, as in the case of bash). Going down the minimal standard would mean that we should codify in policy what we expect the minimal standard of the init system to have to be in the archive, but what this GR seems to be about is saying that applications may or may not actually have that Depends: at all. Neil -- signature.asc Description: Digital signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On Wed, Oct 29, 2014 at 02:16:14PM +0200, Aigars Mahinovs wrote: On 29 October 2014 13:40, Neil McGovern ne...@debian.org wrote: * if we go the MTA/sh route, then we define lowest common denominator interface of an init system and only init systems providing that (possibly with a systemd-shim) can be init systems in the archive and also applications can only depend on presence of these particular interfaces; I think there's possibly a slight logic gap here, and that's around applications can only depend on presence of these particular interfaces. As far as I'm aware, we don't actually say that anywhere. Applications can only /rely/ on those interfaces, but it's certainly possible for an application to have a Depends: on a particular shell. Shell is relatively harmless, imagine if, for example, LibreOffice suddenly had a dependency on Exim (due to some special email sending options used in the mail merge feature) and so installing LibreOffice would also change your MTA. Or, if you installed memtest86, and it replaced lilo by installing grub? :) My point is that I believe that we should be clear what we're saying here. I don't think that (as a project) we've said quite so strongly that program X may only use Y features, or are restricted from declaring a Depends: line. That is quite different to the comment above about defining a lowest common denominator, which is not (as far as I can tell) what this GR is about. Neil -- 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/20141029144023.gk18...@halon.org.uk
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On Wed, Oct 29, 2014 at 12:27:40PM +, Ian Jackson wrote: Neil McGovern writes (Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]): As far as I'm aware, we don't actually say that anywhere. Applications can only /rely/ on those interfaces, but it's certainly possible for an application to have a Depends: on a particular shell. You can have more than one shell. In fact you can have as many as you like. We do *not* allow applications to require a particular shell *to be /bin/sh*. Indeed, but we do allow applications to rely on other particular things to be running, such as the kernel, or the bootloader. That said, I think we're moving off the point, which is that the extension of the sh bit of policy to this GR is one I don't think can be relied on. Neil -- 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/20141029144959.gl18...@halon.org.uk
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
On Wed, Oct 22, 2014 at 07:45:39AM +0900, Charles Plessy wrote: Indeed, you are right: by definition, not all questions have been answered. The existing wording of the amendement is therefore logically inconsistent. I propose the following replacement as per article A.1.5 of our Contitution. Received and updated. Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Hi Sergey, On Tue, Oct 21, 2014 at 04:38:49PM +0300, Sergey Vlasov wrote: Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. This mail isn't signed, nor do I seem to be able to find you in db.debian.org. Unfortunately, only Debian Developers may sponsor resolutions in this way. Neil -- 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/20141022103926.gq18...@halon.org.uk
Re: GR option text on ballots
On Tue, Oct 21, 2014 at 08:14:44AM +0200, Didier 'OdyX' Raboud wrote: Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit : Ian's: make each package support all alternative init systems This is actively misleading in a least four ways: Yup, I wouldn't count that as neutral either. How about: Your two proposals don't seem to match Ian's to which you're responding: Packages should continue to run under sysvinit unless technically unfeasible Ian's doesn't mention sysvinit at all; this would be highly misleading. Packages may require a specific init system if technically required That's not at all the core of Ian's proposal in my reading. That's because they're descriptions for Lucas' amendment. Neil -- signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: --- 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. --- Received and valid. I'll add it to the vote page once it receives sufficient seconds. Neil -- signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Sat, Oct 18, 2014 at 12:21:18PM +0200, Luca Falavigna wrote: Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. All received and valid. Thanks, Neil -- signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: Anyway, whichever the name I call for seconds (or comments: if this proposed amendment is considered harmful, let me know). Received (well, found in the middle of a mail thread, thanks for changing the subject though :P) and valid. Neil -- signature.asc Description: Digital signature
Re: GR option text on ballots
On Sun, Oct 19, 2014 at 03:18:52PM +0100, Ian Jackson wrote: Lucas Nussbaum writes (Re: GR option text on ballots): I'd like to propose: I would like to reiterate my view that these summaries should be positive, and written by the proponent of each version, so long as they are not misleading. A quick look through previous ballots seems (to me at least) to have neutral statements there, rather than positive ones, so I'd prefer these if possible. IMO summary lines should certainly not be written by opponents of the proposed option. Please would you as Secretary confirm that you will seek to use a summary text that both I (as proponent) and you are happy with. That would indeed be my aim, though I reserve my right to make a final decision should that not be possible. Obviously, with what is potentially quite a contentious vote, I'd like to avoid that, hence this mail thread :) If the Secretary feels we have to have a neutral rather than a positive phrasing I would request that we use the following summary line for my proposal: Packages may not (in general) require a specific init system That sounds fine to me. Ian's: make each package support all alternative init systems This is actively misleading in a least four ways: Yup, I wouldn't count that as neutral either. How about: Packages should continue to run under sysvinit unless technically unfeasible or Packages may require a specific init system if technically required ? I would be very displeased if the Secretary chooses to use a text for my proposal which was suggested by my opponent, and which I think contains coded criticisms of my proposal. I'm not sure why you would assume that this is a possibility to be honest. Neil -- 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/20141020111714.ga18...@halon.org.uk
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Oct 19, 2014 at 02:59:16PM +0100, Ian Jackson wrote: (CC secretary@ to avoid this getting overlooked in the mail flood.) I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). Received and valid Neil -- 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/20141020181427.gi18...@halon.org.uk
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: I am therefore bringing forward an alternative proposal Recieved, and verified. Note, this has been proposed by the current Project Leader, and thus does not require seconds, but will record those seconding anyway. Neil -- signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote: On 17/10/14 at 11:38 +0200, Michael Banck wrote: On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: For the jessie release, all software that currently supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. I believe currently needs to be clarified - are you talking about the current state of jessie, of wheezy, or something else? I tried to keep changes from the original text (as voted on by the TC) to the bare minimum. But, since the intend here is to allow swift upgrades between stable releases, it should read: For the jessie release, all software available in Debian 'wheezy' that supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. Hi Lucas, For clarity, are you formally amending your own text here? Neil -- signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, Oct 17, 2014 at 03:25:03PM +0200, Lucas Nussbaum wrote: On 17/10/14 at 13:59 +0100, Neil McGovern wrote: On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote: On 17/10/14 at 11:38 +0200, Michael Banck wrote: On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: For the jessie release, all software that currently supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. I believe currently needs to be clarified - are you talking about the current state of jessie, of wheezy, or something else? I tried to keep changes from the original text (as voted on by the TC) to the bare minimum. But, since the intend here is to allow swift upgrades between stable releases, it should read: For the jessie release, all software available in Debian 'wheezy' that supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. Hi Lucas, For clarity, are you formally amending your own text here? Yes. I am expecting other fine-tunings during the next hours/days, so I initially wanted to gather those changes in a single amended version. But now that you asked the question, yes, please amend the proposal with the above change. Thanks, updated. I want to get the web pages etc updated asap, and post to DDA. I look forward to any more changes :) Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. Your proposal has been received and is signed correctly. Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 07:57:06PM +0200, Jonas Smedegaard wrote: Seconded. I'm getting a bad signature from you, can you try again, perhaps with a clearsigned mail? Thanks, Neil -- signature.asc Description: Digital signature
Re: Results for Debian Project Leader 2014 ElectionStart_Time = 31 Mar 2014 00:00:00
On Mon, Apr 14, 2014 at 09:27:17AM +0200, Joachim Breitner wrote: Hi, Am Montag, den 14.04.2014, 00:00 + schrieb devo...@vote.debian.org: The winners are: Option 1 Lucas Nussbaum congrats, and all the best for the next term. (Also congrats to Neil for getting a very good result as well.) Thanks Joachim, Best of luck to Lucas for the year ahead! Neil -- signature.asc Description: Digital signature
Re: time-limited, auto-reinstated delegations (and reports)
On Fri, Mar 28, 2014 at 06:15:46PM +0900, Stefano Zacchiroli wrote: A way around that would be to use time-limited delegations *only*. Q: What do the candidates think of that idea? If you agree it'd be good, would do you engage in doing so for the duration of your term? I think that there's considerable benefits to this, but also potential drawbacks: Of course there are drawbacks, for instance: 1) given time-limited delegations are not (yet) a custom in our project, teams that have been non time-delegated up to now might feel bad about this in the beginning; 2) the delegation bookkeeping will increase substantially (having been there I am aware of the pain, and I can assure that it is far from being negligible). And these are basically my main concerns :) However, for the Release team, this could be made on a release +6 months basis, as it's around then that RMs are due to change (as the workload has a habit of burning out RMs...) For other teams, it's certainly something that I would explore with them. So I'd give tentative support for the idea. Neil -- signature.asc Description: Digital signature
Re: How should we deal with bad maintainers?
On Fri, Mar 28, 2014 at 10:21:06AM +0100, Gergely Nagy wrote: Raphael Hertzog hert...@debian.org writes: assume that a package maintainer is active but is doing a bad job regarding our standards (things like ignoring problems in stable, breaking backwards compatibility for no good reason, not packaging new upstream versions in unstable, etc) and is not really cooperative (closing bugs hastily, not responding to help offers). What shall we do in those situations? Best case, I'm very motivated and I hijack the package but assume that I'm just interested in having a working package because it's a dependency of a package that I use but that I don't care enough to take it over. What are my options? On a similar topic, a couple of years ago, there was an effort to set up a salvaging process. Not quite for the situation Raphael describes, but somewhat related. My question to both candidates would be: what's your opinion on salvaging packages? If favourable, what do you think, could move it forward? I'm certainly keen to ensure the salvaging work goes ahead - to move it forward though I think it needs a bit of work done on dev-ref to formalise it, and have it proposed. We should make sure we're not duplicating the work of the MIA team. For maintainers who are active, and there's a technical disagreement about how a package is maintained, then the tech-ctte is the correct place to take the issue. Debian has a strong bond between packages and maintainers, which has both good and less good attributes. The advantage is that there's a person who knows the package intimately and is also responsible for it, but can cause issues if they disappear. We should try and mitigate the latter to ensure that the project can move on when this happens. Neil -- signature.asc Description: Digital signature
Re: All DPL candidates: DPL Term lengths and limits?
Hi Brian, On Thu, Mar 27, 2014 at 07:54:50PM -0400, Brian Gupta wrote: I know this has been raised in elections past, but any thoughts on the current one-year DPL terms, and unlimited terms allowed? If thoughts are geared toward change do you have any plans to actively try to change the status quo? I don't. There's been quite a bit of talk of this in the past, including limiting to two years, but it seems to me that the issues here aren't reflected in what happens in practice. Firstly, you have Branden, who for unfortunate circumstances had to divert his attention away from the project during his term. The issue there wasn't one that would be solved by a term limit. The flip-side is Stefano, who served for three terms fantastically. I wouldn't want to restrict this unnecessarily. The main reason for trying to put a term limit in place is usually to make sure that people other than the incumbent stand a fair chance of election, as the DPL has a higher profile than others. We shall have to wait for the outcome of this election to see if that's an issue :) For the length, I think there's a large risk of 'scaring away' any candidates - DPL is quite a commitment and I think a two year term (even though my election to being a Councillor was for four!) could be seen as a major issue for people. As you mentioned, it would be possible to have a shorter candidate statement, but at this point, if there's people who wish to run against the DPL anyway, I think that they should be allowed to do so. Neil -- signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Steve, On Thu, Mar 27, 2014 at 01:03:31PM -0700, Steve Langasek wrote: Do you think it's appropriate for these organizers to use Debian's name in seeking local sponsorship without consulting the DPL? Sorry for not being clearer, but no. I think that a central repository and/or sponsors team is quite important to ensure that our sponsors aren't being pestered by disparate people. Organisations already find the concept of Debian's distributedness quite hard to grasp, so I think that this contact point would be useful. However, with the example of sprints, then it's certainly useful for local sponsorship to happen. I'd like to ensure it's easy for people to see if some sponsor is being handled by a central team, but that shouldn't bind people to a requirement that all requests go through there - rather that the central team should be kept in the loop. I wouldn't want my employer to offer me the office for a weekend, but then me having to ensure approval happens for Debian to use it. Neil -- signature.asc Description: Digital signature
Re: Team health and actions
Hi Enrico, On Fri, Mar 28, 2014 at 09:26:01AM +0100, Enrico Zini wrote: 1. a team that works well and in a sustainable way, and how a DPL can bring thankfulness and appreciation; I think that most of our teams work well and are sustainable. The level of sustainability can sometimes teeter to there being less people-power than needed, but that's a common trait in Debian. If I was to pick one, I'm going to not pick a delegate - the translators who work tirelessly are fantastic, and I don't think get enough recognition on a regular basis - Kudos to everyone who does it :) 2. a team that works well but not in a sustainable way, and how a DPL can help bringing sustainability; A little bit of a stab in the dark here, but I'm going to *guess* the DebConf team, simply because the huge amount of work to organise this every year is very wearing, and I haven't seen any new delegations recently. If this isn't the case, I'd be very pleasantly surprised :) 3. a team that does not work well, and how a DPL can address the problem. I'm going to nominate my own one here - the press team. See the other thread on -vote for more details. Neil -- signature.asc Description: Digital signature
Re: non-free?
On Tue, Mar 25, 2014 at 10:25:02AM +, Steve McIntyre wrote: On Tue, Mar 25, 2014 at 09:32:26AM +0100, Frank Lin PIAT wrote: On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote: Because as long as we document it, it's very hard to claim that non-free is not part of Debian, when you could just add it as a keyword side-by-side with main in your sources.list. The firmware have been moved from main to non-free a few years ago. The unintended consequences is that almost every system now use the non-free suite. Therefore users are more likely to install non-free packages. Yup. Various conversations have happened around firmware in the last few years, but this is an effect that some people may not be aware of. So... Neil and Lucas: what do you have to say on this front? Of all the things that *could* be done here, what would you like to see personally? I think the *simplest* thing[0] would be another line in your apt prompt: The following NEW packages will be installed: wibble The following NEW non-free packages will be installed: binaryblob-nonfree This should raise awareness of the installation of non-free software without the splitting up of the DNS that would cause issues for users. Neil [0] Apologies to apt maintainers if this is not simple. I'm aware that from an outsiders' point of view, all problems can seem simple! -- signature.asc Description: Digital signature
Re: DPL candidates: managing the CTTE memberships
Hi Josselin, On Fri, Mar 28, 2014 at 10:57:59AM +0100, Josselin Mouette wrote: What is your stance on disruptive members in the committee? I would prefer TC to work with each other constructively, but I also recognise that this isn't always possible when it comes to a controversial decision. One person's disruptive is another's reasonable concern. Do you think it applies to some of the behaviors observed during the past year? I'm going out on a limb here and say that you're commenting about Ian. I know Ian fairly well, and am convinced that he has the best interests of the project at heart. There is a genuine issue around the way the discussion took place, and the different approaches that members of the committee took, and the values that different members placed on different aspects of the decision. However, to then take the step to say that someone was deliberatley disruptive is worrying for me. How do you intend to enforce it if necessary? For information, I sent a number of private messages to more then one ctte member over this issue, ranging from personal suggestions to take a step back to re-considering various actions. I think that this is an important role of the DPL, and I'd hopefully be able to bring my personal interations with a wide range of people in Debian to help that. Similarly, what is your stance on conflicts of interest in decision bodies? This affects the CTTE, but also, the FTP masters, list masters, the DPL himself, etc. How do you intend to enforce it? When I was a Councillor, there was the concepts of prejudicial and non-prejudicial conflicts of interest[0]. The question was if a decision would have a material effect, or be seen to have a material effect on the outcome of a decison. Importantly, it's for the individual person to make that decison. There must be an understanding that people can, and *should* make decisions where they are professionally involved, but should also be able to make decisions which they remove their personal interests. When someone feels unable to do so, then they should recuse themselves. I'm sorry for this technical answer, but it's quite difficult to give a quick yes/no answer to this. Neil [0] http://en.wikipedia.org/wiki/Prejudicial_interest signature.asc Description: Digital signature
Re: two questions: fund raising money and publicity
Hi Gunnar, On Thu, Mar 20, 2014 at 12:55:35PM -0600, Gunnar Wolf wrote: So, back to the case: What's your take on this issue? How much can one part of the Debian universe of subprojects expect the money it generated be available for its future? Should we set a clear number? On the specific case, I remember when I wound up the accounts for DebConf 7 that the surplus was earmarked as a donation to DebConf 8. More specifically, there was a Debian seed fund of 10k USD to help with the cash flow and then 8k GBP which was transferred to Argentina. This then continued with 18k USD being sent to Spain, 53k EUR to New York, and then 19k USD to Bosnia and Herzegovina. However, although I think that it's Debian's money, not DebConf's money, we need to remember what the sponsorship was donated for. We should also be clear about what may be expected to be a structural deficit, and what is a cash-flow problem. In general, I think that excess should be returned to Debian as the holding organisation, but that Debian should be willing to help ensure that sub-projects can draw on Debianfunds if needed, and it is sensible to do so. Neil -- signature.asc Description: Digital signature
Re: All DPL candidates: about the PPAMAIN
Hi Thomas, On Sat, Mar 15, 2014 at 03:07:39PM +0800, Thomas Goirand wrote: Though, it is my understanding that those who are capable of doing the work are too busy. So what is your plan? Is using Debian money for sponsoring that work one of the things you would do? If yes, up to what amount would you accept to spend? (note: I think it would be money wisely spent) I'm very wary of using Debian money directly to pay people for development. No matter what your view on if this is good expenditure, I think it's been shown that this is highly divisive to the project. We're a community of volunteers, and the proposals to use money in this way is well documented, so I won't repeat them here. [0] For hardware though, I think that this would indeed be legitimate expenditure - we should ensure that it's not a technical factor that's blocking the deployment of this. However, I think that there's a wider question which can be asked: is wanna-build/britney/dak the best option for the project? SteamOS for example uses OBS [1] to completely rebuild Debian. I'm not suggesting we immediately dump our tools, but it's certainly an option we should keep open in any evaluation. [0] For those who don't remember, search for DUNC tank on your favourite search engine. [1] http://openbuildservice.org/ -- signature.asc Description: Digital signature
Re: what should the DFSG apply to?
Hi Paul, Slightly re-arranging the question order, if that's ok. On Sat, Mar 22, 2014 at 03:42:43PM +0800, Paul Wise wrote: Please share your thoughts on the SC and DFSG, in particular: Which items of the DFSG should apply to which types of works? How do you currently determine which files in upstream source packages are source and which are not? I take the following principle: If I install a package, and don't like either how it works, or how it looks, can I change it myself? In the case of a minified .js file for example, without other source, I technically *can*, but it would make my brain leak out of my ears to do so. Thus for me personally, it's not the preferred form of modification. However, we should also consider if there's an alternative. If the preferred form of modification has been lost in the mists of time, then it's quite possible to describe the resultant file as now the defacto form of modification. How do you currently apply the DFSG wrt your Debian packaging work? How do you currently deal with upstream source packages that include generated files instead of creating them at build time? Speaking in general, as I've managed to give away or remove all my packages that I directly maintain myself, I would remove them from the source package. Would you initiate or support a GR to replace uses of the words program and software in the DFSG with work where appropriate? I probably wouldn't initiate one, I don't think that this is currently the biggest blocking issue facing the project, and would rather avoid another lengthy debate on the topic. However, I would probably support it if one was proposed, at least so that we can get closure on the issue. Neil -- signature.asc Description: Digital signature
Re: To Neil: 2IC
Hi Lucas, On Mon, Mar 24, 2014 at 08:27:52PM +0100, Lucas Nussbaum wrote: In your rebuttal, you are quite critical of the idea of a board. You raise concerns about the risk of creating a cabal, and about transparency and democratic accountability. I fully agree that those concerns are valid ones, and actually even mentioned them in my platform (Of course, there is the risk of creating a cabal, and of reducing transparency. I am absolutely committed to avoiding that. [...]). Indeed, but you seem to have missed out how you'll avoid it. The board concept doesn't seem to have any details on who would serve on it at what time, except essentially by appointment of the DPL when the DPL decides that someone has done some things that the DPL wants done. Saying that you're committed to avoiding that is fine, but the question remains *how* you'd do so which is absent from the platform. On the other hand, you defer the decision about a 2IC until after the election. Apologies for not making myself clearer for you on this, but I'm afraid you're putting words into my mouth here. It's a concept that I find interesting, and would put more thought into it when elected, but I do not intend on appointing a 2IC. Neil -- signature.asc Description: Digital signature
Re: Debian Project Leader?
On Sat, Mar 22, 2014 at 02:23:30PM +0800, Paul Wise wrote: Please imagine a Debian without the DPL position. How would it be better, how would it be worse, how would things work differently, would it be desirable? Hi Paul, I think there's a couple of aspects to this, one from an external project perspective, and one from an internal one. Externally, the DPL role is one that's useful for an interface between Debian and various organisations. This ranges from press, other organisations, and trusted organisations. Without a DPL, it would be quite difficult to have some speak on behalf of Debian in an authoritative way. As press officer, I've issued statements on behalf of the project for some issues, but this is restricted to the view of the project as a whole, so can be limited to the project has made no final decision yet, or developer X says Y. The DPL has a mandate to say things which allows them to be a bit more specific. From a practical point of view, SPI needs someone to approve expenses - I can't think of a simple way of this happening without a DPL. Internally, the DPL is someone who can coordinate and communicate. Talking to other developers, and ensuring that teams aren't being blocked by issues is a key role. Would this still all be possible without a DPL? Yes, but I think it would be improbable without someone *acting* in the DPL role, even if they're not officially elected to it. Recommended reading includes The Starfish and the Spider[0], I would recommend it for those interested in decentralised organisations :) Neil [0] http://www.starfishandspider.com/ -- signature.asc Description: Digital signature
Re: two questions: fund raising money and publicity
Hi Ana! On Wed, Mar 19, 2014 at 10:21:20AM +0100, Ana Guerrero Lopez wrote: DebConf is one of the biggest expenses of Debian, every year we look for sponsorship and we had (and have) sponsors who were sponsoring DebConf as a way of giving their annual donation to Debian and not necessarily funding DebConf itself. (Do you agree with this part, BTW?) Yes and no :) Having written (if my memory serves me correctly!) the first sponsorship brochure for DebConf 7 I view it as slightly more subtle than that. If DebConf didn't happen, then I don't believe that would mean that there would be an equivalent annual donation that would come in. The funding that's given is committed for a reason - sponsorship of an event raises the profile of the company for the attendees, enable recruitment and offer opportunities for contact building, as well as being give back to the community. I don't think that a general give money to Debian request has quite the same draw. There's a reason it's much easier to raise money for a specific goal/thing than in general :) In recent years, we have started to invest more Debian money in stuaff such like sprints and minidebconfs¹ that sometimes look for external founding. This has lead to some cases where sponsors have been contacted for separate teams in Debian which can be confusing. If you think this is a problem. How do you think we can improve this? I do view this as a problem, and the short answer is that I support Brian Gupta's efforts in the debian-sponsors-discuss list[0]. It's something we should be encouraging, and would potentially draw people into Debian who have not previously felt able to contribute. A great article on fund-raising of a talk from Josh Berkus is at [1]. [0] http://lists.alioth.debian.org/pipermail/debian-sponsors-discuss/Week-of-Mon-20140310/79.html [1] https://lwn.net/Articles/560381/ * Publicizing Debian We have several officials ways of publicizing stuff in Debian: press releases, identi.ca, bits.d.o and the DPN. We also have the bits from the DPL that sometimes overlap with the above sources and announce stuff that should be announce somewhere else instead of mixed with the DPL activity. That said, the coordination between the above sources doesn't work very well, all of them have a lot of room for improvement (and I say that being closely involved in one of them) and I have seen Debian contributors lost about what to do when they want to announce something, sometimes being played as a ping pong ball between teams. I would love to know your vision about how publicizing Debian should work and if you think you can do something as DPL to improve the current situation. Indeed, with my press officer hat on, I'd say that publicity and press is just about scraping by. This isn't to denigrate the fantastic work being done in this area by people, but that I think everyone's overworked, and could do with more help. When Lucas looked at the press delegation, a few of the active publicity people were approached to suggest they may want to become press officers, but unfortunately weren't able to commit the time to do so. Ideally, I'd love to see someone with the enthusiasm and time to take this on, to coordinate our efforts and bring together the different methods of communication we do. As for how to solve this issue, I'll be honest: I don't know. I think that coordination of publicity should go through the debian-publicity mailing list if at all possible, but the core issue is finding someone to take the role and drive it forward. Neil -- signature.asc Description: Digital signature
Re: non-free?
Hi Paul, On Sat, Mar 22, 2014 at 05:43:25PM +0800, Paul Wise wrote: To the candidates, Which packages from Debian contrib/non-free do you use or have installed? On my laptop, I have: firmware-realtek, icc-profiles, intel-microcode, skype and steam from non-free, and flashplugin-nonfree, iucode-tool from contrib. On my server, I have pine, which I don't use but some of the users on it seem to be unwilling to move to anything else. How do you feel about Debian's approach to non-free software laid out in Social Contract item 5? Is it the right approach? Should we change it? I believe that is a good balance at the moment. This manages to balance the two core characterics I mentioned in my platform: We care about software freedom and We care about our users. There is an argument that has been brought up many times on our lists around SC#4 as well in this area. One school of thought is that a 100% strict adherance to only using free software is in itself in the interest of our users. I don't subscribe to this view. Although it *is* in the interest of our users to use 100% free software, if they're unable to use their computers, or get real work done with a free operating system, then that doesn't help progress free software and Debian. How much support should Debian give for non-free packages? Whatever maintainers are willing to do, and as a project on a best-effort basis. Should the bug tracker accept reports about non-free packages? Yes, it's very little cost to the project to do so. Should non-free packages remain in the Debian archive and mirror network? Yes, see the last answer for more details. Should we continue to provide buildds for select non-free packages? Yes, if there's people willing to run the non-free network. Should non-free packages be part of releases and or receive security support? It depends what you mean for 'release' and 'support', but I think my answer is 'sort of', on a best effort basis. If there's people willing to put in the work then I don't think we should stand in their way, but the focus of Debian should be on main. If we were to drop non-free from debian.org, what level of separation between non-free.org and debian.org is appropriate? The name only? Completely separate infrastructure and developer set? Somewhere in between? I don't think that splitting this up helps our users. Using debian.org provides a trusted distribution mechanism. I think it's better that people get trusted non-free packages from us, than get them from a random third party by burying our heads in the sand and pretending non-free software doesn't exist. Neil signature.asc Description: Digital signature
Re: Both DPL candidates: handling social conflict
On 21 Mar 2014, at 14:42, Filippo Rusconi lopi...@debian.org wrote: On Fri, Mar 21, 2014 at 02:10:01PM +0100, Stefano Zacchiroli wrote: On Fri, Mar 21, 2014 at 01:44:54PM +0100, Wouter Verhelst wrote: While I understand the question, I'm not sure this is very relevant. Yes, Debian is about promoting the cause of free software; and yes, actually *using* free software is a very good (first) way to promote its cause. I'll encourage everyone interested in these topics to read this, very influential for me, essay by Mako: Free Software Needs Free Tools http://mako.cc/writing/hill-free_tools.html Also, +1 to Paul's mail. The DPL is a rather special case. I certainly don't fancy Debian being slashdotted due to the DPL using non-free software publicly, at the very least as long as suitable Free alternatives exist. Undoubtedly +1 to Paul and Zack. Did we not *eagerly* endure, fifteen years ago, highly unstable software (October GNOME, anyone ?) because we thought that by using it we were going to unavoidably better it, for the cause of software freedom? Nowadays Free Software has become so usable, Neil must have an explanation for not using it to post messages. Let him tell us maybe that he had to borrow a computer... He will certainly have a story to tell. Indeed, I’m currently away on VAC skiing at the moment, see my mail to -private. I thought it may be useful to reply as soon as possible to any -vote mails, rather than waiting until I get back to my main machine. If you’re after a candidate that will refuse to touch anything proprietary, even if it helps to further the progress of the project due to an idealogical allergy to anything non-free, you probably should vote for another candidate, possibly RMS. My aim is to promote Debian, and to lead the project in the best way I can. If that involves using OS X while I’m meant to be away from a computer all together, so be it. Neil -- 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/e046f7a9-63c7-4ce3-b7ca-6d8f7a4d1...@halon.org.uk
Re: Both DPL candidates: appropriate choice of dresswear for the DPL
On 21 Mar 2014, at 14:37, Steve McIntyre st...@einval.com wrote: On Fri, Mar 21, 2014 at 01:27:11PM +, Lars Wirzenius wrote: On Fri, Mar 21, 2014 at 01:44:54PM +0100, Wouter Verhelst wrote: However, Debian is not a cult. Indeed not. We are a clan. Which inspires my next question. Neil and Lucas: do you have, or will you get, a Debian kilt and wear that for Deconf14? I know that Neil has a kilt already and is not afraid to use it: http://wedding.einval.com/gallery/day_raw/abj Indeed, also see my platform :) Neil -- 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/e2b97439-ada5-40d6-82f9-282ecc2b8...@halon.org.uk
Re: All DPL candidates: Debian assets
Hi Hector, On 14 Mar 2014, at 13:25, Hector Oron zu...@debian.org wrote: Hello DPL candidates, First of all congratulations for your nominations. I have several questions for you, I hope you do not mind to reply: Thanks for your question, it’s good to see a DSA member engaging with the election :) a. Debian hardware infrastructure 0. What do you think of Debian teams owning their own infrastructure (hardware)? I believe there’s a real risk here. It’s important for everyone to remember that the work they do is for the project, not individual. I don’t agree with Lucas here that items purchased by a TO belongs to that TO, except in a strictly legal sense. The point is that it belongs to the project as a whole. I don’t think it makes much sense for a team to unilaterally purchase hardware without reference to DSA, but also that DSA should be able to accept any specialist requirements that any team have. I’ve seen this both as secretary and release manager, and I believe that DSA in general does a very good job of being flexible in requests. 1. If Debian team gets hardware resources from external parties/sponsors in monetary form, would you be willing to spend that money buying hardware for that team, or re-use existing hardware which is already part of Debian assets and save that money for something else? Hrm, monetary form in exchange for hardware is a tricky theoretical. I believe it’s important to ensure that any donations are used with the wishes of the donator. Thus, if a donation came in for a specific purpose, then it should be spent on that, or returned. So I guess my answer is the latter. The issue is that I would try and ensure this problem doesn’t occur in the first place - there shouldn’t be a problem that there is excess hardware by a team that can be solved by existing DSA resources which requires external fundraising! b. Debian money 0. If Debian had an excess of cash, which topics do you think are more important to spend that money for the overall project benefit? I don’t think there’s an “if” here. Ever since I was secretary of SPI, I’ve been concerned about the amount of money that Debian has earmarked. Again, I disagree with Lucas here - I don’t think that saving donors money is a good plan, our donators expect their donations to be spent to progress the project. At the moment, in just SPI, we have 100k USD awaiting being spent. As an indication, that’s enough for a DebConf without any sponsors! Our donations should be spent. Be that better porter boxes, or a better backup service, or simply making sure our core machines are replaced regularly. Neil -- 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/c0f24868-dac7-40e1-a5da-a75d2e955...@halon.org.uk
Re: All DPL candidates: Time dedicated to the project + team
Hi Sylvestre, On Thu, Mar 13, 2014 at 10:58:07AM +0100, Sylvestre Ledru wrote: * Are you allowed by your employer to work during the week on DPL tasks or is it something that you are going to do on your free time? A bit of both. Collabora allows for a certain percentage of time to be spent on Community, though I'm in no doubts it'll require quite a lot of my free time as well! As a former City Councillor however, I'm quite aware of time requirements - I spent about 20 hours per week doing that for four years, as well as a full time job (and being Release manager!). * Are you considering a second-in-charge or a DPL team (like the DPL helpers but with more official roles) ? I don't intend on running on a platform of a DPL board/team - this has been discussed quite extensively in the past [0], or Project SCUD [1]. We have teams, and delegations. I'm not convinced that adding yet another committee, and the overhead and bureaucracy that this entails is beneficial to the project. However, I do think it's an essential skill for the DPL to be able to delegate tasks (rather than formal delegations, though those may be needed in some circumstances). The DPL helpers initiative was an attempt to start along these lines, and has helped relieve some of the issues here. I would be keen to try and find people who want to take on some of the other more administrative tasks, but I'm aware of the difficulties that this entails. For example, both myself and Steve McIntyre were victimised^W^Wvolunteered to co-ordinate the sprint approvals by Stefano, but without the budgetary sign-off, there wasn't really much we could do. Additionally, while I was on the SPI board, I often wondered why we don't get more people involved in the non-technical side of Debian. The conclusion I came to was that it doesn't interest people as much, they'd rather just get on with producing an excellent package/distribution. I do find the concept of the 2IC more appealing, I think this is a better model, and shall be putting more thought into this if elected. Sorry, this turned into a bit of a longer mail than the simple yes/no answer you may have been after. Neil [0] https://lists.debian.org/debian-project/2007/02/msg00061.html [1] https://lists.debian.org/debian-project/2005/03/msg00035.html -- signature.asc Description: Digital signature
Re: All DPL candidates: level of team management [and 1 more messages]
On Thu, Mar 13, 2014 at 04:11:27PM +, Ian Jackson wrote: Contrary to what Lars says, I think there is a clear difference between these two approaches. ISTM that Lucas is much more hands-on and (for example) and takes much more of a close interest in the processes adopted by teams, than Neil would do. Do you both think that's a fair characterisation ? I'd say that's fair, but possibly a bit over-generalised. I favour letting the teams get on with what they're good at, but I think helping those teams work out/define process if needed would also be useful. For example, that could be as simple as: https://wiki.debian.org/Teams/Publicity/Announcements Neil -- signature.asc Description: Digital signature
Re: All DPL candidates: level of team management
Hi Lars, Thanks for kicking off the questions this year! On Tue, Mar 11, 2014 at 08:49:41PM +, Lars Wirzenius wrote: For all DPL candidates: We have a number of delegated teams. How detailed should the delegations be? I've written my view of the constitution in quite a detailed post at: https://lists.debian.org/debian-project/2014/01/msg00044.html But for a succinct version, It's basically you should delegate areas of responsibility, not process. What is the appropriate level of oversight, management, and control that the DPL and the project in general should have for deciding what the teams work on, and how they do their job? Firstly, I think it's important to note that the DPL should not be *deciding* what individual people work on, or how they do their job. It's absolutely against how we work as a project. However, there is a role for the DPL to guide what they believe (through their electoral mandate) to be the best path we should be following as a distribution. It's also the job of the DPL to enable things to happen. The DPL should ensure that the teams are being responsive, and that the teams are in good health. Ensuring that a particular team isn't being a pinch point and unreasonably blocking progress in an area is an important aspect. If there is concern in that area, then the DPL should try and work with the team to resolve it, attempting to find more people or money to help, or seeing if there's a way forward that can be agreed by everyone involved. Specifically on oversight, I think it's important that teams send out regular bits mails, and would encourage teams to do so. However, this is separate from control of delegates. In volunteer projects it's important to remember that you cannot force people to do anything: I prefer a constructive relationship rather than a dictatorial one :) Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Mon, Mar 10, 2014 at 02:20:11PM +0100, Wouter Verhelst wrote: On Mon, Mar 10, 2014 at 12:12:33AM +0100, Andreas Barth wrote: * Wouter Verhelst (wou...@debian.org) [140308 02:21]: So rather than accepting this amendment, I propose that we modify paragraph 3 read as follows, instead: --- 3. Updates to this code of conduct should follow the normal GR procedure. However, the DPL or the DPL's delegates can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. --- The idea here is that a DPL can add a link to something considered useful, while normal DD's can still add such a link through a GR if the DPL is opposed. How's that sound? Just a minor point, I think we should put the or the DPL's delegates in () because according to the constitution the DPL could delegate these powers anyways (and so this part is just repeating what our constitution says, and not something special for this decision here). Yes, that sounds slightly better. So, basically, we have now: - My original proposal, which has received enough seconds, - Neil's amendment A, which adds the current mailinglist CoC to the further reading section. I have accepted that amendment in 20140308012109.ga...@grep.be, and no sponsors have objected, so under A.1.5 of the constitution my original proposal is replaced by Neil's amendment A. - Neil's amendment B, which I have not accepted (and which I will not accept either) and which has received enough seconds. However, I have suggested some minor adjustments, and Neil seems to have accepted them (though not formally so). Formally accepted :) If Neil were to formally accept my amendment to his amendment to my GR proposal (or possibly, Andreas' amendment to my amendment to Neil's amendment to my GR proposal -- still with me? ;-), that would end us up with two options on the ballot rather than three (not counting FD), which I think would be a plus. Sounds good to me. Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Mon, Mar 10, 2014 at 10:19:07PM +0100, Wouter Verhelst wrote: On Mon, Mar 10, 2014 at 09:03:19PM +0100, Kurt Roeckx wrote: ol liThe Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. liUpdates to this code of conduct should follow the normal GR procedure. However, the DPL (or the DPL's delegates) can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. liThe initial text of the code of conduct follows, in markdown format. /ol Yes, that's what I think should be done. Neil, can you confirm? Yup, confirmed. Kurt: For avoidance of doubt, please update Amendment A to read as quoted above. Neil signature.asc Description: Digital signature
Re: GR proposal: code of conduct
Hi Wouter, On 8 Mar 2014, at 01:21, Wouter Verhelst wou...@debian.org wrote: On Wed, Mar 05, 2014 at 06:05:45PM +, Neil McGovern wrote: Amendment A - move mailing list CoC text to further reading After some consideration, I accept this amendment. Thank you very much :) Amendment B - Updates to the CoC should be via developers as a whole So rather than accepting this amendment, I propose that we modify paragraph 3 read as follows, instead: --- 3. Updates to this code of conduct should follow the normal GR procedure. However, the DPL or the DPL's delegates can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. --- The idea here is that a DPL can add a link to something considered useful, while normal DD's can still add such a link through a GR if the DPL is opposed. How's that sound? That sounds very sensible to me, I’d be happy to accept it. I’m not sure what formal process Kurt would like me to follow to get these incorporated - Kurt? Neil -- 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/597df157-8055-4a2d-aff4-9e83f9e81...@halon.org.uk
Re: Debian Project Leader Elections 2014: Call for nominations
On Sun, Mar 02, 2014 at 06:47:24PM +0100, Debian Project Secretary - Kurt Roeckx wrote: Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. Hi Kurt, I hereby nominate myself as a candidate for the 2014 DPL election. Dear DSA, until the outcome of the election is clear, please remove me from gid 1231 and 1183 (secretary and debvote). Thanks, Neil signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 11:23:48AM +0100, Stefano Zacchiroli wrote: On Wed, Mar 05, 2014 at 06:05:45PM +, Neil McGovern wrote: Amendment B - Updates to the CoC should be via developers as a whole Justification - I believe that this document should have the strength of being a whole project statement. Being able to be updated by a single person doesn't feel comfortable with me. I understand this argument, but the DPL is not a random single person in Debian, he/she is someone elected by project members. I therefore don't buy that allowing the DPL to change the CoC will diminish in any way the communicative strength of the CoC. I know, but I didn't use the word random :) I think I disagree though that the weight of the CoC is unaffected by the ability of one person to change it - the project as a whole has chosen to endorse (or not, depending on the outcome of the vote) the CoC, rather than endorsing its current state, and allowing the DPL to change it. Similarly to a foundation document, or the diversity statement, it's a position of the project. Also consider that if a DPL (or delegates) try to change the CoC in a way which is not to the liking of many in the project, we do have the ability to override that decision. And that's not theoretical: it has happened in the past. I don't think we lack the needed check and balances here. Indeed, it's not a checks-and-balance thing for me. It's about making a fundimental statement. I believe that the current document is non-specific enough that there shoudn't be a requirement to change it easily, and indeed that would potentially open up the DPL to various accusations of bias for unilaterally changing something. I'm also wary of the difference between a) having a GR to add something and b) explicitly overruling the DPL. So, even if this second amendment is accepted by Wouter, I'd rather vote on two options: one where the DPL might change the CoC, and a separate one which requires a GR. Assuming I'm not alone on this --- public feedback welcome --- it might be simpler if Wouter simply does not accept Neil's second amendment. Indeed, I would also prefer it if it was on the ballot separately! I think it's a point that should be put before the developers as I'm aware that my personal view on this may or may not be shared by the developers in general! Thanks, Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 06:33:44PM +0100, Kurt Roeckx wrote: On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: Hi all, This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. So I've put up a vote page with my current understanding at: https://www.debian.org/vote/2014/vote_002 I've made some minor changes since the version that's there now. I intend to mail debian-devel-announce about this soon, so feedback about the current page is welcome. lfciu6$eiu$1...@ger.gmane.org has some seconds in too. Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 06:37:41PM +0100, Kurt Roeckx wrote: On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: == 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. So I've been wondering under which part of the constituion I should be putting all the options. Are they position statements? That's what I'd probably classify it as, similar to the diversity statement (ie: 4.1.5). Wouter? Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 06:19:56PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: GR proposal: code of conduct): Wouter, are you going to accept Neil's amendment, or should I create 2 options? Wouter, please don't accept Neil's second amendment (the one disallowing modification by the DPL). If you do I shall have to propose another amendment to undo it :-). Indeed, apologies - perhaps I should have been clearer - I don't think that my second amendment should be accepted either! Neil -- 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/20140307182526.gj11...@halon.org.uk
Re: GR proposal: code of conduct
Seconded, but I'd also like a couple of amendments which I'll add in another mail. Neil On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct 3. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. 4. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct ## Be respectful In a project the size of Debian, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community. ## Assume good faith Debian Contributors have many ways of reaching our common goal of a [free](http://www.debian.org/intro/free) operating system which may differ from your ways. Assume that other people are working towards this goal. Note that many of our Contributors are not native English speakers or may have different cultural backgrounds ## Be collaborative Debian is a large and complex project; there is always more to learn within Debian. It's good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving Debian. When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better. ## Try to be concise Keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary. Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made. Try to stay on topic, especially in discussions that are already fairly large. ## Be open Most ways of communication used within Debian allow for public and private communication. As per paragraph three of the [social contract](http://www.debian.org/social_contract), you should preferably use public methods of communication for Debian-related messages, unless posting something sensitive. This applies to messages for help or Debian-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected. ## In case of problems While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion. Serious or persistent offenders will be temporarily or permanently banned from communicating through Debian's systems. Complaints should be made (in private) to the administrators of the Debian communication forum in question. To find contact information for these administrators, please see [the page on Debian's organizational structure](http://www.debian.org/intro/organization) # Further reading Some of the links in this section do not refer to documents that are part of this code of conduct, nor are they authoritative within Debian. However, they all do contain useful information on how to conduct oneself on our communication channels. - Debian has a [diversity statement](http://www.debian.org/intro/diversity) - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) by Enrico Zini contain some advice on how to communicate effectively. -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Wed, Mar 05, 2014 at 05:53:48PM +, Neil McGovern wrote: Seconded, but I'd also like a couple of amendments which I'll add in another mail. And here's those amendments. Amendment A - move mailing list CoC text to further reading Justification: I think that it's better to keep the CoC as a general purpose document, rather than have it specific to each medium. The information at http://www.debian.org/MailingLists/#codeofconduct is still useful as it stands. I'm hopeful Wouter will accept this one, as I don't think it substantially changes the CoC. - participants to its mailinglists, IRC channels, and other modes of communication within the project. -2. The initial text of this code of conduct replaces the mailinglist - code of conduct at http://www.debian.org/MailingLists/#codeofconduct - -3. Updates to this code of conduct should be made by the DPL or the +2. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. -4. The initial text of the code of conduct follows, in markdown format. +3. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct [snip] - Debian has a [diversity statement](http://www.debian.org/intro/diversity) - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) by Enrico Zini contain some advice on how to communicate effectively. +- The [Mailing list code of + conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for + advice specific to Debian mailing lists - Amendment B - Updates to the CoC should be via developers as a whole Justification - I believe that this document should have the strength of being a whole project statement. Being able to be updated by a single person doesn't feel comfortable with me. I'm less convinced Wouter will accept this, but I think it should be on the ballot! - 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct -3. Updates to this code of conduct should be made by the DPL or the - DPL's delegates after consultation with the project, or by the Debian - Developers as a whole through the general resolution procedure. - -4. The initial text of the code of conduct follows, in markdown format. +3. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct - Thanks! Neil -- signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On 2 Mar 2014, at 13:36, Michael Banck mba...@debian.org wrote: On Sat, Mar 01, 2014 at 11:17:12AM +, Neil McGovern wrote: I'm very wary about passing resolutions which require work from future persons unidentified. Presumeably it would need a person who is a) keen on the desktop system in question and also b) keen on a particular init system which isn't supported by the desktop by default. I'm not entirely sure that this person exists, or would be able to essentially maintain that support long term, this would leave the burden on the maintainer to carry something they don't care about. I assumed this person would be Matthew. To do so on their own, for the entire project? I think that falls under the second part of my last sentence. Neil -- 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/88595afa-1be6-42e8-8942-8f364c5b0...@halon.org.uk
Re: Proposal - preserve freedom of choice of init systems
Hi Matthew, On Fri, Feb 28, 2014 at 11:45:01PM +, Matthew Vernon wrote: Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. Assuming that a desktop system only works with logind session management for screen locking, and that no other software has yet been produced which provides this functionality; This sounds like it would be an RC bug from the above, but without anyone identified to put the work in to fix it. I'm very wary about passing resolutions which require work from future persons unidentified. Presumeably it would need a person who is a) keen on the desktop system in question and also b) keen on a particular init system which isn't supported by the desktop by default. I'm not entirely sure that this person exists, or would be able to essentially maintain that support long term, this would leave the burden on the maintainer to carry something they don't care about. Neil -- signature.asc Description: Digital signature
Re: Debian's custom use of Condorcet and later-no-harm
On Fri, Feb 28, 2014 at 04:50:47PM +, Ian Jackson wrote: In my proposal, the casting voter gets to choose between A and B and there less incentive to manipulate the system by voting FD. I'm just wondering, what was the purpose behind treating FD as a special case in the first place? Could it simply not be an option on all ballots, but treated exactly the same as all other candidates? Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
Hi Wouter, Thanks for all your work on helping bring this together so far, but I think this ballot is troubling on a number of reasons. On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. How do you see this being effective? Are you envisioning it being agreed to as part of the NM process perhaps? Additionally, how core is this to the project - could it be viewed as a Foundation Document? IRC channels are particularly interesting, as they also hold additional standards to be upheld. The actual text seems to be somewhat geared towards mailing lists, and then has other communication mechanisms bolted in to it. As an obvious omission, IRC ops aren't on https://www.debian.org/intro/organization. 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct Is this overriding the listmasters then? 3. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. So, we have a Foundation Document, or a Position Statement that's agreed by GR, and then can be changed by the DPL to a delegate. I don't think this is entirely constitutional... Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 03:56:29PM +0100, Didier 'OdyX' Raboud wrote: I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). That would certainly seem to be the case, but it would be illogical for a group who is happy to be overridden with a lower requirement to be prevented from doing so! In practical terms, if the tech-ctte was so minded, they could use some of the proceedures in 4.2.2 to essentially achieve this outcome. Ian - any thoughts on if your tech-ctte constitution GR could address this? Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 09:21:41AM -0800, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). Indeed, or at least to allow this to happen if tech-ctte wishes it. I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. So will I, but I believe it should be sufficiently clear at the moment to the developer body at large where the -ctte's view on this matter is. Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 05:11:17PM +, Ian Jackson wrote: Ian - any thoughts on if your tech-ctte constitution GR could address this? You mean my TC resolution draft. Nope, I meant your supermajorty etc draft. Snipping the rest, as that seems to be something for tech-ctte, rather than me :) Neil -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127172208.gm8...@halon.org.uk
Re: leader2013
On Mon, Apr 15, 2013 at 07:09:50PM +0200, David Kalnischkies wrote: Assuming Debian keyring refers to the package debian-keyring (which should be a reasonable safe assumption, right?) This assumption is incorrect: the Debian keyring is defined by devotee for the leader2013 vote as: cat /srv/keyring.debian.org/keyrings/debian-keyring.gpg /srv/keyring.debian.org/keyrings/debian-nonupload.gpg $DATADIR/leader2013/debian-keyring.gpg Neil -- signature.asc Description: Digital signature
Re: Debian's relationship with money and the economy
On Thu, Mar 14, 2013 at 08:13:02PM +0100, Lucas Nussbaum wrote: I think I would generally be fine about an informational message in Debian Project News about an fundraising campaign for something that clearly benefits Debian. Btw, in the specific example of your book, have you considered creating a Debian package for it? However, I don't think that making Debian press releases about such initiatives would generally be a good idea. My view as one of the press officers is that I'll issue press releases for newsworthy[0] items that the *project* has done, and DPN should have news items that are informative to people interested in the project. Thus, the launch of a new derived distribution, for example, would make a good entry in DPN, but I wouldn't issue a press release for it. Neil [0] Nice mnemonic: TRUTH - Timely, Relevant, Unusual, Trouble, Human Interest. Dear journalist unions, please don't strike me down for revealing your inner secrets. -- signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2013: Call for nominations
On Sun, Mar 03, 2013 at 11:02:06AM +, Moray Allan wrote: I nominate myself as a prospective DPL for the 2013 election. Thanks, received and is a valid nomination. Neil (as Assistant Secretary) signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2013: Call for nominations
On Sun, Mar 03, 2013 at 09:44:32AM +0100, Gergely Nagy wrote: Debian Project Secretary - Kurt Roeckx secret...@debian.org writes: Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. *clears throat* I hereby nominate myself as a prospective DPL. Thanks, received and is a valid nomination. Neil (as Assistant Secretary) signature.asc Description: Digital signature
Re: The other diversity statement
On Mon, Nov 26, 2012 at 12:58:04AM +, Thorsten Glaser wrote: I really should not be writing this. I should be sleeping. I have to get up for work in less than six hours. But I *really* would love to know a DD vote outcome on something like the below text, though written with less sarcasm, I guess. (If this vote proposal finds any Seconds, I'd be surprised and would be interested to see what came out.) Hi, Given that I don't see an actual position statement here being proposed, and you're not asking for seconds, perhaps a discussion on -project may be more appropriate, with a description of the 'problem' you're trying to solve. Neil -- signature.asc Description: Digital signature
Re: Gergely and Wouter: on the need of becoming a DPL
On Wed, Mar 14, 2012 at 02:50:59AM +0100, Wouter Verhelst wrote: Is there any other policies that you disagree with, No. and would you be looking to change any of these as DPL? Not without first trying to achieve consensus. I'm slightly confused by my being copied in to your reply then - do you feel it appropriate to ignore policies you disagree with and/or what would you do if you found the rest of the project out of step with your view of what the project should be doing? Thanks, Neil -- +Mulligan Your folk tale is inconsistent and confusing. +Mulligan I shall round up your local population and tell them good CHRISTIAN folk tales. +Mulligan Then build churches on all your pagan temples in order to stamp out your heathen idolatry. @Ulthar How about I give you the finger, and you give me my temples back? +Mulligan Tell me Mr Ulthar. How will you gather faith when you have no followers? * Mulligan makes a gesture and converts everyone to Christianity. +Mulligan Wow. I think we just summarised 800 years of history in about six sentences. pgpw46G2WLZjp.pgp Description: PGP signature
Re: Finding sponsors for Debian
On Tue, Mar 13, 2012 at 10:13:38AM +0100, Holger Levsen wrote: But I've learned that we need to communicate this a whole lot better. Ideas how ... would be best directed to debian-project :) Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120313091739.gk...@feta.halon.org.uk
Re: Gergely and Wouter: on the need of becoming a DPL
On Tue, Mar 13, 2012 at 05:00:12PM +0100, Wouter Verhelst wrote: Also, I think the CoC is wrong in making policy about who to send replies to. Some people actually prefer getting replies, while others don't. Since there's a header that nicely allows you to specify just that, I think a more useful rule in a code of conduct is use a mailer that respects the Mail-Followup-To: header, or respect it manually. This way, people can express their preference, and there should be no complaints about whether or not replies should be sent. Is there any other policies that you disagree with, and would you be looking to change any of these as DPL? Neil -- Erik_J good day! i hear this might be a good place to get some technical advice when one is debian eliterate :) pgpE96QWBru8B.pgp Description: PGP signature
Second Call for Votes - GR: Debian project members
Hi, This is a second call for votes for GR: Debian project members The timeline is: Voting period starts 00:00:01 UTC on Tuesday, 5th Oct 2010 Votes must be received by 23:59:59 UTC on Monday, 18th Oct 2010 The following ballot is for voting on a General Resolution on Project's membership procedures. The vote is being conducted in accordance with the policy delineated in Section A, Standard Resolution Procedure, of the Debian Constitution. The details of the general resolution can be found at: http://www.debian.org/vote/2010/vote_002 You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact secret...@debian.org. HOW TO VOTE First, read the full text of the GR and all amendments. The ballot does not claim to be complete rendition of the proposals, or even accurately depict the spirit of each proposal. Do not erase anything between the lines below and do not change the choice names. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. You may rank options equally (as long as all choices X you make are 1 or 2). To vote no, no matter what rank Further discussion as more desirable than the unacceptable choices, or You may rank the Further discussion choice, and leave choices you consider unacceptable blank. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. (Note: if the Further Discussion choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the Further discussion choice by the voting software). Then mail the ballot to: gr_nonpackag...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may optionally encrypt your ballot using the public key included below. Also, note that you can get a fresh ballot any time by sending a mail to bal...@vote.debian.org with the subject gr_nonpackagers - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 95912f50-8ac1-4eff-bed0-5c15aab62c72 [ ] Choice 1: Welcome non-packaging contributors as project members [ ] Choice 2: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by Devotee (DEbian VOTe EnginE) using the vote key created for this vote. The public key for the vote, signed by the assistant secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQINBEyqCvwBEADEMzdl7uFNp7pQnzU2xpiZ7bx7ayDJ7QkJMlqtBl8zThzfVNfV BRSBdEG/nQ8VCs3nOmfoYP6roPUDSduDtIQ2yZNTdRjjmZPmc9WkVlw0NP1wHrHz iSZ05cF1DD5IfXu16iEQT5IJpRRObqsk+WnM6c8bFRgbC13eYo3DYrq0wtL+6eik a4meXIjw0wxjTMVii1zKptLU8+leXiACcX7i2T8i4254ReK+NYquHzIkfGCsBBLR wphCy0aKcXRz0BRtQFWVDgNaNkErWBn7BA9SLs2nTEkFGlXatnJQRN/p9Cj2JCRs qRVTzcpho6+akt+GfGRJem2rYHruH1Ht+gUH7sb69Jn/W4hM6ja/cN+o48rOzU0U carLeFsMJAfgetlFMoP/qWBcJcWfvZJVKfkmPq05ykD21IMRn58QGNL7zThSMzXS S1CgffLI6hemrxAl5+bF2eHcNOaqGW7V6Z2++Oc7nSiHJvyaID4yRaJz9x/22+ug ayPswl2ZgWMJUo35gGaLVRCzAk56Sueb4Jt/qAI4rAVf+2ol9djj0ktEEK5lTr7l 2EUVWudiB9Kxz0zhI+Po9FW//+MMz9lviPlZRzQkHgDXLgQL0HGRYMbGE56tkb2Y eMFFsPgLpnyAzgEYrE+lWTudSFhjbJT9GfVahgTod5AWKqSHhfaQ3iNb/QARAQAB tEJWb3RlIGtleTogRGViaWFuIHByb2plY3QgbWVtYmVycyA8Z3Jfbm9ucGFja2Fn ZXJzQHZvdGUuZGViaWFuLm9yZz6JAj4EEwECACgFAkyqCvwCGwMFCQAbr4AGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECHdBYZbwaTsIh8QAKo8UAqXgqspzLbw beOhn5oY/P9JUE2rVuIf0HWWCLTg/N9CnkALMtHpYvmF9CkUecxhkuApg78EaHVZ bruuNR8fupTQUjASgK2h0c2dGIlhP6VNX8q+uYbzysLzXzIywBP+Qf6J7PNilLfX 7Yhc00ZCXizSdQA1+KvqKe6CGEexsY7y1Us4mkAWTxlh+5TIGfQRaOM1AHJ0RT89 W0btfw4esZQQkg88ybWxAuCdBguH6trTAyh6YZnv3c/mjkdJd9mHUommmigfto4+ F9+XhEwgf+k7fSWY9BzS0HHk34Hso6BQLg6p5nOWdXdTBBQ5bP9SVGLAAuL+Tvrz 8oY3xTq5YPkrD+5vnma7OScTzdGXGkXDHlTFiZ8E+yugjVjuxCgXgkXiY5Z495YM X7ZhdGgK8G07kU8CqtaFlWk+dNdZFM1cLKb6BmLSZuDAtzWcBDJ2/EJORUkKj8cl HDlOtdb5ZeiptdiZWFrlCdCBrcBD3mBU9ZxSVYj0++gVl+SEWJ3J7SrRzfk9mAR/ KMr82XsSCbvozJWwMEa0jEIsNF5ZZ4ICfYqUDZuGHaSHSZnUYHuGASd3wpZLsDHB 5l1YEYWr2tgxRrrx/zGqRB0/rgnlU1HPlzQdJaU9MY994IsjKzOdvavwgyMuKgvp 0gWqJEk3vb0NkWPZsGzNa3ndl3zOiQIcBBABCAAGBQJMqg5AAAoJEH9VuxKkD4Yu N98P/2jVC9CSeb+650TymSmYf9NIJFpAln31i/LNe/9VvsvZOa/b2EWVcrgJheXI jYYjQMPxX9yaza4kvYf1Ug39xX7Op9siR0xsOevO+AGpGstZwsxW1vcLEHvR59TH aPL4ch3vKit+m4igAhUs/iwt4Ww/TwMg/YUTTaC5luD+tLj85t4iqRVSY9j2cJpJ RN/Ou/dE3nJd6FukBM3q6cBjlikC9yEYl1nbap+iUFKS4A3Yui5v7YfzzU8Ed8Jb TC/Nn4qIGgpkfQwYnU5SqaVq9waYCjrspRpHfcAVLSN4zGoMWgBJojPrXdG6GQm2 dgn4VUcbcwfO8R2NILIGMItX/GfYewpdEtbe4Owuh3+c1isKQ32luirXyieECqwu RtXEGwbGC+9cR57kyT7h/MYQBiIZrIaL1+nsfYH9GmEL/5HQlnCIotlcxYPNPast An+4tthHeHklXHxzJ6Kf1qKUF09X+FZ9dOEDnmEu2dsKccy25bidAccz03vcckSw y3ufVvPBY8dCqyh4poMidlytygUT0SI54vkoplIim+afpNxzeUmHlu9PfyJ9PAPK
Re: Three common voting errors - how to avoid them
On Tue, Oct 05, 2010 at 03:25:58PM -0700, Russ Allbery wrote: Neil McGovern n...@halon.org.uk writes: Yes, it would. And so would expecting people to read the mail. Given that there were a number (28?) sent before voting peoriod started, I'm not convinced that people will actually do that. I'll be looking at automating how the announcements are sent out in future to help this. This is a very annoying workflow that makes things harder for voters. Can't we stop doing this? I'd much rather see the ballot sent exactly when the vote is open, so that people can simply reply to it immediately and vote. I'm sure I'm not the only person whose mail workflow is not well-designed for keeping around a message that I need to reply to at some set point in the future but can't reply to immediately. Yes, hence my last sentence above :) Neil -- return (test == true)? ( (test == false)? false : true) : ((test == false) ? false : true); -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006161205.gd4...@halon.org.uk
Three common voting errors - how to avoid them
On Mon, Oct 04, 2010 at 08:47:49PM +0100, Debian Project Secretary - Neil McGovern wrote: In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. You may rank options equally (as long as all choices X you make are 1 or 2). Please make sure you use a 1 or a 2. 'X' is not a valid vote. If you want to just mark the one you prefer, you can use a 1 next to the option you prefer. Then mail the ballot to: gr_nonpackag...@vote.debian.org. This means it shouldn't be sent to secret...@debian.org. I'm re-attaching the ballot below, with a Reply-To set for convenience. NOTE: The vote must be GPG signed with your key that is in the Debian keyring. Please remember to sign your vote :) - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 95912f50-8ac1-4eff-bed0-5c15aab62c72 [ ] Choice 1: Welcome non-packaging contributors as project members [ ] Choice 2: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Thanks, Neil -- No matter whether you use charcoal or pine-cones, you've got to ignite the fuel somehow. The traditional way is to use pieces of bark from a birch-tree. In the soviet era, we used Pravda, the newspaper of the Communist Party. Proprietary software licenses work just as well. http://tinyurl.com/yqnm58 signature.asc Description: Digital signature
