Re: Reimbursement rules for people traveling to a BSP
Hi, On 22/01/23 at 09:27 -0500, Tiago Bortoletto Vaz wrote: > On Sun, Jan 22, 2023 at 11:37:41AM +0100, Daniel Lange wrote: > > Am 21.01.23 um 22:34 schrieb Louis-Philippe Véronneau: > > > It used to be one could get an "automatic" (by this I mean, without > > > having to ask for pre-approval) budget of up to 100 USD for traveling to > > > a BSP. > > > > That process has been suspended by . > > ...which has been revoked by the current DPL in > https://lists.debian.org/debian-project/2020/08/msg00050.html > > So, as I understand it, the (semi-)automatic 100USD for basic BSP > reimbursement as started by Lamb is still valid. I think I started it actually, in https://lists.debian.org/debian-project/2014/11/msg00050.html However at the time it was not automatic. I don't know when it became automatic. Lucas
Re: Covering visa fees as part of flights+accommodation expenses for events
On 27/06/22 at 17:43 +, Stefano Rivera wrote: > Hi Daniel (2022.06.27_15:57:52_+) > > I think covering travel Visa fees makes a lot of sense. > > +1 +1 > > Thus I suggest a maximum fee for any Visa related activities, e.g. a default > > of USD 200, adjusted to inflation and (if necessary) relative Visa-cost > > insanity of DebConf hosting countries*. Because sometimes travel is required > > to just get a Visa, e.g. going to a larger city to apply in person. Of > > course - as with all our reimbursement - only the actual cost can be claimed > > with receipts. > > That sounds sensible. I'd go one step further and say that any > visa-related travel costs shouldn't be automatically covered, but > require the sign-off of the visa team (for debconf, or DPL otherwise). Yes. But I don't think that we should have a maximum fee, since the travel to the nearest embassy/consulate might be expensive in itself, but rather include this in the total cost in consideration for travel reimbursement. Lucas
Re: Debian.net Team
On 02/09/20 at 13:49 +0200, Jonathan Carter wrote: > Hey Lucas > > On 2020/09/01 16:05, Lucas Nussbaum wrote: > > On 01/09/20 at 15:29 +0200, Jonathan Carter wrote: > >> On 2020/09/01 09:14, Lucas Nussbaum wrote: > >>> 2. Keeping our important services sanely maintained. Your proposal is to > >>> sanitize *.debian.net a bit. I wonder if instead, we should have a list > >>> of requirements for *.debian.org that does not include "hosted on a > >>> machine managed by DSA". People would then continue to use debian.net as > >>> they do currently, but once the service grows to something really > >>> useful, it gets a review to ensure that it is maintainable, and can move > >>> to the debian.org without necessarily putting more load on DSA. > >> That's really a discussion you'll want to have with DSA, and it doesn't > >> seem that the project is in a position currently to add any more load to > >> the DSA team at this point. > > > > How does it add more load on the DSA team? > > If you intend to make decisions or set up additional policy regarding > how debian.org subdomains are used, then you're going to have to involve > the DSA with that. My understanding is that the current situation is that we have two categories of services: 1/ official services, under the debian.org domain, hosted on machines managed by DSA, where some recommended practices[1] are enforced. 2/ unofficial services, under the debian.net domain, where all DDs can add their own services, with no control/review. It has happened in the past that such services were lost because the maintainer went MIA, or the machine was lost, or I think that we agree that the problem you are trying to solve here is that some of the unofficial services are important services for Debian, and probably desserve more attention from the project. Also, we should avoid increasing the workload of DSA. What you are proposing is building a team that manages unofficial services on the debian.net domain. It might help services maintainers a bit, but I'm not sure it really helps the project enforce good practices for its services. My proposal was to keep debian.net for unofficial services, and instead make it easier to promote unofficial services to official services on the debian.org domain, by lifting the requirement that they need to be hosted on machines managed by DSA (and instead rely on cloud providers, for example), and designing a simple review process for candidate official services. This process would check things like: is the service sufficiently relevant/useful? is there a small team behind the service, or is it a one person's job? Is the code available and free? Are there critical design issues? DSA could of course participate in the review (and it would be great if they did), but it doesn't have to be their sole responsibility. And I don't think that managing DNS entries for those services would really be a huge workload. So I don't see a big increase on DSA's load here... Lucas [1] https://wiki.debian.org/ServicesHosting#Recommended_practices_for_Debian_services
Re: Debian.net Team
Hi On 01/09/20 at 15:29 +0200, Jonathan Carter wrote: > On 2020/09/01 09:14, Lucas Nussbaum wrote: > > 2. Keeping our important services sanely maintained. Your proposal is to > > sanitize *.debian.net a bit. I wonder if instead, we should have a list > > of requirements for *.debian.org that does not include "hosted on a > > machine managed by DSA". People would then continue to use debian.net as > > they do currently, but once the service grows to something really > > useful, it gets a review to ensure that it is maintainable, and can move > > to the debian.org without necessarily putting more load on DSA. > > That's really a discussion you'll want to have with DSA, and it doesn't > seem that the project is in a position currently to add any more load to > the DSA team at this point. How does it add more load on the DSA team? Lucas
Re: Debian.net Team
Hi, On 31/08/20 at 18:21 +0200, Jonathan Carter wrote: > 2. Create a new team to organise some aspects of everything under > debian.net, which would include: > > * Keeping the domain list on the above mentioned > DebianNet page maintained on a regular basis > * Maintain external contacts/relationships with > people and providers who we have special arrangements > with > * Help maintain the list of hosting providers listed > on the wiki page above > * Have accounts with the major hosting providers so that > they can also create new instances whenever there's a > new request from a developer > > There's more ideas that could follow too, but aren't essential right > now. For example, hosting some backup service for all these services (we > really have no idea if the people running them keep backups, or where > they keep them) and maybe assigning some emergency contacts who have > login credentials for at least important (debian.net) services seem like > a good idea. > > That's it in a nutshell for now. Any thoughts... or volunteers? I think that this proposal combines two quite different aspects, and that it might be better to keep them separate. 1. Maintaining contacts with infrastructure providers that are willing to help Debian. That's of course useful, but not limited to debian.net services. For example, some QA tasks could benefit from access to cloud resources. 2. Keeping our important services sanely maintained. Your proposal is to sanitize *.debian.net a bit. I wonder if instead, we should have a list of requirements for *.debian.org that does not include "hosted on a machine managed by DSA". People would then continue to use debian.net as they do currently, but once the service grows to something really useful, it gets a review to ensure that it is maintainable, and can move to the debian.org without necessarily putting more load on DSA. Lucas
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
On 19/02/20 at 23:17 -0600, Gunnar Wolf wrote: > Hello Lucas, > > Lucas Nussbaum dijo [Wed, Feb 19, 2020 at 11:45:43AM +0100]: > > > Most probably, the results will be announced by mail (and not > > > communicated during a meeting), because the bid review process has led > > > us to need to decide in this way. I cannot speak for the previously > > > appointed DebConf Committee¹, but for the iteration I have been > > > delegated for, I can promise you we will not hide problems™ — That is, > > > once we choose, I can commit that we will not hide the reasoning > > > behind our choice. Some of it will not be full-public, as -of course- > > > it includes important human interaction bits, but all important points > > > will be made public. > > > > You kind-of make it sound like what you promise was not done by the > > previous DC Committee. I'd like to point that details about the decision > > process and the rationale were provided after the DC20 decision. > > Yes. I think I can promise that, because I think the situation to be > different to what it was a year ago. And I know I'm getting ahead of > things; I do not want in any way to put pressure on the rest of the > DCC on this account — But I think we will decide by consensus, not by > voting. And that we can share the reasoning we are following. [..] > I acknowledge the decision and communication of it was quite harder > last year than what we are facing now. If the project has a problem with the level of transparency of the DCC, I think that it should be improved in all cases, not just when the decision is easier to make... > I don't say that DC20's decision was "intended to keep something > quiet" nor that "there's a truth that needs to come out". I can only > comment on what I saw as an close-but-still-outsider. I know that the > DC20 decision crosses many personal issues, and that explaining it > thoroughly will likely hurt. Honestly, I don't what there's left to explain. As stated in Stefano's email, a number of points were made about issues with both bids; we tried to decide by consensus but failed, because different members assigned different levels of importance to those issues; and, after ensuring that none of us would change our mind, we ended up voting. If I look back, I have two regrets: One is that we did not provide a rationale with the decision email. Merging Stefano's email with the decision email might have improved things slightly. On the other hand, all issues were discussed in public before. The other one is that our decision making process doesn't have an early check that there aren't any big unsolvable issue with the bid. In some sense, we ignore those Elephants until the final decision, which makes it harder to reject a bid based on those Elephants because in the meantime, we asked the bid team to do a lot of work on detail-level issues. We could have something like a "bid acceptability check", at the start of the process, to detect, discuss and formally decide on Elephants early on. One way to achieve that could be to poll regular DebConf attendees about the bid, to measure the proportion of those who would not attend such a conference. (Historically, we had issues with DC13 (because camp), DC10 and DC14 (because US), and DC18 (because Brazil) at least -- I don't remember if there were discussions about DC11 and DC16 but there could have been.) Lucas signature.asc Description: PGP signature
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
Hi, On 18/02/20 at 23:54 -0600, Gunnar Wolf wrote: > Most probably, the results will be announced by mail (and not > communicated during a meeting), because the bid review process has led > us to need to decide in this way. I cannot speak for the previously > appointed DebConf Committee¹, but for the iteration I have been > delegated for, I can promise you we will not hide problems™ — That is, > once we choose, I can commit that we will not hide the reasoning > behind our choice. Some of it will not be full-public, as -of course- > it includes important human interaction bits, but all important points > will be made public. You kind-of make it sound like what you promise was not done by the previous DC Committee. I'd like to point that details about the decision process and the rationale were provided after the DC20 decision. See the threads in https://lists.debian.org/debconf-team/2019/03/threads.html Specifically https://lists.debian.org/debconf-team/2019/03/msg00021.html > Within the DebConf committee and the wider DebConf team there have > been extensive discussions about Israel as a hosting country and we > acknowledge that there will be some members of Debian that prefer to > not travel to Israel for political reasons. > > Still the Committee felt the upsides of the bid were significant and > edged well over the Portuguese bid. But it was a close call. The five > member DebConf committee had a two hour final decision meeting and a > 3:2 vote in favor of Israel. And https://lists.debian.org/debconf-team/2019/03/msg00034.html > You can probably guess what they are, but here's a summary. Most of > these came up in the public team meeting, before. Not all of us agree > with all of these points, but they were all discussed: > > * There hasn't been a DebConf in Europe (where the majority of regular > attendees live) for a number of years now - by the old norms we are > long overdue for one. > * There are regular DebConf attendees (and orga members) who have stated > that they wouldn't attend a DebConf in Israel. Although Israel is near > Europe, we could expect lower attendance than Lisbon. > * The Haifa bid has on-site University accommodation. This massively > simplifies things for the organisers. > * Neither bid has a local team that is as strong as we'd like, but Haifa > appears to have a small edge here. > * There are some nationalities that may find it difficult or even > impossible to visit Israel. This isn't new territory for us; we > regularly have to deal with attendees being denied visas. > * Israel has big political issues. I would imagine that a large part of > our community objects to the country's behaviour toward the Palestinian > people, for example. > * We've held DebConf in politically questionable countries before, and > don't want to preclude a bid for political reasons. Obviously no > country is perfect, and it's all relative. This may be further than > we've been, before, though. > * Along those lines, it would be unfair to a bid team, to let them do > all the work to prepare a bid, and then reject it because of an issue > with their country. If there are political requirements for host > countries, they should be laid out in the submission guidelines. > * We don't want DebConf to be endorsing a country or a city. But we're > aware that those optics are unavoidable. Wherever we go, we will bring > a large portion of our community, have a (presumably) great time, and > share memories of it for years to come. > > Again, we were divided in which of these we supported, which we thought > the most important, and which we'd state less diplomatically :P > We spent a good couple of hours trying to build a consensus on a > selection. Once it was clear that that wasn't going to emerge, we went > with a vote. So: On 18/02/20 at 23:54 -0600, Gunnar Wolf wrote: > ¹ The fact that one of the Committee members left it, and is quite > vocal on his opposition to the choice made by it, makes it clear to > me that, even if the Committee had intended to keep quiet, the truth > will come out. I'm sure Jonathan can comment on the decision process > as he lived it. We don't have NDAs. I must say that I'm a bit shocked by this paragraph. If I summarize: - you are a member of the current DebConf Committee. - you take the moral high ground and promise transparency, while the transparency you promise is no better than the transparency of the DC20 decision process - you allude that the Committee that made the DC20 decision intends to keep something quiet, and that there's a truth that needs to come out. Lucas (For context, I was a member of the Committee at the time of the DC20 decision, and resigned on 2019-09-17, see <20190917135320.ga29...@xanadu.blop.info>)
Re: Repeating: Only the Automatic Approvals of BSP Reimbursements are on Hold; You scan still Ask
Hi Sam, On 10/01/20 at 05:35 -0500, Sam Hartman wrote: > TL;DR: You are welcome to ask for approval for attending a BSP or > similar; it's only the automatic approvals on hold. > > I heard two different people in an email thread claim that you cannot > get reimbursed for attending a BSP. > The only thing that is on hold right now is *automatic approvals*. > Just ask first. I'm curious, since I was the one that setup that BSP policy: Did you trace back when we went from "I am willing to approve reimbursement requests about attending BSPs" (which is basically what was in [1]) to "automatic approvals"? AFAIK, the only case where we had/have automatic approval was for DSA. - Lucas [1] https://lists.debian.org/debian-project/2014/11/msg00050.html
Re: Community Team - where we want to go
On 09/10/19 at 22:26 +0100, Steve McIntyre wrote: > * Proactively writing emails to those who habitually make the >community a hostile place, informing them that their behavior is >harmful to the community, that action may be taken in the future, ^ that sounds a bit strange given the team doesn't really have the power to take actions itself, but I can live with that. How official is this group? If it is not delegated, should it be listed (for example on https://www.debian.org/intro/organization.en.html) as an official contact point? (I believe it should not) Lucas
Re: hacking a home with free technology and Debian
On 02/10/18 at 17:25 +0200, Daniel Pocock wrote: > > - hardware controller: > > + a USB ZWave dongle > > Did you mean the Z-Stick[1] or another model? > > Z-Stick is rated highly in reviews[2] and the web site claims it is > aimed at open source and cloud-averse users. Yes, that's the one I'm using > Can anybody comment if they give a genuinely plug-and-play experience, > without needing firmware blobs or proprietary tools to get up and > running? Or are there even better alternatives for the > freedom-conscious Debian user? The Z-Stick just exposes a serial device. As far as I remember it worked out of the box with libopenzwave, and thus domoticz. Lucas
Re: hacking a home with free technology and Debian
Hi Daniel, On 15/09/18 at 00:45 +0200, Daniel Pocock wrote: > Hi everybody, > > I've got an interesting opportunity to completely replace all the > sockets, lights, heating controls and appliances in my Dublin house with > things that are free or easily hackable. > > Which direction are other people in the Debian and free software world > going with such projects? Searching the wiki, the only significant page > I found was a reference to X10 protocol[1] > > Other people have mentioned having some success hacking proprietary > devices that use Zigbee and ZWave. > > Can anybody comment on these or any other related technologies? > > Being more specific, at a bare minimum, I envisage having a small rack > with a Debian server, smart power sockets to control things like the > boiler and immersion heater and a range of lights around the house > controlled centrally. My experience in the world of home automation is that, when selecting the technology (X10, ZWave, etc.) you should look at the whole chain: - whether you can find software to control it - whether you can find hardware to control it (typically a RF transmitter device) - whether you can find end devices (switches, thermometers, etc.) that do what you need Whether the protocol is open or not does not matter much, unfortunately. What really matters is whether it has been sufficiently reverse engineered. The fancy new technologies don't have that many end devices available, or they are fairly expensive. (Or you might want to design your own devices, but that's not something I was willing to do) I've had some success with: - software: domoticz (not in Debian, but Debian-friendly, and there's an ITP). I mostly use it through its REST API to automate stuff or get data (into a munin plugin for example) - hardware controller: + a USB ZWave dongle + RFPlayer, a multi-protocol gateway that understands many (proprietary) protocols (but the firmware is closed source). There's another one on the market with a different set of protocols, called RFXCom - end devices: Zwave remove switches (beware of the max power they can handle if you want to control your heater), Oregon thermometers, OWL energy monitor, Zwave and Deltia Dore "pilot wire" devices (for electric heaters controller), roller shutters (note that there's two protocols on the market, and only one of them has been reverse engineered). Lucas
Re: shutting down httpredir.debian.org?
On 12/04/16 at 07:04 +, Peter Palfrader wrote: > Hi, > > we keep getting reports of httpredir.debian.org not working correctly, > such as intermittently just sending errors or redirecting to mirrors > that are out of date. This doesn't solve the issue of finding someone to maintain it, but wouldn't it be easier if, instead of trying to use all existing Debian mirrors, httpredir just used a smaller number of them, known to be quite reliable? Lucas
Re: call for help: partners program
On 16/03/15 at 10:13 +0100, martin f krafft wrote: also sprach Lucas Nussbaum lea...@debian.org [2015-03-16 09:45 +0100]: Obviously I'm not in a position to make long term commitments as the DPL. I'd welcome crazy ideas in that area, at least in a brainstorming phase. Maybe you could start by working on a list of possible benefits, and then discuss with the DPL and the project which ones we are willing to give to sponsors? Okay, so then let's assume we identify perk Foo; now there are three possible scenarios: a) you know best, do as you see fit — okay, forget that… ;) b) nice perk, but I think this should not be Silver but Gold and up c) no way we will offer this from n people, good idea from m people I can only dream of (a), and (b) would be really useful feedback. But what do we do in the case of (c)? Scratch it for lack of consensus? Push it anyway? What if it's hugely successful with our sponsors and doesn't change the project really, once people have come to accept it? What if it's a big failure and we won't do it again? I am asking all these questions now because such sponsorship brochure is a lot of work. I don't think any small team among us will be able to just get it right, and being able to obtain feedback from the community will be extremely useful. At the same time, however, I'd hate to create all this work (which does involve speaking with sponsors at some point), only to find that the efforts will get stalled because the Debian community can't agree to place this in the hands of a few and ride along. The DebConf15 brochure had some perks at some time that caused vicious debates, and while we removed the contentious ones, I think that the only reason we managed to actually get this brochure out was due to time pressure and just pushing things, which may have alienated some people. In the context of Debian partners, we do not have this time pressure and we don't have the ability to drive this to completion, unless delegated. Obviously, nobody would be interested to go against the majority, but knowing that there won't be consensus on everything, one still needs to be able to make a move with the support of the project. I think that it is the role of the DPL to break ties in that context, under Make any decision for whom noone else has responsibility.. Of course, that should be done after hearing opinions, including from teams such as the press team and the www team that are likely to be affected by many of the perks. I don't think that it makes sense to delegate that authority to the partners team. Its role should be to: - *propose* a list of Perks - rank them in levels (Silver, Gold, ...) - decide on values for their levels - translate non-financial contributions to a common scale I agree that some perks might be contentious. But there are also a lot of easy ones. Maybe start by building a list, and we'll see where this goes? - Lucas signature.asc Description: Digital signature
Re: call for help: partners program
On 15/03/15 at 14:51 +0100, martin f krafft wrote: Sorry for bringing up https://lists.debian.org/debian-project/2015/03/msg00020.html earlier today without having seen this message last month. also sprach Lucas Nussbaum lea...@debian.org [2015-02-17 14:02 +0100]: I would like to build a small group of people in charge of this program. Count me in. That's great! Steffen Möller (Cced) also volunteered. Maybe you too could start discussing how you want to organize, and get the ball rolling? Ideally, this program would be merged with a Debian fundraising team. Do we have a fundraising team? If not, then no need to merge, for then you are talking about the fundraising team, no? Anyway, details… 1) improve the DebConf fundraising processes, and keep in mind that it could be transferred from 'DebConf fundraising' to 'Debian fundraising' We're (DebConf fundraising) already looking at ourselves as that, at least when we take a step back, so I'd say that you can check this off. This was obvious in the discussion around a CRM, which we'll need desperately… 2) revitalize the partners team … and which I'd introduce as point 2.5). In fact… 3) discuss merging both efforts when they are both in a sufficiently good shape. … I wouldn't do it this way. Please let me propose an alternative idea that I think could get us further faster without disrupting DebConf fundraising until we're ready to. How about we revive the partners team and work e.g. on a brochure / marketing material (incl. all the benefits and stuff we sell), as well as a CRM (and cash collection automation).¹ Meanwhile, communications between this newly revived team and the DebConf team will be keep all on the same page and it might well make sense to prepare our DebConf sponsors e.g. during the DC16 cycle.² Once a CRM is in place and we have products identify that we can sell to our subscribers,³ then we can dive into the waters and merge in DebConf fundraising. The above plan looks good to me. Please let me know if you need something from me. - Lucas signature.asc Description: Digital signature
Re: call for help: partners program
On 16/03/15 at 09:32 +0100, martin f krafft wrote: also sprach Lucas Nussbaum lea...@debian.org [2015-03-16 07:55 +0100]: Please let me know if you need something from me. I would like to know how the procedure will be between now and then. Let's make it easy and say up-front that we will not allow a sponsor to gain influence over project decisions, no matter how much money they give us.¹ So we get to work and design the products to sell with our sponsorship brochure, i.e. bundling perks (benefits) for different levels. For instance, we might want to name sprints after our Silver+ sponsors, mention all Gold and Platinum sponsors in our press releases forthwith, and offer 50% discounts on the DebConf sponsorship packages of equal or lesser levels to all our sponsors. Obviously, none of this will be developed behind closed doors (though probably also not on a mailing list like this) and it'll be really useful to reach out to the community for feedback, scrutiny and ideas, but what I wouldn't want to do is develop this brochure in a mailing list discussion with dozens of people. I'd only be motivated to work on this if I was allowed to try things (within limits of course, and also respecting guidelines put forth in a delegation), make mistakes and recover from them. Can you imagine that we can pull this off? ¹) I think we could open ourselves to ideas about this later on, but that would certainly require a working programme and a lengthy discussion about values. So let's not even go there now. Obviously I'm not in a position to make long term commitments as the DPL. I'd welcome crazy ideas in that area, at least in a brainstorming phase. Maybe you could start by working on a list of possible benefits, and then discuss with the DPL and the project which ones we are willing to give to sponsors? Also note that one of the tricky parts of the partners role is the ability to consider non-financial contributions (e.g. hardware, hosting, sprint hosting, etc.). This is largely orthogonal, but must not be forgotten. The pending partners inquiries are all of that nature. Lucas signature.asc Description: Digital signature
Re: On Debian not using its money (was: Q to all candidates: SWOT analysis)
On 15/03/15 at 13:05 +0100, martin f krafft wrote: also sprach Lucas Nussbaum lu...@debian.org [2015-03-15 12:40 +0100]: I agree that it should be possible to improve on identifying a recurring, plannable, dependable income. But there hasn't been much response to requests for help in the related areas. For example, I only got one answer to the call for help for the partners program, which has been stuck for months now. The auditors team is also clearly under-staffed. I think the problem with both partners programme and auditors is that it's not entirely clear what the roles and the potentials are. I mean, what would it mean nowadays to help the partners programme? Wasn't it addressed in https://lists.debian.org/debian-project/2015/02/msg00070.html ? Quoting: I would like to build a small group of people in charge of this program. There are ideas floating around about having several levels (platinium/gold/silver/...), and a limited duration for membership. The team would be responsible for setting this up in a way that makes it possible to mix different kinds of contributions using the same rankings/levels. Then, the team would be responsible for evaluating requests for joining the program. There's a number of pending requests that could be used to benchmark the designed ranking. - Lucas signature.asc Description: Digital signature
Re: On Debian not using its money (was: Q to all candidates: SWOT analysis)
On 15/03/15 at 11:28 +0100, martin f krafft wrote: Our problem wrt money is IMHO that we don't have cash flow, i.e. recurring, plannable, dependable income, which can be allocated to budgets and necessary expenses, bypassing the substance which then only serves as our backup. The substance is one of the two things that distinguishes us from a startup seeking cash flow. The other difference is that we already have a very strong brand. It won't happen without careful design and a lot of work on our behalf, but it should definitely be possible to create this cash flow, especially if it were a project decision and delegated to a few. I agree that it should be possible to improve on identifying a recurring, plannable, dependable income. But there hasn't been much response to requests for help in the related areas. For example, I only got one answer to the call for help for the partners program, which has been stuck for months now. The auditors team is also clearly under-staffed. Regarding fundraising, we actually force the ones willing to organize DebConf to do our fundraising, while it would be much more sensible to have a 'Debian fundraising team' that just collects funds for Debian, have Debian allocate funds to the DebConf team for DebConf organization. But if we decide now that the DC16 team doesn't need to do fundraising because a Debian team will do that, and call for help to build such a Debian team, I fear that we might not get enough volunteers ;) Additionally, it is one of the areas of Debian where it's better if the DPL is not too involved, to maintain a clear separation of powers between the one making decisions (the DPL) and the ones making sure that those decisions are sensible (the auditors). So, unless there are people who are willing to do more work in that area, I fear that we will be stuck in the statu quo, and discuss this again during next year' DPL campaign. I wonder if this is actually such a big issue: there are many areas of Debian where things are not perfect, but are sufficently OKish not to be blockers. As long as we don't want to spend much more money, as teams are fine with not having annual budgets (but with each expense being approved separately) , and as we can continue to ignore potential sponsors that request a summary of Debian's income and expenses, we can probably continue like that. - Lucas signature.asc Description: Digital signature
call for help: partners program
Hi, Debian has a partners program (see https://www.debian.org/partners/). It is used to thank and advertise organizations that are supporting or helping us. Examples include: - hosting Debian infrastructure, or providing services used by Debian - providing hardware (or plans to buy hardware at a lower cost) - hosting sprints - supporting the LTS initiative - etc. Unfortunately, due to lack of time of the people that used to be involved, the partners@ team has not been able to keep up with addition requests. I discussed this program with DSA (which is one of the main teams making use of it, to thank hardware/hosting sponsors), and at least Luca Filipozzi is interested in helping getting the partners team back in shape. I would like to build a small group of people in charge of this program. There are ideas floating around about having several levels (platinium/gold/silver/...), and a limited duration for membership. The team would be responsible for setting this up in a way that makes it possible to mix different kinds of contributions using the same rankings/levels. Then, the team would be responsible for evaluating requests for joining the program. There's a number of pending requests that could be used to benchmark the designed ranking. Ideally, this program would be merged with a Debian fundraising team. However, at this point, most of what Debian does in terms of fundraising from large organizations (not individuals) happens through DebConf. I fear that merging this now would be too big, so I think that the plan here should be to: 1) improve the DebConf fundraising processes, and keep in mind that it could be transferred from 'DebConf fundraising' to 'Debian fundraising' 2) revitalize the partners team 3) discuss merging both efforts when they are both in a sufficiently good shape. So, at this point, I'm looking for 2-3 people interested in creating a partners team. - Lucas signature.asc Description: Digital signature
Re: What do you expect from the DPL?
On 16/02/15 at 20:39 +0100, Ondřej Surý wrote: Just few random notes... On Fri, Feb 13, 2015, at 04:08, Paul Wise wrote: - Mediation regarding social and technical problems The former seems like the responsibility of Debian as a whole and the latter is the responsibility of the CTTE. I have several occasions in my mind when I would be happy if someone has stepped in and helped with mediation. For my own sake, and for the problem sake. Note that it can also have very negative effects if someone jumps in and starts mediating when none of the parties involved have actually asked for mediation. So, in general, if you think mediation from someone would be helpful, it's better to be explicit and request it. I view CTTE as a heavy hitter and DPL could use more soft approach before the parties approach CTTE. Having the DPL and the CTTE involved at the same time is a bit problematic, as they are defined as two very separate and independent bodies in the constitution. In the case of issues with CTTE member(s), I think that a better first step is to approach another CTTE member, or the CTTE chairman, and then if this fails, to approach the DPL about it. Also sometimes there is a feud between developer and delegate. This is also area where DPL could step in and help with the outcome. Sure. Lucas signature.asc Description: Digital signature
Re: What do you expect from the DPL?
Hi, On 13/02/15 at 11:08 +0800, Paul Wise wrote: On Fri, Feb 13, 2015 at 4:57 AM, Ana Guerrero Lopez wrote: Lucas sent an email asking people to encourage their 'dream DPL' [1]. I have already encouraged a few people in the last weeks, but when discussing with them, they all tell me very different things about the DPL role. When I asked: What are you expecting the DPL to do?, I got a bunch of different replies: The DPL role is defined in the constitution. https://www.debian.org/devel/constitution#item-5 Please note that it's very well possible that the constitution is wrong, or needs to be changed, as Debian changed a lot since that document was originally written. For example: The Project Leader should not use the Leadership position to promote their own personal views. This has been violated by several DPLs (me included), who pushed forward things they cared about, or discussed them in interviews, without necessarily first ensuring that it matched the project's consensus. My own view on the original question (What are you expected the DPL to do?) is that the main thing the DPL must absolutely do is being a good garbage collector (I think the original naming comes from Zack). There are lots of areas of Debian that suddenly get broken, often in unexpected ways, or where there's no-one clearly responsible. And usually, the DPL ends up being the ultimate fallback for those things. This is also what makes the role particularly hard: the DPL usually get involved when it's (too) late to find easy solutions, or in areas that are not covered by the typical expertise of a DD. It's also the most crucial part of the role because often, there are people blocked by the lack of progress, being deeply frustrated about their Debian involvement due to that. Of course, when there's a recurring flow of requests in the same area of expertise that end up in the DPL's hands, it makes sense to create a specific team to work on those issues. That's what was done recently with the trademark team, and the auditors team (to improve interactions with TOs, deal with reimbursement requests, etc.). But creating teams out of nothing is also not particularly easy, especially in non-technical areas. Then, with this 'Garbage collector' / 'Facilitator' part is covered, there are of course lots of other things the DPL can do using the remaining time, but, IMHO, they mostly fall in the 'Could do' rather than 'Must do' category. Also, as Paul pointed out, we have teams covering most of the areas listed in Ana's email, and it is not healthy when the DPL starts overstepping on those teams' work. Commenting on some of the list from Ana's email: - Set technical goals for the project That seems like the responsibility of Debian as a whole. That's indeed something that is the responsibility of everybody, and of no-one in particular. In the past, we had 'release goals'. But when I worked on the release team delegation, it was really hard to include something about release goals (see thread at http://deb.li/3D9kV). Do we need an entity in Debian that decides on the technical agenda? (That's probably a good question for DPL candidates :P) - Be aware of everything that goes on with Debian. E.g. I have the feeling some people expect the DPL to read all the Debian mailing lists. That is simply not feasible, even though the amount of discussion that goes on in Debian feels like it is going down over time. Interestingly, that is part of the constitution, though: The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. My own take on this is that various other people have been doing that very well (probably better than what I would have done), so I've generally decided to focus on things where the DPL was the bottleneck, rather than things that are already well covered by others. - Debian representation: give talks on behalf of Debian in important conferences or congresses. Also give interviews. - Handle the relationship with the open source ecosystem I would add here: - Handle the relationship with the Free Software ecosystem There isn't anything in the constitution about interacting with external entities. As the Leader, the DPL is probably better known outside Debian than most Debian members due to external press coverage etc so it makes sense that they would be contacted more often about being a speaker. I think that Debian as a whole should be responsible for interacting with external orgs, giving talks/interviews etc. We do have a number of folks who have volunteered to be speakers at least: https://www.debian.org/events/speakers Regarding talks, my experience is that most event organizers are not ready to cover travel costs. Which turns the question into: Given the expected impact of the talk, is it worth spending Debian money to cover
Re: Debian Project - Donations Question
Hi Anthony, On 08/01/15 at 15:51 -0800, Anthony Hunter wrote: My name is Anthony Hunter and I'm inquiring as to who is the best contact to discuss about your donations program? If you are interested in hardware donations, please see https://wiki.debian.org/Hardware/Wanted and contact hardware-donati...@debian.org If you are interested in donating money, please see https://www.debian.org/donations and contact audit...@debian.org Thank you for being willing to help Debian! - Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150109071913.ga27...@xanadu.blop.info
Re: Alternative proposal (+call for seconds): Expire 2-R members every year
On 06/12/14 at 13:26 -0800, Steve Langasek wrote: On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote: Rationale - First, I think that there is wide agreement that a more regular turn-over among TC members would be a good thing. And both Stefano's and this proposal aim at addressing this, by ensuring that at least 2 members of the TC are replaced every year. However, too much turn-over, with more than 2 replacements at one point of time, might have negative effects too. The TC might be temporarily weakened by having more young members; replacing more than two members at one point will cause less replacements later; it increases the difficulty of finding new members. The recent situation, with three TC members resigning, should not be treated as exceptional in the context of this resolution. If it were to happen again, I don't think that we should add one or two automatic expirations to the three resignations. This proposal differs from the original proposal by counting all resignations and removals as part of the desirable 2 per year replacement rate, so that the total number of replacements does not exceed two if only one or two younger members decide to resign. This version of the proposal could even result in an internal TC discussion: OK, the Project wants two members to be replaced. Are there members that feel like resigning now? Or should we just fallback to the default of expiring the two most senior members?. I think that such a discussion would be a healthy way for each TC member to evaluate its status. The orignal proposal could have the detrimental effect of pushing inactive/demotivated members to stay on the TC until their expiration, to avoid causing additional churn. The pathological corner case here appears to be that the longest-serving member of the TC could evade the term limit indefinitely. A scenario that assumes good faith on the part of all TC members is: - The longest-serving member of the TC spends a minimum amount of time engaging with TC issues. They vote on all resolutions, but don't spend much time cross-examining the petitioners, nor do they participate in resolution drafting. From their perspective, they are doing their duty on the TC, but other members of the TC have a faster response time to issues and therefore wind up doing the bulk of the work. - The other members of the TC all are very passionate about their work on the committee. (They've all been serving less than 3 years, so they have a lot of passion for it.) They engage with every issue, spend several hours each week on trying to make the TC serve the needs of the project as best they know how. And once or twice each year, there is a big issue that lands on the TC's desk, with social and technical issues intertwined and that require a lot of energy to pick apart. Once a year, one of these issues further devolves into a public flamewar where the ethics of the TC members themselves are called into question. And as a result, two members of the TC per year resign. - With the minimum turnover requirement met, the longest-serving member continues to serve as long as they are comfortable doing so. Did you consider this corner case in your analysis? If you think this corner case is less important than the risk of high turnover in the TC, could you elaborate why you think this? Your scenario describes a case where a member of the TC fullfills their voting duties, but does not otherwise really participate in TC work. This can happen, but I don't really see a correlation between this happening, and the seniority of that specific TC member. One could imagine a scenario where a recently-appointed TC member goes semi-MIA very early, and still stay on the TC for 4 years. After all, in Debian teams, people go MIA for various reasons, and this is not correlated with their seniority in those particular teams. I think that the root goal of this GR is to force more turn-over in the TC, which is a very desirable thing. Doing that by removing the most senior members every year is a reasonable default choice. However, the goal of this GR is NOT to provide a mechanism to automatically 'expire' poorly-performing TC members. I am not sure that this is necessary: we already have a mechanism to remove members of the TC (§6.2.5), which has already been used in situations where members of the TC had become inactive. I doubt that we need more than that. Also, if the version of the GR I proposed gets chosen, I hope that the fact that resignations or removals can 'save' other members from expiration will result in yearly discussions where the status and activity level of each member gets reviewed, which could actually help address the general problem of semi-MIA TC members. Lucas signature.asc Description: Digital signature
Alternative proposal (+call for seconds): Expire 2-R members every year
[ Cross post -vote, -project ; M-F-T: to -vote ] Hi, I am hereby formally submitting an alternative proposal, between double-dashed lines below (formally it's an amendment, but I don't expect Stefano to accept it, as we discussed it before). I am also calling for seconds (see below). === The Constitution is amended as follows: --- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 +++ constitution.2-R.txt2014-11-24 10:24:42.109426386 +0100 @@ -299,8 +299,22 @@ Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. -5. If the Technical Committee and the Project Leader agree they may +5. A Developer is not eligible to be (re)appointed to the Technical + Committee if they have been a member within the previous 12 months. +6. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +7. Term limit: + 1. On January 1st of each year the term of any Committee member +who has served more than 54 months (4.5 years) and who is one +of the N most senior members automatically expires. N is +defined as 2-R (if R 2) or 0 (if R = 2). R is the number of +former members of the Technical Committee who have resigned, +or been removed or replaced within the previous 12 months. + 2. A member of the Technical Committee is said to be more senior +than another if they were appointed earlier, or were appointed +at the same time and have been a member of the Debian Project +longer. In the event that a member has been appointed more +than once, only the most recent appointment is relevant. 6.3. Procedure --- === Rationale - First, I think that there is wide agreement that a more regular turn-over among TC members would be a good thing. And both Stefano's and this proposal aim at addressing this, by ensuring that at least 2 members of the TC are replaced every year. However, too much turn-over, with more than 2 replacements at one point of time, might have negative effects too. The TC might be temporarily weakened by having more young members; replacing more than two members at one point will cause less replacements later; it increases the difficulty of finding new members. The recent situation, with three TC members resigning, should not be treated as exceptional in the context of this resolution. If it were to happen again, I don't think that we should add one or two automatic expirations to the three resignations. This proposal differs from the original proposal by counting all resignations and removals as part of the desirable 2 per year replacement rate, so that the total number of replacements does not exceed two if only one or two younger members decide to resign. This version of the proposal could even result in an internal TC discussion: OK, the Project wants two members to be replaced. Are there members that feel like resigning now? Or should we just fallback to the default of expiring the two most senior members?. I think that such a discussion would be a healthy way for each TC member to evaluate its status. The orignal proposal could have the detrimental effect of pushing inactive/demotivated members to stay on the TC until their expiration, to avoid causing additional churn. Note that there are a few examples to compare the behaviour of the 2-S and 2-R proposals in 20141126142529.ga31...@xanadu.blop.info. Calling for seconds --- The DPL can propose general resolutions or GR amendments without seeking seconds. I initially wanted to waive that right, to only have this option on the ballot if there's sufficient interest from others, but the Secretary declined (in 20141124232153.ga17...@roeckx.be). I am therefore seeking seconds, and will withdraw this alternative proposal if it does not reach the required number of seconds by December 10th. Thanks -- I would like to thank Stefano for organizing the discussion around this GR, and preparing the various versions of the resolution and amendments. Lucas signature.asc Description: Digital signature
Re: donations and paypal
Hi David, On 16/11/14 at 18:31 -0400, David Prévot wrote: Hi, Le 16/11/2014 15:23, Lucas Nussbaum a écrit : (resending to -www@, #681501 is now archived) Resending to project, and setting follow-up-to accordingly: this is about the public image of the project, it’s not limited to the point of view and opinions of the people currently behind the website IMHO. I understand you care very deeply about this issue. However, this is not a reason to bounce my email from -www@ to -project@ without making it clear that you did that (by forwarding it instead of bouncing it, for example). Now, given that you want to express disagreement about my decision, I think that you should explain why _you_ think that: (1) Debian should not list paypal; (2) This is a serious enough issue to override auditors, who are normally in charge of managing how Debian receives donations; (3) What Debian should do instead, and how you are willing to help. Lucas signature.asc Description: Digital signature
Re: donations and paypal
On 17/11/14 at 16:09 +0800, Paul Wise wrote: On Mon, Nov 17, 2014 at 4:02 PM, Lucas Nussbaum wrote: However, this is not a reason to bounce my email from -www@ to -project@ without making it clear that you did that (by forwarding it instead of bouncing it, for example). FTR, I was the one who bounced the message, not David. Ah, then I apologize for blaming David. But given that you chose to move this discussion to -project@, I'd like to extend to you the same questions I asked to David. As I already wrote, I totally agree that Paypal is far from perfect, and, if there were some FLOSS-friendly payment processors available, I would love to see Debian advertise and use them. There's a simple path to scratch that itch: help design FLOSS-friendly payment processors, and help our TOs support them. However, in the meantime, I don't think that the problems with Paypal are a sufficient condition to refrain from using it. I actually see this discussion as similar to the one about the use of CDNs: CDNs are more an infrastructure issue than a free software issue; payment processors are a financial issue, not a free software issue. Lucas signature.asc Description: Digital signature
Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering
Hi, I think that everyone will agree that we are having a big crisis about the role of the TC in Debian. What saddens me deeply is how some of us framed this as a Debian vs the Technical Committee fight. The Technical Committee _is_ Debian. If we feel it's malfunctionning, it's our problem as Debian Project Members, and our responsibility to fix it. So I agree with what Steve wrote: On 16/11/14 at 11:37 -0800, Steve Langasek wrote: This demonization of the Technical Committee for doing their job under the constitution needs to stop. If you don't like the way the TC is structured under the constitution, feel free to propose a GR to change that. But if all you (and certain others across various Debian lists) are going to do is attack the members of the TC for making a decision they've been asked to in the way that they believe is technically correct, then I invite you to be the next Debian Developer to leave and I promise you I will not mourn your departure. I also would like to point out that decisions related to init systems (default, coupling, upgrades, etc.) are probably the hardest decisions that Debian ever had to make, because they mix political (Canonical influence vs Red Hat influence), philosophical (unix philosophy vs integrated solution), and technical aspects, and at the same time have an impact over a large portion of our packages. The fact that those decisions push our governance processes to their limits is not surprising. We need to be a bit careful here, and understand what are the root causes for the problems we are seeing, before discussing possible changes: depending on the identified causes, we could need a mix of constitutional changes for TC composition and processes, agreed good practices for the TC workflows, etc. At the same time, we need to find a way to continue to work, especially given that we are trying to release Jessie at some point in the near future. There are some decisions that Debian needs to make rather sooner than later, like the question of what to do about init systems during upgrades. Even if many of us expressed disappointment about how the TC worked recently, it served us well since 1998, so I am quite sure that we could find a way to return to a way of making decisions that is considered acceptable by most of us, until we agree on more radical changes to TC procedures. Specifically, I would like to ask Debian Developers to contribute (positively) to TC discussions when relevant, in order to help the TC get a complete understanding of the issues, their consequences, and possible resolutions paths. I was disappointed to see that only a handful of DDs (outside of TC members) took part in the recent technical discussions. Every DD should really feel welcomed to act like a (non-voting) TC member. I would also like to ask the TC to provide a bit more time for public discussions (during the technical discussions, and on draft CfV), as many project members felt that some recent votes were a bit rushed, and did not allow enough time for public review. Thanks, Lucas signature.asc Description: Digital signature
Travel reimbursement for BSPs
Hi, I was asked if I would consider reimbursing travel and accomodation costs for participation in Bug Squashing Parties. Fixing our RC bugs (and generally helping the release team with getting Jessie in a releasable state) is clearly something that we should all encourage and get involved with, and Bug Squashing Parties have an important role for that. So, I am willing to approve such reimbursement requests, with the following conditions: - The requester must already be a Debian contributor (and preferably have demonstrated an ability to contribute to this kind of work): I don't think that we should extend the sponsorship to people who are not yet involved in Debian. - The requester should agree to communicate about his/her activities during the BSP, in a blog post for example: the goal here is too increase the visibility of such work and contribute to making it everybody's problem. (Note that this point is not a strong requirement, but rather something that is nice to do.) - The max amount reimbursed will be 100 EUR or USD$125 (or equivalent): this should be enough to help attend a local/regional BSP -- if there's no such event, it might be a sign that one should try to organize such an event. - As usual, this should follow the processes described at https://wiki.debian.org/Teams/DPL/Reimbursement (And now people will be angry at me for not announcing this prior to the Paris BSP. Sorry!) Lucas signature.asc Description: Digital signature
donations and paypal
(resending to -www@, #681501 is now archived) Hi, I was asked to look into the question of whether (and how) we should list Paypal on https://www.debian.org/donations. I've gone through various discussions about Paypal, including the one on debconf-team (http://lists.debconf.org/lurker/message/20141010.131258.9c56bd7d.en.html). I agree that Paypal is far from a perfect service, for several reasons. We should clearly continue to offer alternative options for donations. However, I don't think that the known problems with Paypal are bad enough to surpass the the benefits of accepting donations via Paypal. Also, TTBOMK, the problems with Paypal are unrelated to Debian's main goals: for example, it doesn't require the use of proprietary software (even javascript). Paypal has also been used successfully already by Debian, e.g. for the OPW fundraising efforts. So I think that Paypal should be listed similarly to other donations: - not hidden in an 'other' section but listed directly similarly to Click Pledge; - provided with a form, not just a link, if auditors decide it's suitable and useful; - if auditors decide it is useful, listed at the top of the page for donations in Euros, if we can't find a better alternative. Of course, as a good practice, Paypal should not be used for long-term storage of Debian funds. This would limit problems in case of freeze of our accounts. If one can find a good, factual document that explains the various concerns about Paypal, it could be mentioned (in a footnote, for example). There's http://en.wikipedia.org/wiki/PayPal#Criticism, but it's mostly focused on the problem of automated freezings of accounts. However, it should be mentioned as an informational message that some people have expressed concerns about Paypal, not as a message that Debian discourages the use of Paypal. As I know that some members of the www team have strong opinions about this topic, I'd like to clarify that I am not asking them to implement those changes themselves. However, I am asking them to not reject a suitable patch, and to not revert a change that would implement this. Thanks, Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 23:13 +0100, Steve McIntyre wrote: On Mon, Oct 06, 2014 at 11:26:25PM +0200, Lucas Nussbaum wrote: On 06/10/14 at 20:38 +0100, Steve McIntyre wrote: On Mon, Oct 06, 2014 at 12:38:31PM +0200, Lucas Nussbaum wrote: On 06/10/14 at 12:07 +0200, Tollef Fog Heen wrote: Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. There were other occurences of reimbursement requests coming very late recently. It seems that some people wait until the deadline to do such tasks. Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. So that's a stupidly tight setup on their part, so what...? What actual *problem* are you trying to solve in Debian by arbitrarily reducing the limit for us? Given that we have no clear process to track reimbursement requests over time, late reimbursement requests often involve digging through email archives to understand their status. OK... How many such requests do we have to deal with? In those situations, it may take a little time. Complain to the people doing it when they're *too* late. But an arbitrary short cut-off is not helpful. I agree that improving the processes (using e.g. RT) would be better, but this hasn't happened yet. If you want to join the auditor@ team to make that happen, you're welcome. But I am already spending far more time than I would like on financial stuff. It's your call on how much time and effort you want to spend, of course. I don't remember having to spend much time at all on reimbursements as DPL, but you may have many more requests; I'll admit I don't know the numbers. I don't keep numbers about such requests, but I think that there are several factors: - the number of sprints increased a lot since 2010, resulting in more sprint-related reimbursement processes. - our infrastructure grew quite a lot, and DSA is more professional and organized, resulting in more expenses. - the process seem to have changed quite a bit. Apparently, you were only approving the initial overall budget for sprints, but the per-person reimbursement requests were handled directly by the TO, with the DPL out of the loop (which also makes it hard to understand the status of old sprints when a reimbursement request comes up after 6 years). - people seem to have higher expectation regarding reimbursement delays, and tend to complain to me. All those changes are probably good, but the auditor/DPL side of things did not really scale up accordingly, and my attempts to improve that side by recruiting more volunteers have failed so far. (but hey, I got two volunteers during this discussion) Also, I really don't see why you feel that it's necessary to have the possibility to wait for a year before submitting a reimbursement request. See Phil's response, for one. Personally, for small-ish things I often end up leaving them for a while until they bunch up enough to care about the money. Why is 3 months suddenly too long for that? You're changing something that doesn't need changing, AFAICS - that's why I'm asking you to justify why the change is necessary. So, I've updated https://wiki.debian.org/Teams/DPL/Reimbursement to add the following: If it is much more convenient to you to submit your reimbursement request later than that, you can submit it no more than a year after the corresponding event, but you must inform lea...@debian.org and audi...@debian.org of that delayed submission during the three-month period, with a rough estimate of the expense (+/- 10%). I think that this compromise addresses concerns on both sides: - we get a clear status about pending reimbursement requests (and their amount) after 3 months - we have the possibility to submit reimbursement requests later if needed Providing a rough estimate should not be a problem, given it is already required to get pre-approval. Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 07/10/14 at 09:18 +0200, Enrico Zini wrote: On Tue, Oct 07, 2014 at 08:12:49AM +0200, Lucas Nussbaum wrote: Providing a rough estimate should not be a problem, given it is already required to get pre-approval. If it's already required to get pre-approval, why ask to send it again? In order to keep a flexible and lightweight process, sprints are usually approved for a global (not per-person) amount: the sprint coordinator collects estimates for each participant, and then requests approval for the overall budget. But it often happens that a participant only provides a wild guess, or that the coordinator guesses for the participant, using an estimate from a participant from the same country, for example. That's not very important at that point of the process, but at the end of the 3m period, it's useful to get a more accurate view of the cost of sprints (for example, to build an overview of Debian's budget). If the participant provided an accurate-enough estimate, s/he can just re-use that when informing about delayed reimbursement. If not, then at this point, the participant needs to do the work to prepare an estimate. We could switch to a process where all participants providesan accurate amount prior to sprints approval, that serves as the max value for reimbursement, but I don't think that this would be popular. :) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007090236.ga20...@xanadu.blop.info
Update to reimbursement procedure (now: max 3 months after expense)
(Cced -sprints@ and dsa@, as those groups are the most likely to be affected by this change) Hi, https://wiki.debian.org/Teams/DPL/Reimbursement stated: As a general rule, no reimbursement requests will be processed if requested more than 1 year after the corresponding event (sprint, purchase, etc). I received a reimbursement request today for expenses made in 2008 and 2011. I don't think that we (esp. auditor@) have the energy to track reimbursement requests made so long ago, so I decided to stick to the above policy, and to reject this request. I also used that opportunity to update the wiki page so that it reads: As a general rule, '''no reimbursement requests will be processed if requested more than three months after the corresponding event''' (sprint, purchase, etc). (diff: 1 year - three months) Clarifications: - This applies to future expenses, but not to expenses which have already been approved. If you are unsure about the status of one particular expense, please contact me. - It's three months starting from the time when you can start asking for reimbursement. For sprints, it's when your travel is completed, not when you initially bought tickets. For hardware purchases, I don't mind if it's when the hardware is delivered or even set up, if there are doubts about whether it will work, for example. - This remains a general rule, and common sense will be applied: if there was a good reason to delay asking for reimbursement, I won't blindly reject requests, of course. As a reminder, the auditors team is still under-staffed. Tasks include: - improving our overview of Debian's financial status - working with our TOs to improve procedures (reimbursements, etc) - improving our donations fundraising processes and infrastructure - tracking of other assets (hardware, domain names, etc) If you are interested, please get in touch! Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 09:51 +, Martin Zobel-Helas wrote: Hi Lucas, i am a bit unhappy with that change, i can understand your move though. See reason below. On Mon Oct 06, 2014 at 10:53:13 +0200, Lucas Nussbaum wrote: I also used that opportunity to update the wiki page so that it reads: As a general rule, '''no reimbursement requests will be processed if requested more than three months after the corresponding event''' (sprint, purchase, etc). (diff: 1 year - three months) Clarifications: - It's three months starting from the time when you can start asking for reimbursement. For sprints, it's when your travel is completed, not when you initially bought tickets. For hardware purchases, I don't mind if it's when the hardware is delivered or even set up, if there are doubts about whether it will work, for example. FFIS insists in the original paper receipts. Every snail mail letter to FFIS costs me 55¢. While this is not much, with your change the number of letters i need to send raises for me. I tend to mail leader@, auditor@ and ffis immidiatly after the expense, but tend to collect the receipts for a while and then send a bunch of them to FFIS. Can we keep it that way, even if the time distance between two letters to FFIS is like... 6 months or so? Yes, I agree that this is a case where it make sense to consolidate reimbursement requests to save on the mailing costs. Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 12:07 +0200, Tollef Fog Heen wrote: ]] Lucas Nussbaum As a general rule, no reimbursement requests will be processed if requested more than 1 year after the corresponding event (sprint, purchase, etc). I received a reimbursement request today for expenses made in 2008 and 2011. I don't think that we (esp. auditor@) have the energy to track reimbursement requests made so long ago, so I decided to stick to the above policy, and to reject this request. I also used that opportunity to update the wiki page so that it reads: As a general rule, '''no reimbursement requests will be processed if requested more than three months after the corresponding event''' (sprint, purchase, etc). (diff: 1 year - three months) Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. There were other occurences of reimbursement requests coming very late recently. It seems that some people wait until the deadline to do such tasks. Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. Has the auditors requested this change? There's nothing in the DPL log about it. No. auditor@ is Cced to all requests, and I expect them to jump in if I tried to buy a bike or a poney with Debian money, but other than witnessing reimbursements, they do not participate/help in the process: all the load is on the DPL and TOs, and I can assure you that it's not very enjoyable. :-) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006103831.gc27...@xanadu.blop.info
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 13:33 +0200, Holger Levsen wrote: Hi, On Montag, 6. Oktober 2014, Lucas Nussbaum wrote: Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. /me too Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. or have it raised to 6 months. 3 month is really not that long, esp for those who are too being busy due to jobs or whatever. (While within a job one can do these request on job-time, so a shorter interval is more reasonable here.) Also we don't want to punish those we want to support :) Sure. But should we punish our Trusted Organizations with reimbursement requests that take several months? It takes 15 to 30 minutes to gather receipts, scan/snail-mail them, and request reimbursement via email. If for good reasons, you are temporarily so busy that it's not possible for you to find those 30 minutes in 3 months, I can accept that, and will not blindly reject reimbursement requests (especially if you send an email to inform that you will be late before the 3 months deadline). But on the other hand, I would like to set the expectation that reimbursement requests should generally be sent in less than 3 months, which seems to me like a totally reasonable deadline in the general case. Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 20:38 +0100, Steve McIntyre wrote: On Mon, Oct 06, 2014 at 12:38:31PM +0200, Lucas Nussbaum wrote: On 06/10/14 at 12:07 +0200, Tollef Fog Heen wrote: Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. There were other occurences of reimbursement requests coming very late recently. It seems that some people wait until the deadline to do such tasks. Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. So that's a stupidly tight setup on their part, so what...? What actual *problem* are you trying to solve in Debian by arbitrarily reducing the limit for us? Given that we have no clear process to track reimbursement requests over time, late reimbursement requests often involve digging through email archives to understand their status. I agree that improving the processes (using e.g. RT) would be better, but this hasn't happened yet. If you want to join the auditor@ team to make that happen, you're welcome. But I am already spending far more time than I would like on financial stuff. Also, I really don't see why you feel that it's necessary to have the possibility to wait for a year before submitting a reimbursement request. Lucas signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On 06/10/14 at 21:09 +0200, Tollef Fog Heen wrote: Somewhat of a separate problem, but it seems we're currently punishing our volunteers with delays of many months. AIUI, people are still waiting for reimbursements for the release sprint nine months ago. According to a quick email search, of the 7 release team members attending the sprint, only two of them submitted reimbursement requests (but there were 3 locals). Both reimbursement requests were handled (one only recently, due to missing receipts). Both SPI and FFIS are generally processing reimbursement requests in less than a month. (two days for a money transfer requested from SPI on Sep 20th; 6 days for a reimbursement requested from FFIS on Jun 26th). Debian.ch has been generally slower so far (which prompted my question in the TO evaluation thread). As a rule of thumb, if you think you submitted everything, and have been waiting for more than a month, it's a good idea to inquire about the status. Lucas signature.asc Description: Digital signature
Re: Prospective Trusted Organization - Debian.ch
Hi, On 05/10/14 at 15:52 +0200, Lucas Nussbaum wrote: == The organization should be reliable, sustainable, and reactive == As for reliability and sustainability, debian.ch has been running since at least 2008 without interruption, with annual general meetings (AGMs) and other in-person meetings. Between 2011 and 2013, [[http://debconf13.debconf.org|DebConf13.ch]] in Vaumarcus, was launched and conducted successfully by several debian.ch members. This involvement has hurt these members' reactiveness post- DebConf13 (which is visible through the time it took to fill this procedure); this is getting better these days. So, I must say that my experience of payments handled by debian.ch hasn't really been stellar: on at least one occasion, it has been necessary to send several reminders until the payments were finally made. Are you open to improving your processes regarding this? For example, have you considered using a ticket system such as RT (maybe Debian's) to follow payment requests? Also, have you considered switching to an organization where two people act as treasurer / backup-treasurer, and are able to process requests when needed? I had the impression that this was not the case, despite what you wrote about the president having access to the accounts, and that this was a factor in the OPW payments situation. Thanks, Lucas signature.asc Description: Digital signature
Prospective Trusted Organization - Debian.ch
Hi,
As you know, we now have a list of criteria to evaluate prospective
Trusted Organizations[1], which makes it possible to implement our
Constitution's §5.1.11.
Debian.ch is now ready to go through this process. You will find at [2]
how this organization relates to those criteria (wiki source copy-pasted
below, for convenience).
This email starts the official discussion period (of a minimum of two
weeks).
Thanks,
- Lucas
[1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria
[2] https://wiki.debian.org/debian.ch/TrustedOrganizationCriteria
---8
#pragma section-numbers on
See https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria
== Introduction ==
See the [[http://debian.ch/articles_of_association.pdf|debian.ch bylaws,
in english]]
== The organization should share Debian's general visions ==
{{{
The organization's bylaws, activities and political stance should not
conflict with the Debian Social Contract.
}}}
From the debian.ch bylaws, article 2:
§2 PURPOSE
1. debian.ch is the official representative of the Debian Project in
Switzerland and Liechtenstein.
1. The Association holds assets on behalf of the Debian Project in
Switzerland and Liechtenstein.
1. It supports the Debian project and its activities using the
Association’s assets.
Note that these bylaws were written under the earlier running state of
debian.ch actually being a TO. These highlight that the intent behind
the debian.ch association foundation was to explicitly be a
representative of the Debian project and support it and its activities.
== The organization should remain loyal to Debian ==
{{{
The organization should be considered fully trustworthy, or provide
guarantees that Debian's assets will be managed according to the Debian
Project's decisions.
}}}
From the debian.ch bylaws, article 5, about membership:
§5 MEMBERSHIP
1. Members of the Debian project with permanent residence or
citizenship in Switzerland (...) may choose to assert membership of the
Association and their membership is automatically accepted.
1. Any member may propose another person for admission as a member.
The General Meeting will decide on their inclusion. The proposed member
must be present at the meeting unless it is impractical for them to
attend.
1. A member can leave the Association debian.ch at his own request at
any time.
1. A General Meeting may choose to exclude a member without cause. A
majority of 2/3 of members present must vote in favour of such a motion
for it to be carried.
* 5.1. Indicates that the bulk of debian.ch members are
[[https://www.debian.org/vote/2010/vote_002|Debian members]], thereby
providing the loyalty warranties.
* For information, the current debian.ch Committee consists of odyx,
gaudenz and hug.
== The organization should provide accountability on assets held in
trust ==
The yearly financial statements are made public after each AGM.
Debian Auditors can ask for detailed account statements on request and
we're discussing ways of better integration with them.
== The organization should be reliable, sustainable, and reactive ==
As for reliability and sustainability, debian.ch has been running since
at least 2008 without interruption, with annual general meetings (AGMs)
and other in-person meetings.
Between 2011 and 2013, [[http://debconf13.debconf.org|DebConf13.ch]] in
Vaumarcus, was launched and conducted successfully by several debian.ch
members. This involvement has hurt these members' reactiveness post-
DebConf13 (which is visible through the time it took to fill this
procedure); this is getting better these days.
== The organization should provide a reasonable financial framework ==
=== Bank account ===
* debian.ch has an account at [[https://www.postfinance.ch/en.html|
Postfinance]] in CHF and a PayPal account. An EUR account could also be
opened if needed. These accounts are controlled by the acting debian.ch
treasurer. The acting debian.ch president also has access to the
accounts in case of need. Switzerland is part of the SEPA area which
allows us free bank transfers within the EU.
=== Spending ===
* debian.ch can spend it's money according to the associations goal,
which is support the Debian project. This includes transfers to other
TOs.
=== Tax-exemption status ===
* debian.ch did not apply for tax-exempt status, because the additional
bureaucracy and limitations outweigh the advantages at the moment.
* debian.ch is subject to tax on earnings if our yearly earnings exceed
5000CHF.
== Additional opportunities ==
* debian.ch has been (and still is) [[http://debian.ch/merchandise|
selling Debian-branded merchandise]] including the popular umbrellas,
swiss knives and stickers.
signature.asc
Description: Digital signature
Re: Debian Quiz game
On 03/10/14 at 14:00 +0200, Thijs Kinkhorst wrote: On Thu, October 2, 2014 11:45, Lucas Nussbaum wrote: It would be great if a team could magically form to maintain it as a Debian package. I'm Ccing people who already expressed interest in helping with this, but feel free to just join the fun! Maybe this fun Debian Quiz could also serve as some inspiration: https://www.df7cb.de/debian/quiz/ Indeed. (actually there already was a pointer to it in the git repo) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003171127.ga8...@xanadu.blop.info
Re: Debian Quiz game
On 03/10/14 at 11:48 +0200, Holger Levsen wrote: Hi Lucas, (bcc:ed the other interested parties...) On Donnerstag, 2. Oktober 2014, Lucas Nussbaum wrote: I've pushed the current state (with answers!) to collab-maint: http://anonscm.debian.org/cgit/collab-maint/debian-quiz.git/ It would be great if a team could magically form to maintain it as a Debian package. I'm not sure what the package should do? The original game is just a list on a website, how/why should this be much different? I do like the idea of just presenting the questions and hiding the answers a little but, eg in git. I don't have any strong opinion about where things should go. It could be turned into a simple HTML document with javascript to hide/show answers. But it could also be nice to translate the game using po4a. I also like the idea of shipping stuff we produce as Debian packages, even for such documents. (it makes bug tracking, releasing, etc much easier) But the bottom line is: whoever takes charge of this can decide! Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003100022.ga18...@xanadu.blop.info
Debian Quiz game
Hi, During one of DebConf14 evenings, I raised the idea of creating a 'Debian Quiz', inspired from the famous TCP/IP Drinking Game that used to be maintained by Valerie Aurora [1,2]. [1] http://valerieaurora.org/tcpip.html [2] http://sock-raw.org/netsec/tcpipdrink.html We quickly found 23 questions: Q: Give two names of girls that were originally part of the Debian Archive Kit (dak), that are still actively used today. Q: Cite 5 different valid values for a package's urgency field. Are all of them different? Q: What are most Debian project machines named after? Q: What does the B in projectb stand for? Q: Name three locations where Debian machines are hosted. Q: What happened to Debian 1.0? Q: Name the first Debian release. Q: what are Debian releases named after? Why? Q: Swirl on chin. Does it ring a bell? Q: One Debian release was frozen for more than a year. Which one? Q: Order correctly hamm, bo, potato, slink Q: Order correctly lenny, woody, etch, sarge Q: what was the first release with an and-a-half release? Q: name the kernel version for sarge, etch, lenny, squeeze, wheezy. bonus for etch-n-half! Q: What was Dunc Tank about? Who was the DPL at the time? Who were the release managers during Dunc Tank? Q: Which one was the Dunc Tank release? Q: Where were the first two DebConf held? Q: Describe the Debian restricted use logo. Q: What does piuparts stand for? Q: What is the codename for experimental? Q: Which DebConfs were held in a Nordic country? Q: What is the official card game at DebConf? Q: When was the Debian Maintainers status created? However, I lack the time to turn this into something better, so I'm looking for adopters. I've pushed the current state (with answers!) to collab-maint: http://anonscm.debian.org/cgit/collab-maint/debian-quiz.git/ It would be great if a team could magically form to maintain it as a Debian package. I'm Ccing people who already expressed interest in helping with this, but feel free to just join the fun! Lucas signature.asc Description: Digital signature
Re: On a policy for non-debian foss content in a mini debconf
Hi, On 06/09/14 at 16:31 +0530, Pirate Praveen wrote: Hi, There was recent discussions on debian-dug-in list [1][2] on the content of a mini debconf being planned in India during October 17 and 18. The event is being organized in an engineering college with a good track record of free software contributions [3]. I proposed a mini debconf in the hope of getting more contributions to debian. Since we did not get many debian contributors to attend the event and encouraging the student who already contributed to give talks on their Free Software contributions. But many in the community felt mini debconfs and debconfs have been primarily about debian and having other talks would confuse attendees. Some suggested 1/3 of the talks could be about debian as debconfs have a debian day where local community can join. I would like us to define the requirements of calling an event mini debconf as a policy so we don't have to have this debate every time we organize a mini debconf. My suggestion would be to leave that to the local organizers based on the strength of local communities to decide how much debian content would qualify for calling it a debconf. I'm also thinking about creating a new brand like debian utsav which would mean a joint event of debian and local debian community to share each others experiences. I was approached earlier this year (in April) about this event, and the possibility for Debian to sponsor this event. After seeking some feedback, I decided to allocate 4500 EUR, or 6000 USD, to this event, to participate in the funding of travel for Debian contributors to/from the event. The name of the event was not a very important factor for this; the fact that the event was focused on Debian was, as well as the recommendations I got from several DDs. Later, it seems that the people in charge of organizing this event had discussions about widening the focus. I was Cced late in that discussion, and clarified that (on Aug 20th): Debian can only support this event if it's centered on Debian. $6000 is quite a lot of money for Debian, and not something we can spend on non-Debian-centric events. However, if you want to make it non-Debian-centric, Debian could maybe just pay flights for one or two DDs that will give talks during the event. I think that the main discussion that needs to happen is between the organizers of this event, to decide what the focus will be. As I wrote On Aug 20th, Debian could maybe still sponsor travel for 1-2 DDs who would give a couple of talks each at the event, even if the event is not focused on Debian, provided that it is worth it for Debian (e.g.; what's the expected attendance at the event?). But time is running out, as prices for flights are going to increase soon. I don't feel the need for a stricter policy on the naming of MiniDebConfs. Events can get funding from Debian even if they are not called MiniDebConfs, and conversely, events named MiniDebConfs are not guaranteed to get funding. Also, I don't think that MiniDebConf is a strong brand yet. As Steve pointed out: why anyone would want to misleadingly describe something as a DebConf if it's not about Debian Lucas signature.asc Description: Digital signature
Re: Cooperation with the FSF?
Hi Ansgar, On 05/09/14 at 09:42 +0200, Ansgar Burchardt wrote: Hi, elsewhere I heard that there was some talk (also including people from the FSF) about cooperation with the FSF. Could anybody tell a bit more what current ideas are? I just remember the fsf-collab-discuss list on Alioth with sadly died rather quickly... You might want to check this talk, that provides a very good overview of the current status. https://summit.debconf.org/debconf14/meeting/110/debian-and-the-fsf-working-together-to-advance-free-software/ The video isn't available yet, and I can't find the slides online. I'm Ccing John Sullivan, maybe he can help! Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140905093328.ga19...@xanadu.blop.info
Debian participation in the Outreach Program for Women
Hi, The Outreach Program for Women, organized by the GNOME foundation, aims at helping women get involved in Free Software, in a scheme similar to Google's Summer of Code. Nicolas Dandrimont and Tom Marble (Cced) proposed to act as Debian coordinators for the winter edition of the program, which I happily accepted. :-) They will be in charge of finding sponsors to fund Debian's participation, seeking projects proposals, deciding which project(s) get selected for Debian slot(s), and generally dealing with the administrative work with the GNOME foundation. On the funding side, I've agreed to use up to $6,250 from Debian's reserves to help fund this participation. If the search for sponsors raises less than $6,250, Debian will pay the difference so that we can have one slot. If it raises between $6,250 and 2*$6,250, Debian will pay the difference so that we can have two slots, etc. Please get in touch with Nicolas and Tom (they are both at DC14) if: * you have ideas about possible sponsors * you have ideas about possible projects, or are interested in mentoring one yourself * you are interested in helping them organize all of this Thanks, Lucas signature.asc Description: Digital signature
Re: Updating the DebConf Chairs delegation
Hi, On 16/08/14 at 14:46 -0700, Steve Langasek wrote: I pointedly asked you in our private discussions: what problem are you trying to solve by appointing additional DebConf chairs? You did not respond to this question. Instead, you have delegated new chairs, reproducing the previous broken structure. [...] I would hope to have a constructive discussion about DebConf governance while we are all together in a week at DebConf14. But I am dismayed by this delegation right beforehand, which I think reflects a misunderstanding of the actual problems that face the DebConf team. Most of Debian teams (delegated or not) are small groups using consensus to make decisions. This provides a number of features, including: - the ability to make better decisions by taking more viewpoints into account (which is especially important for DebConf chairs, since this is mainly a non-technical role with many potential social/cultural issues) - redundancy, when one member goes MIA for non-Debian reasons - splitting/sharing the powers over several people I'm not sure why you think that a single chair would be an improvement, but I don't agree with that. I agree that DebConf chairs are sometimes under more pressure than other teams to make quick decisions due to the timely nature of DebConf organization. But I don't think that this is a sufficient reason to give up on consensus. Instead, it probably means that DebConf chairs is a team which needs to be as proactive as possible at uncovering possible problems, to limit the urgent decisions to the bare minimum. But then, I agree with you that we don't have a good shared understanding of the problems of the current DebConf governance. But we also do not have a good shared understanding of the solutions. There are many different ways to organize Free Software conferences, and if we make major changes to how we organize DebConf, or organize the organization of DebConf, we should make sure that we understand where we are going. I would very much like to participate in discussions about this during DebConf'14, together with the DebConf chairs. Lucas signature.asc Description: Digital signature
Re: [PHP-QA] Debian and the PHP license
Hi Ian, Thanks for bringing this up. On 30/07/14 at 13:09 +0100, Ian Jackson wrote: There has been an ongoing and wholly unproductive conversation on -legal about some difficulties with the PHP licence. Would it be possible for us to obtain some proper legal advice ? Do we have a relationship with the SFLC we could use for this ? Sure, we could ask for advice from SFLC about this. If so I would be happy to write up a summary of the facts and the questions to put to our lawyers. I think this is likely to be straightforward but I would send a draft to -legal and ftpmaster@ to check that the answer would actually resolve the problem one way or another. I think that such a summary would be very useful, at least to increase the awareness about the issue, and to improve the description of the violation on ftpmasters' REJECT FAQ. However, based on my own (possibly limited) understanding of the issue[1], this is case of a license (the PHP License) with sub-optimal wording that is misused by third parties, as it was initially designed for PHP itself, and is used for random software written in PHP. As a result, the license adds some restrictions for derivative works that could prevent software under that license to meet the DFSG. So I think that it is important to distinguish between two different questions: (1) Is there a legal risk for Debian to distribute such software? (2) Does the Debian project want to tolerate and ignore this sad situation, or try to make the world a better place by working on fixing this mess? [1] built on reading #728196, the thread starting at https://lists.debian.org/debian-devel/2014/06/msg00493.html and the one starting at https://lists.debian.org/debian-legal/2014/07/msg00024.html When you have a summary and questions ready, we can work together on forwarding them to SFLC for legal advice. Lucas signature.asc Description: Digital signature
Re: Updating the list of Debian Trusted Organizations
Hi, On 09/07/14 at 12:28 +0800, Paul Wise wrote: On Wed, Jul 9, 2014 at 12:23 PM, Brian Gupta wrote: Auditors team has been maintaining a list in the wiki [1]. I updated it to include the latest updates, but Lucas may have other thoughts about where and how to maintain the list. Im thinking that at minimum, the constitution should link to this wiki page. It feels a bit strange to have a very official document (the constitution) link to a very easy editable document (a wiki page). I would rather have a page on www.d.o listing the TOs... The donations page should also be updated to list those TOs that are willing and able to receive Debian donations. Yes. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711073019.gb17...@xanadu.blop.info
Task open for takers: review Debian status wrt OIN
Hi, One of the task on my TO-DO list that I would happily delegate is to review the status of Debian wrt the Open Invention Network, to possibly change our position from We are not interested in joining OIN to We want to join OIN, because: (1) OIN claims they have changed quite a lot over the years, so they might better match our needs, or be more useful to us, or Debian's joining OIN might be of high interest to the Free Software community. (2) it has been recommended by third party organizations that we join OIN. The tasks involved are: - review and summarize the past discussions on this topic (I'm quite sure that such a summary already exists somewhere) - review the current status of OIN wrt past concerns, maybe discuss with our contacts at OIN - present conclusions and a recommendation to the Project. This task is low urgency, but quite important. If someone is interested in working on that, please let me know, so I can share more details in private. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140703105617.ga32...@xanadu.blop.info
Re: Trusted Organisation status for DebConf15's legal entity
Hi, On 20/05/14 at 14:26 +0200, Richard Hartmann wrote: Dear all, is there anything more I can (or need to) do? No, that's on my TO-DO list now. Thanks, Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140520132445.ga17...@xanadu.blop.info
Re: Trusted Organisation status for DebConf15's legal entity
On 02/05/14 at 19:47 +0200, Richard Hartmann wrote: Dear all, as announced some time ago, we will incorporate DebConfDeutschland e.V. tomorrow. All founding members will be DDs with the full list being sent as a reply to this email after the fact. Given that: * We will not be using the name Debian * We are not planning to run for more than necessary for DC15 We would like to know: * If we need TO status * Assuming yes, what the next steps are Hi, Given that DebConfDeutchscland e.V. will still hold Debian funds, I think that it should become a TO. After all, the process is quite simple, and I don't expect any problems. As you already described how you met the TO criteria in cad77+gqwz0opgzi2qsgre3y3vbungtg6b4beqtcqbrz-wjh...@mail.gmail.com, I think that we can safely say that the minimum two weeks discussion period started on 2014-04-26 (and thus ends on 2014-05-11). Lucas signature.asc Description: Digital signature
Sponsoring a Tails hackfest?
Hi, The Tails project is a Debian-based live system focusing on privacy and anonymity. For more information about Tails and their relationship with Debian, see: https://tails.boum.org/ https://wiki.debian.org/Derivatives/Census/Tails https://tails.boum.org/contribute/relationship_with_upstream/ https://tails.boum.org/contribute/how/debian/ http://www.wired.com/2014/04/tails/ Tails is organizing a two-day hackfest and a contributors summit in July. They are requesting sponsorship from Debian for the events, in order to cover travel costs for contributors. Their overall budget is between 10kEUR and 20kEUR. Given that: - they are a derivative working closely with Debian (and being a live system, having their own public identity makes sense) - they are doing a lot of their work in Debian -- the hackfest could be seen as a Debian sprint - they are addressing important issues, and clearly contribute to Debian having something to say about such issues I am planning to allocate 5000 EUR. Comments? Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140503064307.ga1...@xanadu.blop.info
Re: Trusted Organisation status for DebConf15's legal entity
Hi, On 03/05/14 at 10:54 +0200, Richard Hartmann wrote: On Sat, May 3, 2014 at 7:53 AM, Lucas Nussbaum lea...@debian.org wrote: As you already described how you met the TO criteria in cad77+gqwz0opgzi2qsgre3y3vbungtg6b4beqtcqbrz-wjh...@mail.gmail.com, I think that we can safely say that the minimum two weeks discussion period started on 2014-04-26 (and thus ends on 2014-05-11). Works for me. Just to make sure: This means that unless someone raises objections, we can expect you to rubberstamp our status (and tell us what, if anything, else we need to do at that time?) Yes From the docs, the last step is not entirely clear to me, but it really seems to be as simple as you saying they are TO, please add to your list and sending to auditor@ The last step was never used so far AFAIK. But it could probably be implemented as a d-d-a email providing the updated list of TOs, and a page on the Debian website listing TOs and referencing the d-d-a email. (Similar to delegations and https://www.debian.org/intro/organization) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140503090343.ga29...@xanadu.blop.info
Call for Debian speaker(s) at Distro Recipes
Hi, Distro Recipes is a 2-day event organized in Paris (11+12 June 2014), aiming at gathering people from various distributions for talks and fruitful exchanges. The same group of people also organize Kernel Recipes. I attended last year's edition and really enjoyed it. Unfortunately, I can't attend it this year due to another event I really must attend for $day_job. So, I'm looking for 1-2 speakers to talk about Debian-related topics. Travel costs can be sponsored by the conference, and hosting can be provided at one of the organizers' place. Any takers? Please send talk proposals ASAP, and before 2014-05-08. I'll then forward them to the conference organizers. Lucas signature.asc Description: Digital signature
Re: Trusted Organisation status for DebConf15's legal entity
Hi, On 26/04/14 at 23:42 +0200, Richard Hartmann wrote: 2. The organization should remain loyal to Debian See 1. Going against Debian's best interest now or in the future would not only be stupid beyond description, it would also wipe out our collective reputations and remove the common cause that unites us as DebConf15 team members. At Lucas' request, we are working with our German lawyer to add something like board members must be DDs or similar into our constitution, but this will be a non-trivial legal construct, especially given that the Verein (association) is legally required to be an independent legal entity whose highest decision-making body is the members' assembly. Therefore, it'll be really hard to codify external influence as requested. For the German tax office, it'll be a stretch to bestow authority to an international formation such as Debian, and we certainly want to avoid having to explain what Debian is and how we make decisions. Whether we can make this happen or not: the board needs to approve new members before they can join and thus vote anyway. As a consequence, hostile take-over is very unlikely. I personally think that this could be enough, but would welcome more opinions on that. Lucas signature.asc Description: Digital signature
Re: Trusted Organisation status for DebConf15's legal entity
On 26/04/14 at 23:42 +0200, Richard Hartmann wrote: Before anyone raises this point: Yes, we tried contacting[1] FFIS, but they have not even answered in more than four weeks; we are not confident that they would be more reactive going forward and do not consider them an option any more. [...] Also, at least Ganneff and me would be willing to carry on the e.V. after DebConf15 if this is deemed useful to Debian. Given FFIS' performance (the above isn't a one-time event only, it's been this way for a long time), this seems likely. I think that we need to be very careful here. Being a TO is very difficult. And building a TO that is sufficiently reliable, over several years, is even more difficult. It's not a surprise that organizations such as SPI have grown to hold assets for several projects, because scaling up is a way to amortize the costs of the various involved processes. Also, most of the organizations holding Debian's assets have at times encountered some problems. More diversity among TOs has some useful features, but also some downsides: it becomes harder to make large expenses if funds are split over several organizations; it requires more coordination work from auditors. Similarly to how DSA is trying to reduce the number of datacenters hosting Debian machines, it makes sense to keep a quite low number of TOs just to keep the interaction overhead low. So I'm not against considering the idea of keep the DC15 TO after DC15, but this will clearly have to be weighted against the disadvantages of this option. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428200935.gb32...@xanadu.blop.info
Re: Prospective Trusted Organizations - FFIS
Hi Joey, On 11/03/14 at 11:58 +0100, Lucas Nussbaum wrote: == The organization should be reliable, sustainable, and reactive == * The organization has several people sharing the role of treasurer in order to react quickly to requests in all circumstances true. I was actually surprised by this: I've always thought that you were the only really active person behind FFIS. Could you elaborate a bit on FFIS' internal organization? I couldn't find that information on FFIS' website, but maybe I just missed something. Thanks, Lucas signature.asc Description: Digital signature
Prospective Trusted Organizations - FFIS
Hi, Following the discussion in https://lists.debian.org/debian-project/2014/03/msg00012.html, I asked FFIS to describe how they met the features listed at https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria. I'm forwarding their answers below; please use the next two weeks to ask follow-up questions. Based on this discussion, I will then decide whether to officially add FFIS to our list of Trusted Organizations. I haven't received answers from debian.ch yet. - Lucas - Forwarded message from Martin Schulze j...@infodrom.org - From: Martin Schulze j...@infodrom.org To: Lucas Nussbaum lea...@debian.org Cc: i...@ffis.de, audi...@debian.org Date: Sat, 8 Mar 2014 16:16:09 +0100 Subject: Re: Evaluation criteria for (prospective) Trusted Organizations -- FFIS Message-ID: 20140308151609.gx...@finlandia.home.infodrom.org Debian Trusted Organizations (TO) are organizations that hold and manage assets on behalf of the Debian project. The list of TOs is maintained by the Debian Project Leader (following [[http://www.debian.org/devel/constitution|Debian Constitution]] 5.1.11 and 9). In order to be accepted as a TO, an organization should provide some features, and satisfy some criteria. The list below should not be understood as required features, but rather as a set of desirable features. A prospective TO is expected to describe how it compares to this set of desirable features. TableOfContents() == The organization should share Debian's general visions == The organization's bylaws, activities and political stance should not conflict with the Debian Social Contract. == The organization should remain loyal to Debian == The organization should be considered fully trustworthy, or provide guarantees that Debian's assets will be managed according to the Debian Project's decisions. Some examples of possible implementations: * The organization has a long history of successfully holding a similar role for other Free Software projects true. * The organization is managed by highly respected members of the Free Software community true. * The organization has a leadership structure that ensures a minimum number and/or a majority of Debian developers * The organization has decision-making processes that explicitely delegate decisions on Debian assets to the Debian Project Leader true. == The organization should provide accountability on assets held in trust == Some examples of possible implementations: * The organization provides, on a regular and frequent basis (e.g. quarterly), detailed reports of assets tranfers and balance sheets, in a machine-parsable format. * The organization provides access to Debian's accounts live data, in a machine-parsable format. true. == The organization should be reliable, sustainable, and reactive == Some examples of possible implementations: * The organization is managed by a large group of active Debian Developers * The organization's managers have been involved in Debian or other Free Software projects for a long time, and have a high reputation of being reliable. true. * The organization has several people sharing the role of treasurer in order to react quickly to requests in all circumstances true. == The organization should provide a reasonable financial framework == For example, it is desirable that: * Donations and sponsorship are tax-deductible for the donor true. * Donations, sponsorship, income from sales and transfers from other TOs are not subject to income tax * There are no major restrictions on what kind of expenses can be made, either due to the organization's bylaws or to the legal framework of the organization Needs to support Free Software or free information. * There are no major restrictions on how the organization could transfer assets to another TO Some properties are often mutually exclusive (e.g.; ''tax-deductible for the donor'' and ''no major restrictions''). This is fine -- the goal here is to understand beforehand what will be possible for a specific TO. == Additional opportunities == Some organizations might offer additional services to their affiliated organizations, such as legal counsel. Some organizations have might plans that result in possible income for Debian, such are giving to Debian some of the result of the sale of merchandising. -- Linux - the choice of a GNU generation. - End forwarded message - signature.asc Description: Digital signature
Prospective Trusted Organizations - (FFIS), Debian France
Hi, Our constitution (5.1.11 and 9) describes a process to manage the list of Trusted Organizations: (5.1.11) The Project Leader may: Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations. There are three organizations that never went through that process, and that either we use as if they were already TOs, or they would like to officially become a TO: FFIS, Debian.ch, and Debian France. As previously announced, we (auditors, DPL helpers, myself) have been working on a list of features that a TO is expected to provide, or could provide, in order to use it as a basis for the public discussion. I contacted Debian France and Debian.ch and asked them to describe how they met those features. I propose to not ask FFIS to answer those questions, given they have been successfully handling some Debian assets for a long time (more than 10 years?). If nobody disagrees by the end of the two-week discussion period, I will officially add FFIS to the list of TOs. You will find below Raphael Hertzog's comments about Debian France (as Raphael is Debian France's president). Please use the next two weeks to ask follow-up questions. Based on this discussion, I will then decide whether to add Debian France to our list of Trusted Organizations. Debian.ch has not answered yet. - Lucas - Forwarded message from Raphael Hertzog hert...@debian.org - From: Raphael Hertzog hert...@debian.org To: Lucas Nussbaum lea...@debian.org Cc: audi...@debian.org, c...@france.debian.net Date: Fri, 14 Feb 2014 22:42:27 +0100 Subject: Re: Evaluation criteria for (prospective) Trusted Organizations -- Debian France Message-ID: 20140214214227.gd23...@x230-buxy.home.ouaza.com Hi Lucas, On Fri, 07 Feb 2014, Lucas Nussbaum wrote: As you know, we (auditors, DPL helpers, myself) have been working on implementing Debian Constitution 5.1.11 and 9, that is, a process to manage the list of Trusted Organizations. As Debian France is interested in becoming a Debian Trusted Organization, and Debian is obviously interested in accepting Debian France as Trusted Organization, we would like to go through that process with you. Sure, I'm ccing the Debian France board so that they can follow the process. There's a wiki page[1, also copied below for convenience] that lists features that a TO is expected to provide, or could provide. Could you please describe how Debian France compares to those features? If needed, we will then iterate a bit on your answers, and then I will forward them to debian-project@ to start the two-week public discussion period. [1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria == The organization should share Debian's general visions == The organization's bylaws, activities and political stance should not conflict with the Debian Social Contract. The bylaws are in French here: http://france.debian.net/documents/Statuts_debian_france_2.0.pdf Many of the points are deferred to the internal rules document (Règlement Intérieur) available here: http://france.debian.net/documents/RI_debian_france.pdf (The latter document can be easily modified by the board) The purpose of the association is to promote Debian and to help its development. There's no conflict with the Debian Social Contract. The bylaws now mention explicitly that Debian France might take the role of Trusted Organization for Debian. == The organization should remain loyal to Debian == The organization should be considered fully trustworthy, or provide guarantees that Debian's assets will be managed according to the Debian Project's decisions. The current board contains 7 DD and 2 non-DD: http://france.debian.net/equipe/ The internal rules imposes that the board must always be constituted of at least 2/3 of Debian Project Members so that the association is always in control of members of the Debian project. The internal rules (section 10.4) exposes the conditions under which Debian France is willing to act as a Trusted Organization. Basically we will honour all requests of the DPL as long as we get the corresponding invoice or appropriate supporting statement to meet our accounting requirements. == The organization should provide accountability on assets held in trust == We do manage our accounting with ledger in a git repository. We intend to give access to that git repository to Debian auditors. We will use some the ledger features to manage a separate analytic accounting dedicated to the Debian project since the assets of Debian will be kept separate from
Re: State of the debian keyring
On 27/02/14 at 11:11 +0100, Yves-Alexis Perez wrote: On Mon, Feb 24, 2014 at 05:35:34PM +0100, Lucas Nussbaum wrote: Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi Nice public shaming :) A large number of people still using 1024 bit keys are very active DDs. Well, a quick grep on the result shows that of those 652 uploads done using 1024b keys, only half of them were made since the beginning of 2013. Not really, the listing is about keys, not uploads (only listing the last upload for a given key). The correct interpretation is: | Well, a quick grep on the result shows that of those 652 1024b keys, | only half of them were used for uploads since the beginning of 2013. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228105204.ga21...@xanadu.blop.info
Re: State of the debian keyring
Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi A large number of people still using 1024 bit keys are very active DDs. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224163534.ga19...@xanadu.blop.info
Re: Possibly moving Debian services to a CDN
Hi James, On 08/02/14 at 13:48 +0800, James Bromberger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/02/2014 11:46 AM, Luca Filipozzi wrote: Have you been trying to reach out to other CDN providers about supporting Debian? I know of discussions with Amazon CloudFront, but I remember some technical blockers? Could the DPL be of some help to you in that process? I am in active discussion with another CDN provider and I should restart the CloudFront conversation. There are technical considerations with Fastly, also, that Tollef will work through. We've always been of the opinion that we need two CDN providers. We're just as concerned about vendor lock-in as anyone. Hello Luca, all, http://cloudfront.debian.net/ is continuing to do some traffic. It is also offering CDN acceleration for debian-cd and cdimage. We set up a second CDN distribution, http://cloudfront-security.debian.net/; however at this point in time CloudFront does not support IPv6. CloudFront now has 51 edge locations worldwide (having added Rio de Janerio, Taipei, Manila, Marseille and Warsaw recently) and supports custom SSL certificates if (Debian) want to do this. Wasn't there an issue (that might not be CloudFront-specific) about the refresh times of files in dists/? I remember reading about something like that. As to lock in - CloudFront is an http cache network - stop handing out the cloudfront.debian.net URL and traffic naturally drops off; nothing else do to. Sure, the hypothetical scenario which I'm worried about is: - there's only one CDN provider willing to support Debian, and able to meet our technical requirements - we switch everything to that CDN, and shut down our mirrors network - the CDN provider decides that, after all, it doesn't want to support Debian anymore Clearly, that's a long way from the current status, but that's something that we should keep in mind, and I was just slightly worried that it was not mentioned in Tollef's status update. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208084147.gc30...@xanadu.blop.info
Re: Possibly moving Debian services to a CDN
On 30/01/14 at 13:53 +0100, Tollef Fog Heen wrote: ]] Tollef Fog Heen Hi all, - the various bits and bobs that are currently hosted on static.debian.org I thought it's time for a small update about this. As of about an hour ago, planet and metadata.ftp-master are now served from the Fastly CDN, and it all seems to be working quite smoothly. We've uncovered some bits we want to make work better, such as adding and removing backend servers automatically when they become unavailable or are added to the static DNS RR, purging content from the caches when it's updated and possibly some other minor bits. This does sadly mean we don't currently have IPv6 for those two services, something that's being worked on by Fastly. As for the privacy concerns raised in the thread, I've had quite a lot of discussions with Fastly about how they operate wrt privacy. They don't store request-related logs (only billing information), so there are no URLs, cookie, client IPs or similar being stored. Varnish has an ephemeral log which they go through a couple of times a minute where some of that information is present, but it never leaves the host (unless we enable logging to an endpoint we control). I'm quite content with how they're handling the privacy concerns. In the interest of full disclosure I should also mention that I'm starting to work for Fastly in a few days time. I don't believe that has influenced my views or judgements here. Hi Tollef, Thanks a lot for this status update. I'm very much in favor of exploring ways to make the Debian infrastructure easier to manage, and using a CDN sounds like a great way to do so. It's great that things worked out with Fastly (any plans for a more public announcement?). However, in [1], I raised one main non-technical concern that is not mentioned in your mail: I fear that, by moving to CDNs without ensuring that there are a sufficient number of CDN providers willing and able to support Debian, we could end up in a lock-in situation with a specific CDN provider (after all, there are not so many of them, and even a smaller number could be able to deal with our technical requirements). [1] https://lists.debian.org/debian-project/2013/10/msg00074.html Of course, as long as we have the infrastructure to go back to the old way of doing things, it is not a big problem. So I'm not worried at the moment. But one of the end goals of using CDN is to reduce the number of Debian PoP (have Debian machines in a fewer number of datacenters, to make them easier to manage). Once we do that, it will be very hard to go back. Have you been trying to reach out to other CDN providers about supporting Debian? I know of discussions with Amazon CloudFront, but I remember some technical blockers? Could the DPL be of some help to you in that process? Cheers. Lucas signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On 07/02/14 at 18:16 +0100, Peter Palfrader wrote: On Sat, 08 Feb 2014, Thomas Goirand wrote: It'd be super nice to have the archive rebuild jobs running on the Debian infrastructure rather than on AWS for example. I agree, and it has been proposed several times over the last few years. To say there was no interest whatsoever would overstate the amount of excitement those suggestions have received. The archive rebuilds are currently running over a very short amount of time ( 8 hours). That's an important feature, because it allows one to rebuild a snapshot of the archive (or a quasi-snapshot, since that could span two dinstalls) and make sure to find all build failures in that snapshot. Unfortunately, to do that, one requires quite a lot of computing power. As a wild guess, I would say 20 to 30 recent servers (I've been using more than 100 EC2 VM for some rebuilds, especially when doing two rebuilds at the same time to compare the rebuilds, e.g. gcc 4.n vs gcc 4.(n+1)). We currently get this computing power for free from Amazon. We used to get it from my employer through a research project (Grid'5000), and we could return to that if needed: the move to Amazon was an attempt at switching from 'only Lucas can work on that' to 'other people can work on that', which was a success given at least David Suarez (general purpose rebuilds + bug filing) and Sylvestre Ledru (clang rebuilds) have been actively running rebuilds over the last year, and I haven't. Also, we made sure of not using anything Amazon-specific in the rebuild infrastructure. Doing those rebuilds on Debian infrastructure would require either: 1) investing in a set of powerful machines to do the rebuilds ($50k as a guess, $2k * 25 -- and that's probably the bare minimum we would need), finding hosting for them, managing them. We get all of that for free from Amazon, so I don't think that this would be good use of Debian's funds. 2) degrading the service: loosen the requirement to rebuild quasi-snapshots of the archive, or use snapshot.debian.org to build a possibly older snapshot of the archive (which would result in filing bugs that were already fixed). None of those options look particularly exciting. That's why I never explored further the idea of running those rebuilds on Debian infrastructure. But maybe you have a nice solution, that you haven't explained yet? One thing we could do, though, is move all the static part of the rebuild infrastructure to Debian infrastructure. That's the virtual machine used to schedule builds on all temporary nodes, and the virtual machine used to store logs. Those logs used to be stored in http://people.d.o/~lucas/, which did not work scale well to several people doing the rebuilds. I approached DSA asking if they would be willing to provide similar archival space in a place accessible by a team including non-DDs. (#debian-admin, 2013-06-03) All of the suggested solutions (mail all build logs as attachments to the bug reports; ask someone else or a cron job to rsync from external host to qa.d.o; push to buildd.d.o) had drawbacks or required additional work that I didn't have time for at the time, so we have just been using an EC2 VM (aws-logs.d.n) to store the logs since then. Probably that should be revisited, but I'm no longer the good point of contact for that (David Suarez is). Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208070510.ga27...@xanadu.blop.info
Re: mailing list auto subscriptions
On 06/02/14 at 01:46 +0100, Francesca Ciceri wrote: On Wed, Feb 05, 2014 at 10:31:17PM +0100, Holger Levsen wrote: Hi, I believe every new DD or DM should be auto subscribed to -devel, -project and -devel-announce (and -private for DDs), best with the usual someone subscribed you for this, please confirm confirmation mail, not sure how to make this reality (as in: how to change DAM procedures), probably by first achieving consenus here?! And then? If the rationale for this is that -devel is a strategic list for Debian contributors, I'd like to point out that for a non uploading DD, -devel is mostly useless. Or at least for the kind of non-uploading work *I* do. +1 I've been trying to use -project rather than -devel for stuff that is relevant to DD without upload rights. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206121217.ga1...@xanadu.blop.info
Re: bits from the DPL -- December 2013
On 22/01/14 at 10:22 +0100, Raphael Hertzog wrote: On Tue, 21 Jan 2014, Lucas Nussbaum wrote: - [bgupta] work with SPI to enable donations via paypal Note that Debian France has planned to setup that for the Debian project. It would be a small change on this page: https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php Instead on the current single option we would have two options: * Donation to Debian France * Donation to the Debian project Assuming of course that we are recognized as a trusted organization. Great! [zack] organize a survey of DDs (N: draft questions) What is this about? This was discussed in http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-09-16.59.log.html (search for 'survey') Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122094117.ga15...@xanadu.blop.info
Re: Debian services and Debian infrastructure
Hi, disclaimer I'm only replying on the main point I'd like to make, so I'm limited my quoting to that. Do not take it as agreement or disagreement on the other points -- I just consider them more minor points. /disclaimer On 21/01/14 at 22:09 +0100, Tollef Fog Heen wrote: The recurring pattern seems to be that, when DSA is approached to move the service to Debian infrastructure, their evaluation of the service's design results in changes requests or constraints that the service maintainers consider too hard to satisfy. I don't think this is an accurate statement. There have been a few cases where people have shown up with a design we were unable to accomodate and progress have stopped, but in general there's been a tremendous forward progress in what's hosted on DSA infrastructure. I don't think it's ever been easier to get new services hosted on DSA infrastructure in the history of the project. Examples over the last six months are voip, tracker, manpages, contributors, and that's without looking at any of the various static vhosts added. No process is perfect, and while we should look at the cases where we've failed to reach a conclusion leaving everybody happy, I think it's just as, or even more important to look at the cases where we do have a happy ending. 3. to provide a place to experiment with new services + create a Debian cloud with virtual machines to develop new services (maybe providing manually-created VMs would be enough -- I'm not sure we need a complex infra such as OpenStack). In general, we're quite happy to create VMs for people when they show up with a service they want to deploy, so I think this is quite well covered. It's great that you are quite happy to create VMs for people when they show up with a service they want to deploy. But that's not what I'm talking about. I'm seeking a solution for people who show up with an *idea* they want to *experiment* with. Because: 1) that's when they should engage with DSA so that you have a chance to review/participate in the design, not months later when an unofficial service is up and running; 2) the alternative is that they give up on the idea, or host it themselves, which makes it harder to work collaboratively on the service, and results in services that have a single maintainer (or none, in the end). A strong requirement for such a solution is that it should be easy to get access to a VM, even if the developers do not have any working code yet, or are not even set on all the implementation details of the services (e.g.; a 10-lines description of what the service is about should probably be enough). Another requirement is that the developers should have root access on the virtual machine, so that it's easy to try various options without DSA intervention (remember: this is about developement/beta testing, not about running the service in a super-stable, production mode). Since we discussed that back in June, you added 'providing an OpenStack cloud' on the DSA radar (it noticed that it was mentioned in the 'just starting' category of DSA meeting minutes). Providing such a solution on Debian hardware would be a great solution to the above problem. Is there something you need from the DPL to make this a reality? Also, a technical question (I'm curious): is there a technical reason why it's not possible to do that inside the current Ganeti setup? Is there something inherently less secure with providing root access to a VM inside a Ganeti cluster, compared to providing root access to a VM inside an OpenStack cloud? I'm asking because I don't expect a huge demand for this (something between 5 and 15 VM per year), so that's still a scale that could manageable using RT tickets + manual creation. Finally, I'd like to re-state that hosting everything (including development VMs) inside the Debian infrastructure is the most desirable solution. However, it seems that it requires manpower and resources that DSA does not really have for now (I would happy to help if possible with the 'resources' side -- I can't do much about the 'manpower' side). That's something we should work on so that ultimately, e.g. 1 or 2 years from now, we reach that point. But I don't think that we should wait 1 or 2 years to solve that general problem. That's why I'm exploring a compromise and temporary solution, which is using resources from public clouds. I will be very happy to drop that solution as soon as we have a DSA-provided one. Lucas signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
Hi, On 21/01/14 at 13:11 +, Stephen Gran wrote: This one time, at band camp, Lucas Nussbaum said: [...] single mail shot with no follow up. Well, it's been a bit over 2 weeks, and you haven't posted a follow up. This doesn't feel like a conversation to me. I understand you're busy, but it feels very much like you're not actually interested in engaging. I find that slightly demoralizing. I'm not sure of what you would like me to follow up on? I've just re-checked, and emails from you in that thread did not include a single question. Generally, I agree with everything that has been said in that thread (minor snarky comments from Joerg on m68k and 'real unrealistic requirements', but I didn't think it was worth replying to them). For example, I fully agree that we should try hard to host 'important' services on Debian hardware. Also, I don't think that anybody disagrees that we have a problem with 'speculative' services (as you put it, or 'services development' as I put it). DSA cannot and should not provide hosting for all Debian-related services being developed, as you wrote yourself: I don't think jumping straight to a solution that puts all of the responsibility for every idea for a service in Debian on DSA shoulders is either the only way to go or even a good way to go. There are plenty of bad ideas that should be allowed to wither on the vine, and there are always going to be services that have been designed in such a way as to be difficult to integrate into DSA-managed infrastructure. We are, after all, a reasonably small team of volunteers. Pretending that we can support an infinite number of services or an infinite variety of designs is just going to end in disappointment for someone. Now, of course, I'm very disappointed that nobody from DSA is interested in acting as a gateway between service developers and hosting solutions outside of Debian infrastructure that would be suitable for services in development and experimental/maturing services. In my eyes, that would have been a win-win situation, by putting DSA in the perfect position to be aware of emerging services, and to interact early with service maintainers. But, well, I cannot force anyone to do work that they don't want to do. However, it sounded pointless to argue on that if there is no concrete offer to host Debian's services being developed outside of Debian infrastructure. So, since that discussion, I've been talking to a few hosting providers, and two of them have offered to support Debian with free resources (on their clouds) for Debian development. Since I think that avoiding vendor lock-in is a must, I'd like to make sure that we can get a third one on board before working out further details. That will include deciding how allocation of such resources happen, and where discussion about this should happen. My first choice would be to use debian-services-admin@ for that, but of course that will be your decision as I don't want to 'pollute' the list with traffic you are not interested in. - Lucas signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On 21/01/14 at 15:07 +, Stephen Gran wrote: I think there's quite a range of options between DSA can't host everything under the sun and I'll go set up a private parallel development environment out of project funds without any further discussion. I don't know who you are quoting here, but I never said that I would go set up a private parallel development environment out of project funds. What I'm doing currently is what I wrote in the mail you replied to: However, it sounded pointless to argue on that if there is no concrete offer to host Debian's services being developed outside of Debian infrastructure. So, since that discussion, I've been talking to a few hosting providers, and two of them have offered to support Debian with free resources (on their clouds) for Debian development. Since I think that avoiding vendor lock-in is a must, I'd like to make sure that we can get a third one on board before working out further details. That is, *explore the possiblity* to get *free* resources for Debian development. Now, of course, I'm very disappointed that nobody from DSA is interested in acting as a gateway between service developers and hosting solutions outside of Debian infrastructure that would be suitable for services in development and experimental/maturing services. In my eyes, that would have been a win-win situation, by putting DSA in the perfect position to be aware of emerging services, and to interact early with service maintainers. But, well, I cannot force anyone to do work that they don't want to do. So, I offered at one point to set up an openstack private cloud for DDs to use for service development and so on. I got almost as enthusiastic a response to that as we got to kerberos, AFS, and now MQ. I decided to let it go instead of putting lots of energy into something that no one would use. That sort of thing can be revisited if it's actually interesting for people. FTR, I agree that the demand will not be huge for that. Probably in the order of 4-8 services hosting requests per year. However, I disagree that no one would use that. I know of at least two services using VMs on EC2 for service development currently. If we can avoid spending DSA's time on a private OpenStack Cloud by getting free resources, and solve the problem of providing a development infrastructure that way, I really think that this is the way to go. I'm not sure what you picture when you talk about us acting as a gateway. Perhaps you could elaborate on that. I'm not keen on playing script monkey to set up machines for people - I'd much rather that interested people be able to do that for themselves. If you just want us to be a point of contact for people developing new services, I think we've said several times that we'd like to be just that. I think that the tasks involved would be something such as: - Work with hosting providers so that we have some diversity in the offerings, and avoid vendor lock-in. - Understand the offerings (what's available? possible?) - Document the various offerings (wiki page) - Understand what prospective service maintainers are asking for, in terms of resources. Maybe provide advice on design. - Do the matching between what service maintainers need and the hosting providers - Maybe provide some support to service maintainers (e.g. for dealing with the specifics of each hosting provider) - Maybe make it possible to install DSA-flavored VMs on the various Clouds, using the resources pointed to in [1]. [1] http://lists.debian.org/20140109083128.ga12...@varinia.lobefin.net There's nothing here that *needs* to be done by DSA, but it would certainly be very helpful to have DSA members involved. However, it sounded pointless to argue on that if there is no concrete offer to host Debian's services being developed outside of Debian infrastructure. So, since that discussion, I've been talking to a few hosting providers, and two of them have offered to support Debian with free resources (on their clouds) for Debian development. Since I think that avoiding vendor lock-in is a must, I'd like to make sure that we can get a third one on board before working out further details. That will include deciding how allocation of such resources happen, and where discussion about this should happen. My first choice would be to use debian-services-admin@ for that, but of course that will be your decision as I don't want to 'pollute' the list with traffic you are not interested in. No, that's precisely the sort of thing the list is for, I thought - it's not a private list for DSA or anything. Not sure where the word pollute or its scare quotes have come from, but it sure feels hostile. I'll assume you don't mean it that way. Well, if DSA has nothing to do with this development infrastructure they don't host, it could have made sense to have a separate list for that, just to keep the signal/noise ratio high
Re: Debian services and Debian infrastructure
On 21/01/14 at 15:47 +, Luca Filipozzi wrote: And I actively engaged other DDs regarding their VPS opportunities (although no response so far in some cases). Oh, that's great! I've just sent you a private mail to share my contacts. I really had no idea that you intended to work on that, given that when we discussed related topics in June and again in December, you showed little interest in exploring such setups. It would have avoided some duplicate work if you mentioned it when I talked about it in [1]: | As you know, Amazon provides Debian with free credits on the | AWS Cloud. Those credits are normally used for archive rebuilds, but | have already been used by a GSOC project (PTS rewrite), and more | recently, to start work on an archive-wide autopkgtest setup. A few more | virtual machines could be accomodated, and I will investigate if we | could extend that even more. Also, codesearch.d.n is hosted on | Rackspace's Cloud[1]. I will also follow up on that. [1] https://lists.debian.org/debian-project/2014/01/msg00010.html Lucas signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On 21/01/14 at 17:23 +0100, Tollef Fog Heen wrote: I have some operational questions about this cloud setup, since it seems you've delegated running Debian owned machines to us and then gone and got some that you don't want us to run. I'm not sure what to do with that disjuncture. I don't know what you are talking about. Where did I got some Debian owned machines that I don't want DSA to run? Those VMs are machines. They're not owned by the individual developers (quite obviously), so they're owned by Debian. The DSA delegation you sent less than two weeks ago include: - Setting up and administering Debian-owned machines, ensuring that they are kept secure, operational, and running. so it's quite clear to me at least than any VMs owned by Debian falls under that umbrella. Separately, given how upset you got after having a request to add a member to the DSA team Cc-ed to debian-project I think you're completely out of bounds when you're informing DSA (and others) that you're working on setting up parallel infrastructure by mailing debian-devel-announce. Given that, in [3], I wrote: | As you know, Amazon provides Debian with free credits on the | AWS Cloud. Those credits are normally used for archive rebuilds, but | have already been used by a GSOC project (PTS rewrite), and more | recently, to start work on an archive-wide autopkgtest setup. A few more | virtual machines could be accomodated, and I will investigate if we | could extend that even more. Also, codesearch.d.n is hosted on | Rackspace's Cloud[1]. I will also follow up on that. I think that I informed the project that I would explore opportunities to host services in development using free resources provided by public clouds. So, we can bikeshed for a long time over whether free credits on public Clouds are machines that must be managed by DSA. And we should probably throw in the discussion the AWS credits donated to Debian (see [1]) -- however I'm surprised that this comes up now when we have had such credits since 2011[2]. Or, we could try to get constructive, and get things done. I had never planned to keep the management of this in DPL-dom, and even asked DSA in [3] if you would like to manage those resources. My second-choice would have been to build a small team to do the tasks listed in [4]. But if DSA would like to do those tasks, I'm super-happy to hand them over to you. My question from [3] on whether you would like to be in charge of that still stands, and I was planning to get back to you about it once I had clarified if it was possible to get such a scheme set up with Cloud providers. So, just let me know. [1] https://lists.debian.org/debian-devel-announce/2013/12/msg3.html [2] https://lists.debian.org/debian-qa/2011/11/msg1.html [3] https://lists.debian.org/debian-project/2014/01/msg00010.html [4] https://lists.debian.org/debian-project/2014/01/msg00089.html Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140121171426.ga26...@xanadu.blop.info
Re: Please give a summary (Was: Debian services and Debian infrastructure)
Hi Andreas, On 21/01/14 at 17:51 +0100, Andreas Tille wrote: Hi, as a random reader I have the feeling that this thread is about a conflict between DSA members and DPL. For me all these mails do not make the slightest sense and it would help if someone could give a summary what you are talking about and if possible give some example what you think is OK and what not. In https://lists.debian.org/debian-project/2014/01/msg00010.html (2014-01-04), I said that I would contact Cloud providers to see if it would be possible to get free credits for Debian development. I also asked DSA if they would like to be involved in the management of such resources. Stephen Gran replied (partially on behalf of DSA, but that part was personal) that he wouldn't be willing to be involved, in https://lists.debian.org/debian-project/2014/01/msg00018.html. Nobody else from DSA replied to that question. I moved forward with contacting Cloud providers, and got two positive contacts, which I reported about in https://lists.debian.org/debian-devel-announce/2014/01/msg5.html. That seems to have prompted today's follow-up discussion. DSA expressed several concerns today, which I will try to summarize: - I did not participate in the discussion after the initial mail on 2014-01-04. - I was in agreement with most of what was written, so I did not feel the need to follow-up. - I should not have contacted Cloud providers without informing them beforehand. - from my POV I informed them on 2014-01-04. They did not state back then that they wanted to be Cced. - Those credits would be Debian machines, so they have to be managed by DSA. - I asked them if they wanted to manage them, and was planning to ask again. So, from my POV, the current state is described in https://lists.debian.org/debian-project/2014/01/msg00096.html: | I had never planned to keep the management of this in DPL-dom, and even asked | DSA in [3] if you would like to manage those resources. My second-choice would | have been to build a small team to do the tasks listed in [4]. But if DSA would | like to do those tasks, I'm super-happy to hand them over to you. My question | from [3] on whether you would like to be in charge of that still stands, and I | was planning to get back to you about it once I had clarified if it was | possible to get such a scheme set up with Cloud providers. So, just let me | know. | [1] https://lists.debian.org/debian-devel-announce/2013/12/msg3.html | [2] https://lists.debian.org/debian-qa/2011/11/msg1.html | [3] https://lists.debian.org/debian-project/2014/01/msg00010.html | [4] https://lists.debian.org/debian-project/2014/01/msg00089.html Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140121180935.ga27...@xanadu.blop.info
Re: Please give a summary (Was: Debian services and Debian infrastructure)
Hi Ian, On 21/01/14 at 18:11 +, Ian Jackson wrote: Lucas seems to be intending to mediate these offers to interested DDs (who have Debian-related uses for a VM) directly, with the apparent expectation that those DDs would end up administering those VMs directly in an ad hoc manner. DSA haven't been involved or informed (until now). That's not accurate, sorry. I mentioned that I was planning to do that in https://lists.debian.org/debian-project/2014/01/msg00010.html . In the same mail, I asked DSA if they would be willing to manage those resources. I can see at least three problems with this, which have been mentioned in this and previous threads: Firstly, there is the prospect that bad things would happen to these VMs. For example, they might get compromised; or access to them could be lost when the invididual DDs who had been running them leave or go on vacation. This would be bad for the project, and of course it's bad for DSA because in such a situation DSA would be asked about these VMs and expected to fix it but have no access to or knowledge about them. Secondly, there is the risk that there would be no coherent way to retire these VMs when they are no longer needed. When we take on ongoing donated resources like that, there should be a mechanism for ensuring that the project knows about them, can periodically check that they're still being used and needed, etc. Sure, it's important that the project's resources, whatever they are, are properly tracked and managed. Thirdly, it increases the risk of services being developed in a way that would make them hard to deploy on DSA-managed infrastructure. Developers of services would benefit from early contact with DSA to understand at least in general terms how to make a readily deployable and maintainable online service. Interesting. How does it *increase* the risk of services being developed in a way that would make them hard to deploy on DSA-managed infrastructure? The current status is that people host their services on their own hardware. I don't see how moving services to VMs would make things worse. On the contrary, if done properly, this provides a chance to monitor which services are being developed, review designs, etc. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140121202401.ga...@xanadu.blop.info
Evaluation criterias for (prospective) Trusted Organizations
TL;DR: let's try to implement Constitution 5.1.11 and 9.3: discuss status of prospective TOs, accept them, have an official list of them. Hi, Our Constitution says: (5.1.11) The project leader may: Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations. (9) 9. Assets held in trust for Debian In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2. Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there. SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. (9.3) 9.3. Trusted organisations Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project. Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets. Debian maintains a public List of Trusted Organisations that accept donations and hold assets in trust for Debian (including both tangible property and intellectual property) that includes the commitments those organisations have made as to how those assets will be handled. So far, we never really implemented those requirements, and the situation is a bit blurry: - SPI is a clearly a TO - FFIS is de-facto a TO (I don't think that anybody is going to argue on that), even if we have not had a public discussion about it - debian.ch holds Debian funds, even if we have not had a public discussion about it. Whether it should be considered a TO or not is not clear at all - Debian France is aiming at becoming a TO, and is currently updating its bylaws towards that. It already holds some funds for the Debian project. With auditors and DPL helpers, we worked on a list of evaluation criterias for prospective Trusted Organizations[1]. [1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria (also copied below for convenience) The expected next steps are: 1. We review and improve the TO Evaluation Criterias [this mail/thread] 2. I ask each organization to describe how they meet (or not) the criterias. 3. We have the two-week public discussion about each organization 4. I officialize the status of each organization In the end, I am 99% sure that all of SPI, FFIS, debian.ch and Debian France will be official TOs. However, this work is also a way to review their status, and better understand some limits, weaknesses, threats, opportunities, etc. So, first things first, I would welcome your feedback on the TO criterias[1]. Soft deadline: 2014-02-01. [1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria Also, I'm inclined to waive the discussion for both SPI and FFIS, and just officialize their status, given they have been around for a very long time and served us very well of that time. If you disagree, please say so. Thanks! Lucas --- local copy of wiki.d.o/Teams/DPL/TrustedOrganizationCriteria ---8 Debian Trusted Organizations (TO) are organizations that hold and manage assets on behalf of the Debian project. The list of TOs is maintained by the Debian Project Leader (following [[http://www.debian.org/devel/constitution|Debian Constitution]] 5.1.11 and 9). In order to be accepted as a TO, an organization should provide some features, and satisfy some criterias. The list below should not be understood as required features, but rather as a set of desirable features. A prospective TO is expected to describe how it compares to this set of desirable features. == The organization should share Debian's general visions == The organization's activities and political stance should generally match Debian's own political and philosophical stances. == The organization should remain loyal to Debian == The organization should be considered fully trustworthy, or provide guarantees that Debian's assets will be managed according to the Debian Project's decisions. Some examples of possible implementations: * The organization has a long history of successfully holding a similar role for other Free Software projects * The organization is managed by highly respected members of the Free Software community * The organization has a leadership structure
Re: Evaluation criterias for (prospective) Trusted Organizations
On 17/01/14 at 11:13 +0100, Lucas Nussbaum wrote: With auditors and DPL helpers, we worked on a list of evaluation criterias for prospective Trusted Organizations[1]. ^ (and now, I remember that 'criteria' is plural. Please s/criterias/criteria/ everywhere ...) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117102048.ga31...@xanadu.blop.info
Re: Evaluation criterias for (prospective) Trusted Organizations
On 17/01/14 at 12:47 +0100, Raphael Hertzog wrote: Hi, On Fri, 17 Jan 2014, Lucas Nussbaum wrote: So, first things first, I would welcome your feedback on the TO criterias[1]. Soft deadline: 2014-02-01. [1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria I didn't find anything really problematic in the criteria, at least not wrt Debian France. Let me still add some comments. == The organization should share Debian's general visions == The organization's activities and political stance should generally match Debian's own political and philosophical stances. activities might be a bit broad. TO might have (Debian-related) activities that Debian is (purposedly) not doing, and this should not be a blocker IMO. IMO we should simply tell that the TO bylaws, activities and political stance should not be in conflict with Debian's social contract. OK, not conflict is indeed a better wording. [ Your other comments are specific to Debian France -- let's not address them now, but rather when we will discuss Debian France ] Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117155306.gb7...@xanadu.blop.info
Re: Updating the Policy Editors delegation
.oO ( funny that this comes up now, given the same delegation text was already used in https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and https://lists.debian.org/debian-devel-announce/2013/06/msg4.html) On 06/01/14 at 13:51 +, Neil McGovern wrote: On Fri, Jan 03, 2014 at 05:58:19PM +, Ian Jackson wrote: Furthermore, I don't think this delegation declaration is constitutionally appropriate. The policy editors are, primarily, maintainers of a package. Indeed, there's potentially an issue here that the constitution states (8.3) Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. By defining a process within a delegation, this removes this option, which a delegation cannot do. The processes for how to maintain a package, and ordinary maintainership succession, would seem to fall squarely within the current maintainers' own discretion. Jurisdiction to adjudicate package maintainership disputes, and oversight of the decisions of the policy editors, are explicitly granted to the Technical Committee. So it seems to me, at the moment, that this delegation is ultra vires and hence not binding on the policy maintainers. Indeed, though please note that this isn't an official interpretation of the consitution. If you want that, please mail secretary@ :) Doing that now. :-) Also, I'm more worried with the interactions with Constitution 6.1.1. It seems to me that a Policy Editors delegation should have come from the TC, not the DPL. Dear Secretary, what do you think? Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106143846.ga23...@xanadu.blop.info
Re: Please update the DSA delegation
Hi, On 04/01/14 at 14:04 +0100, Andreas Barth wrote: Hi Lucas, * Martin Zobel-Helas (zo...@debian.org) [131202 22:11]: Hi Lucas, I am pleased to announce that DSA has promoted Héctor Orón Martínez to a full member of the team. Please update the delegation for the Debian System Administrators accordingly. Did I miss the conclusion on this? Is Héctor Orón Martínez now part of the delegated DSA team? Or do you have reasons to not make him a normal DSA member? Or do you think that the delegation is auto-updated? See https://lists.debian.org/debian-project/2013/12/msg00049.html Yes, I'm late with that. So, I've just updated the delegation to include Hector, without trying to improve the task description. Expect another mail from me later this week-end about the issues mentioned in https://lists.debian.org/debian-project/2013/12/msg00033.html (Actually I think we should have our delegations so that if the current delegates add someone new, inform the DPL and -project and don't receive a veto within 6 weeks, the new person is automatically delegated as well - but I don't think our constitution nor the current delegations are explicitly allowing that, and so I would prefer an official update.) I disagree with that, as stated in e.g. https://lists.debian.org/debian-project/2013/12/msg00032.html and https://lists.debian.org/debian-project/2013/12/msg00036.html . But that does not mean that you should not try to change the constitution to add this process. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014010418.ga...@xanadu.blop.info
Debian services and Debian infrastructure
Hi, As previously mentioned[1], I've been talking with DSA about the state of Debian services on Debian infrastructure. DSA asked me to move the discussion to a public list, which is what I'm doing here. What follows is my current state of mind on this question. I'm open to changing my mind based on the project's feedback. [1] https://lists.debian.org/debian-project/2013/12/msg00015.html The underlying questions that I'd like to answer are: Q1. How much should we push for Debian services (services useful to Debian) to be hosted on Debian infrastructure? Q2. Should we seek other hosting opportunities to ease Debian services development and hosting? Should I authorize the use of Debian money to fund infrastructure not managed by DSA, in the case of a useful service that DSA has been unable to accept in the infrastructure it manages? Q3. What should be our definition of official services? Background == First, it's important to state that DSA has been doing a fantastic job on maintaining our core infrastructure for the last few years. The level of quality and professionnalism of their work clearly surpasses what can be found in most organizations, volunteer or not. However, there has been several episodes, involving the development of new services or their move to Debian infrastructure, that generated a lot of frustration and demotivation on both sides (DSA and service developers). As examples, one can think of codesearch, or the fedmsg GSOC project. There are also services that have been developed outside of Debian's infrastructure, with AFAIK no plans to move them to Debian infrastructure. The recurring pattern seems to be that, when DSA is approached to move the service to Debian infrastructure, their evaluation of the service's design results in changes requests or constraints that the service maintainers consider too hard to satisfy. I'm worried that this situation is harmful for the project. Similarly to how we increased the amount of collaborative packages maintainance over the years, we should improve on collaborative service maintainance, and we should move away from the myriad of unofficial services maintained by a sole DD, and hosted on this DD's personal machine. The obvious way to do that would be to facilitate the hosting of emerging services on Debian infrastructure, and I think that we should all work together to identify what could be done towards that. I've given some thought to this myself, and came up with the following ideas. Some of them are probably really bad ideas, but let's try to brainstorm a bit: 1. to improve communication between DSA and service maintainers + have an archived, public list where (prospective) service maintainers can engage with DSA about stuff they are planning/thinking about. (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?) + have DSA provide collective answers more often, rather than a set of individual answers. It's often not clear if something is a final decision, or the opinion of a DSA member. + redirect some discussions from IRC to a mailing list, esp. when things look like policy decisions (on service design, etc) 2. to improve the tracking of services + request wiki pages from maintainers that detail who are the contact points, what the service does, what are its requirements. State a service level agreement (informative of expectations, not punitive, of course) + have service maintainers create similar pages for services in development, to provide some kind of incubation process during which DSA can provide feedback. 3. to provide a place to experiment with new services + create a Debian cloud with virtual machines to develop new services (maybe providing manually-created VMs would be enough -- I'm not sure we need a complex infra such as OpenStack). Additionally, one suggestion from DSA is to involve them as earlier as possible in the design process. I'm now trying to answer my own questions: Q1. How much should we push for Debian services (services useful to Debian) to be hosted on Debian infrastructure? Fragmentation in terms of hosting is harmful, and we should all try to get our services hosted on Debian infrastructure, because that's the easiest way to ensure that the maintainance of such services can be shared or transferred between developers. Now, for some services, it seems that doing this has become so hard that it harmed the service itself, and badly demotivated the service maintainers. I don't think that we should allow that to happen. We should stay open to other hosting solutions, when this is necessary. Q2. Should we seek other hosting opportunities to ease Debian services development and hosting? Should I authorize the use of Debian money to fund infrastructure not managed by DSA, in the case of a useful service that DSA has been unable to accept in the infrastructure it
Re: Buying hardware with Debian money
Hi Mason, Sorry for the delayed answer. On 16/12/13 at 22:33 -0500, Mason Loring Bliss wrote: On Sun, Oct 20, 2013, Lucas Nussbaum lea...@debian.org wrote: I received a few requests for hardware purchases, that I think are worth discussing with the project as a whole in order to progress towards having clear guidelines for what is acceptable and what isn't in terms of spending Debian money. Please provide feedback on the proposed decisions -- they are not final yet. Hello, and apologies for being so late in responding. I only noted this discussion after a DPL report, and it's taken me some time to subscribe and reply. Thanks for your feedback, even if the decisions are final now. Those decisions were hard to make, and I don't think that we can draw general rules from them yet. Some comments inlined below. I'd like to generally note that I'm not in favour of buying hardware for individual developers. Hardware for Debian infrastructure is obviously distinct from this, and I'd suggest that even hardware purchased for a particular role and maintained within the Debian infrastructure would be reasonable. Right Going down the list: A. Memory expansion cards for m68k buildds (expected cost: 500 EUR) Infrastructure investment - reasonable. B. Powerful machine for d-i development (expected cost: 1.5k-2k EUR?) Unreasonable. The developer should be using his own hardware. If the Project is to supply hardware, it should live within the Project's infrastructure. The developer is specifically noting that the machine will be running virtual guests for the actual development work, and as such I can't imagine why this cannot live inside the Debian infrastructure, thus making it more available to the community as a resource when this develop doesn't need it for active work. The developer argues against a remote machine, saying, I do realize having some nice hardware racked up in some datacenter would be nice for testing purposes, but until automated regression testing is implemented, one needs to rely on clicking and typing into a VM, so as to debug/develop some framework to perform automated testing. This can readily be accomplished with VNC. The developer also notes that prepairing an upload requires a local machine, which, again, suggests that a machine managed within the Debian infrastructure doesn't present the requisite level of trust... This request simply bothers me. It is, I believe, too much to ask of the Project. Some points that contributed to making this decision are: - debian-installer is a central part of Debian, where we have historically had problems attracting contributors (despite trying) - the developer in question is the main contributor to d-i, and has been for some time - developing debian-installer efficiently requires fast hardware, faster than what can be found in a medium-range laptop - testing debian-installer often requires running the installer interactively. This could be done over VNC, but this is really far from being comfortable. Typically, you want to be able skip very fast to the point that you are working on (without reading all the questions :-) ), and latency and low bandwidth makes this very hard. - the machine would be only used for Debian work (my original mail said primarly -- the developer clarified in private) - if the developer were to stop his involvement in d-i, the machine could be returned to the project So, I really saw this purchase as purchasing Debian infrastructure hosted at a Developer's rather than in a datacenter. C. Laptop for developer (expected cost: 1k-1.5k EUR?) Again, individual developers should supply their own hardware. (that request was not approved in the end) My perspective: I donate a small sum to SPI, earmarked expressly for Debian, monthly. I imagine there are many other people who do the same thing. Seeing these requests for gifts from the Project makes me mentally add up how many months of my contributions are going to satisfy a developer's desire for something that he'd really ought to be providing for himself. I believe in the election process and I have no illusion that I'm in a position to try to micro-manage how the Project uses its available resources, but it really won't take seeing this sort of thing more than once or twice before I redirect this particular portion of my charitable giving elsewhere. I would personally be far too embarassed to ask a non-profit group to which I volunteered development time to give me equipment for the purpose, rather than simply asking for the use of Project-managed resources if my own resources seemed somehow insufficient. I agree with you that using the project's resources to provide gifts to developer is not acceptable. On the other hand, many Debian contributors make life choices that result, for example, in jobs where they can spend time on Debian during work hours, in exchange of a lower
Re: DPL helpers meeting today (2013-12-16)
On 16/12/13 at 08:28 +0100, Lucas Nussbaum wrote: Hi, We will have a DPL helpers meeting today at 18:00 UTC, on #debian-dpl. Hi, The meeting was cancelled due to the lack of participants. I'll organize a poll to schedule the next meeting (next year). Cheers Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216193236.ga20...@xanadu.blop.info
DPL helpers meeting today (2013-12-16)
Hi, We will have a DPL helpers meeting today at 18:00 UTC, on #debian-dpl. Titanpad with agenda: http://titanpad.com/debiandpl-20131216 (Please update the status of your action items before the meeting if possible) Lucas -- copy of the agenda below -8 #+TITLE: DPL helpers - working agenda #+DATE: [2013-12-16] * roll call * next meeting proposal: 2014-01-08, 18:00 UTC ? * Current DPL TO-DO list + backlog status See live version at http://people.debian.org/~lucas/todo.txt * New topics * Action items from last meeting (please update status and mention if discussion is needed. if not, we will just skip it during the meeting) ** DONE rafw follow status of anti-harassment bug (#728492). N: ask english l10n for review bug fixed! ** DONE lucas follow-up on the events team discussion + the list of members on organization.en.html was updated + there's a Debian event box, currently at Sylvestre Ledru's + open question: content of Debian event box. asked to list it somewhere. ** INPROGRESS lucas follow-up on TO definition discussion https://wiki.debian.org/DraftDefinitionTrustedOrganizationsDiscussion sent new version, collecting feedback ** TODO bgupta write a proposal for handling of debian.* domain names ** TODO bgupta Work with SPI to get a Debian controlled Paypal account ** TODO bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 ** TODO bgupta Investigate accepting crypto-currency donations (With SFLC help) ** TODO bgupta deal with http://debian.ch/opw2013/ (Perhaps point to main debian donations page) ** TODO bgupta look to update text on http://www.debian.org/devel/leader regarding property, to reflect multiple Trusted Orgs ** TODO RichiH to add Debian logins to http://www.debian.org/intro/organization ** TODO zack to draft questions for a survey of DDs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216072833.ga17...@xanadu.blop.info
Re: Please update the DSA delegation
On 05/12/13 at 09:35 +0100, Thijs Kinkhorst wrote: On Thu, December 5, 2013 02:15, Ian Jackson wrote: I would go further and say that I think it would be better to do things differently. For a team which is functioning well, it would be helpful if the DPL delegated to the team the authority over its own composition, explicitly reserving the right to intervene. That way there is no procedural problem: there is no question of someone de facto making decisions which de jure they are not empowered to make, or alternatively of having to have people wait for a rubber stamp from the DPL before getting on with useful work. Perhaps it would make sense to first more clearly define problems we want to solve with the whole delegation process, so we then know what kind of process would best address that. I see that currently the process costs the DPL quite some time while at least to me it's unclear what problem it solves for the project. Can we point to a concrete issue in the past few years that we were able to address more efficiently because delegations were in place? Hi, This was discussed in https://lists.debian.org/debian-project/2013/05/msg00018.html. Main points are: * it facilitates the monitoring of the team manpower, which helps taking proactive actions before things get too difficult. * it provides a place to clearly define what are the roles, responsibilities, powers of the team. * it's a rather lightweight process when things work well. It's bureaucratic, yes, but not so expensive bureaucracy. There are a number some teams active that perform tasks essential to Debian but are not delegated. Do we see more problems with those teams than with the delegated ones? Which ones are you thinking about? (the release team is not delegated yet, though this is a long running pending task, and there's a draft already). Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131205104623.ga28...@xanadu.blop.info
Re: Please update the DSA delegation
On 05/12/13 at 10:53 +0100, Martin Zobel-Helas wrote: Hi, On Wed Dec 04, 2013 at 17:45:22 +0100, Lucas Nussbaum wrote: 3) I was a bit surprised to see Martin's announcement that Hector was now a member of DSA, and his request to update the DSA delegation. I don't understand that. Hector has been doing a good amount of work as part of the DSA team. After he has been a trainee for half a year, I spoke with the other members (yes, that was done privatly, i need to admit) if they also think that he should become a full member. I waited until I heared back from all other members. The usual process is that the appointement of delegates is usually discussed between the DPL and the team. Of course, for well-functioning teams that propose a new delegate who already went through a training process, that discussion is rather likely to be short. But that's not a valid reason to suppress it completely and make it sound like a public demand that the DPL does the required paperwork (I'm sure that it was not Martin's intent, but it's still worth clarifying, I think). My intent was to be as open as possible in the decission we have taken. As Joerg wrote, I think uncontroversial changes to functional teams have never been a problem for an update of a DPL delegation. Is the DSA team a non-functional team? I wouldn't say that. I think that the general opinion inside the project is that it's functioning quite well, well, or very well, depending on who you ask. However, there has recently been a number of events where there seem to have been communication problems between DSA and the rest of project (service developers not engaging with DSA early during the design process; service developers engaging with DSA late, and then having difficult conversations; failed contact between service maintainers and DSA about service moves, ...). And as a result, several people gave up on hosting services they maintain inside Debian infrastructure. I think that it's important for Debian to provide an environment for experimenting ideas on infrastructure, designing new services, etc. Ideally, I think that this should happen on Debian infrastructure managed by DSA, because (1) it facilitates collaborative service maintenance; (2) it's better when people focus on what they are doing best, and we don't have a infinite supply of expert sysadmins. So I'm trying to see if something can be done to improve the current status. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131205104522.ga28...@xanadu.blop.info
Re: Please update the DSA delegation
On 05/12/13 at 13:46 +0100, Thijs Kinkhorst wrote: On Thu, December 5, 2013 11:46, Lucas Nussbaum wrote: This was discussed in https://lists.debian.org/debian-project/2013/05/msg00018.html. Main points are: * it facilitates the monitoring of the team manpower, which helps taking proactive actions before things get too difficult. * it provides a place to clearly define what are the roles, responsibilities, powers of the team. * it's a rather lightweight process when things work well. It's bureaucratic, yes, but not so expensive bureaucracy. These arguments are all inherently bureaucratic in nature (monitoring, defining responsibilities). That's not bad per se, if it can be justified that this form of monitoring or formal responsibility determination actually solved concrete issues. Since you skipped my request for concrete examples, I'm assuming you also haven't seen such cases :) I don't think that delegations solve any problem per se. They are a tool that facilitate the monitoring of key teams in the project. Obviously, from the DPL POV, the goal should not be to focus on the bureaucracy side, but rather on having well-functioning key teams. I am convinced that delegations help with making sure that teams stay functional, and I'd assume that Stefano agrees given the amount of work he put during his three terms into clarifying the roles of teams, and delegating additional teams. I'm not convinced that the work done on all these delegations is a net win. I am. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131205132105.ga3...@xanadu.blop.info
Re: Please update the DSA delegation
On 05/12/13 at 14:26 +, Ian Jackson wrote: Lucas Nussbaum writes (Re: Please update the DSA delegation): On 05/12/13 at 09:35 +0100, Thijs Kinkhorst wrote: Perhaps it would make sense to first more clearly define problems we want to solve with the whole delegation process, [...] ... This was discussed in https://lists.debian.org/debian-project/2013/05/msg00018.html. Lucas, I'm concerned that you apparently have time to debate the merits of our approach to delegates, but unless I'm mistaken you haven't found time to simply say yes to Hector's promotion to a full member of the DSA team. Is there some reason (besides lack of DPL team attention, and besides some wider questions about what exactly the delegation should consist of) why Hector should not be appointed immediately ? If there is such a reason please say that you are considering the merits of the appointment. Otherwise please would you confirm it immediately. At this point, I don't see any reason why I wouldn't eventually delegate Hector, in an update of the DSA delegation. On 05/12/13 at 15:53 +0100, Gerfried Fuchs wrote: Maybe I get you wrong - and maybe you got Lucas wrong - but are you implying that Hector is a controversial nomination? Where did I miss that part? From what I read in Lucas initial response to Martin, it was about general communication issues with the (current) DSA team (wheter or not that might be true), not with Hector specificly. The way you phrase it makes it rather sound that Hector is a controversial nomination? At this point, I have no reason to believe that it's controversial. Now, please, can I go back to work? (I'm ignoring the questioning on my use of my time, and the comment on the lack of DPL team attention) Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131205162710.ga7...@xanadu.blop.info
Re: Please update the DSA delegation
Hi Martin, On 05/12/13 at 23:03 +0100, Martin Zobel-Helas wrote: Hi Lucas, Hi Lucas, I am pleased to announce that DSA has promoted Héctor Orón Martínez to a full member of the team. I think that this mail must have been misinterpreted. It was not meant to be a demand. I was happy to share that we had recruited zumbi. He's been working with us in one form or another for over three years now and is very experienced with porter workflow and helped a lot recently within the arm community. Within the last year he has shared more and more of our duties and my colleagues and I thought it high time that he not only be part of the team, but that he also be recognized by the project as such. My colleagues and I are very excited to have him onboard. Please rest assured that no offense was intended. Thank you for this clarification. As said in other emails, I'm sligthly backlogged due to some travel and am travelling again next week, and I would prefer to factor in this update the outcome of the current discussion with DSA. But I will get to delegating Hector soon (very likely before the end of 2013). Lucas signature.asc Description: Digital signature
Re: Please update the DSA delegation
On 04/12/13 at 14:58 +0100, Joerg Jaspert wrote: Hi I am pleased to announce that DSA has promoted Héctor Orón Martínez to a full member of the team. Please update the delegation for the Debian System Administrators accordingly. I'd rather wait until we see where our current (private) conversation is going, as the job description could be updated/clarified as a result. There are two ways to interpret this. One is that one simple wants to avoid a mostly doubled mail to d-d-a, now delegating Hector, when there is going to be a change to the role of DSA upcoming anyways. Which may be the case if the role of DSA changed since the last delegation, to have the delegation reflect reality. The other is that Hector is used as a way to pressure DSA into accepting a role change they may otherwise not accept or have given reasons why it is wrong to do so. Now, I have no idea how that private discussion looks like, so I can only base my observation on what I see of DSAs works and the old delegation text. Which doesn't look like the role really changed? May I ask what I miss? Over the last months, I was contacted by DDs about several issues involving DSA (which doesn't mean they are fault). I initiated a discussion with DSA to try to understand how we could improve things (at this point, my limited understanding is that it's mainly communication problems). The discussion is ongoing. A delegation is a good opportunity to clarify interactions between a team and the rest of the project, so I'd rather factor this in, if relevant. Three other comments: 1) As I explained on -private@ a few weeks ago, I'm slightly backlogged, and I'm not sure why you think that this delegation should be prioritized compared to other pending tasks, especially given that it's not blocking Hector's work (according to LDAP, DSA did not wait for the delegation to give Hector effective DSA powers -- I suppose that he already was a member of the adm group during his time as a DSA trainee). 2) As said numerous times, I would love to get more help with other DPL-related tasks, so that I would be able to update delegations in less than 48 hours. The next DPL helpers meeting is on 2013-12-16 at 18:00 UTC. 3) I was a bit surprised to see Martin's announcement that Hector was now a member of DSA, and his request to update the DSA delegation. The usual process is that the appointement of delegates is usually discussed between the DPL and the team. Of course, for well-functioning teams that propose a new delegate who already went through a training process, that discussion is rather likely to be short. But that's not a valid reason to suppress it completely and make it sound like a public demand that the DPL does the required paperwork (I'm sure that it was not Martin's intent, but it's still worth clarifying, I think). Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204164522.ga19...@xanadu.blop.info
Re: Please update the DSA delegation
On 02/12/13 at 22:11 +0100, Martin Zobel-Helas wrote: Hi Lucas, I am pleased to announce that DSA has promoted Héctor Orón Martínez to a full member of the team. Please update the delegation for the Debian System Administrators accordingly. Hi, I'd rather wait until we see where our current (private) conversation is going, as the job description could be updated/clarified as a result. Lucas signature.asc Description: Digital signature
Re: DPL helpers meeting on wednesday (2013-11-27)
On 26/11/13 at 14:11 +0100, Lucas Nussbaum wrote: Hi, As previously announced, we will have a DPL helpers meeting tomorrow (2013-11-27), at 18:00 UTC, on #debian-dpl. Hi, The meeting happened. Minutes: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-27-17.58.html Minutes (text): http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-27-17.58.txt Log: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-27-17.58.log.html Action items for next meeting: rafw follow status of anti-harassment bug (#728492). N: ask english l10n for review zack to draft questions for a survey of DDs lucas follow-up on TO definition discussion https://wiki.debian.org/DraftDefinitionTrustedOrganizationsDiscussion bgupta write a proposal for handling of debian.* domain names bgupta Work with SPI to get a Debian controlled Paypal account bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 bgupta Investigate accepting crypto-currency donations (With SFLC help) lucas follow-up on the events team discussion RichiH to add Debian logins to http://www.debian.org/intro/organization bgupta deal with http://debian.ch/opw2013/ (Perhaps point to main debian donations page) bgupta look to update text on http://www.debian.org/devel/leader regarding property, to reflect multiple Trusted Orgs Next meeting: 2013-12-16, 18:00 UTC, #debian-dpl Pad for next meeting: http://titanpad.com/debiandpl-20131216 Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128121705.ga26...@xanadu.blop.info
DPL helpers meeting on wednesday (2013-11-27)
Hi, As previously announced, we will have a DPL helpers meeting tomorrow (2013-11-27), at 18:00 UTC, on #debian-dpl. Titanpad with agenda: http://titanpad.com/debiandpl-20131127 (Please update the status of your action items before the meeting if possible) Lucas -- copy of the agenda below -8 #+TITLE: DPL helpers - working agenda #+DATE: [2013-11-27] * roll call * next meeting already planned: 2013-12-16, 18:00 UTC * Current DPL TO-DO list See live version at http://people.debian.org/~lucas/todo.txt Q: anything missing? * New topics * Action items from last meeting (please update status and mention if discussion is needed. if not, we will just skip it during the meeting) ** TODO rafw follow status of anti-harassment bug (#728492) ** TODO zack to draft questions for a survey of DDs ** TODO lucas follow-up on TO definition discussion https://wiki.debian.org/DraftDefinitionTrustedOrganizationsDiscussion ** TODO bgupta write a proposal for handling of debian.* domain names ** TODO bgupta Work with SPI to get a Debian controlled Paypal account ** TODO bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 ** TODO bgupta Investigate accepting crypto-currency donations (With SFLC help) ** TODO lucas follow-up on the events team discussion ** DONE lucas to send email to -project@ about using Debian funds for OPW ** TODO RichiH to add Debian logins to http://www.debian.org/intro/organization -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131126131150.ga22...@xanadu.blop.info
Re: DPL helpers meeting on wednesday (2013-11-13)
On 12/11/13 at 23:04 +0100, Lucas Nussbaum wrote: Hi, As previously announced, we will have a DPL helpers meeting tomorrow (2013-11-13), at 18:00 UTC, on #debian-dpl. Titanpad with agenda: http://titanpad.com/debiandpl-201311XX (Please update the status of your action items before the meeting if possible) Hi, The meeting happened. Minutes: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-13-17.59.html Minutes (text): http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-13-17.59.txt Log: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-11-13-17.59.log.html Action items for next meeting: rafw follow status of anti-harassment bug (#728492) zack to draft questions for a survey of DDs lucas follow-up on TO definition discussion https://wiki.debian.org/DraftDefinitionTrustedOrganizationsDiscussion RichiH to add Debian logins to http://www.debian.org/intro/organization bgupta write a proposal for handling of debian.* domain names bgupta Work with SPI to get a Debian controlled Paypal account bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 bgupta Investigate accepting crypto-currency donations (With SFLC help) lucas follow-up on the events team discussion (DONE) lucas to send email to -project@ about using Debian funds for OPW Next meeting: November 27th, 18:00 UTC Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115133323.ga20...@xanadu.blop.info
Debian participation in Outreach Program for Women
Hi, As you probably noticed[1,2,3], Debian is participating in the GNOME foundation's Outreach Program for Women. A targeted fundraising campaign[4] has been running, with the informal agreement that, if it was quite successful but not successful enough to fund one slot ($5750), the rest would be covered with Debian funds. However, we are in the situation that the fundraising campaign has been very successful. Despite quite late announcement, $2240 have been raised at this point, which are matched by one of Debian's sponsors[5], turning this into $4480. Which means that the share paid from Debian funds would be rather limited. I am now considering using Debian funds to cover for up to two slots. The maximum cost for Debian would be $7020 (2*$5750 - $4480), but could be reduced as the fundraising campaign is not over yet, and the GNOME foundation could agree to waive some fees. The Outreach Program for Women aims at building a more diverse Free Software community, and I think that this is something we care about a lot in the Debian project. Even if it's only marginally improving Debian on a technical level, it's clearly a way to improve Debian as a project and as a community. This is the first time we participate, and we are doing that mostly as an experiment. Having two data points instead of one is clearly useful, and I also think that it is important not to put too much pressure on the mentor and the intern. From a financial point of view, Debian could afford that (thanks to the fantastic work of the DC13 fundraising team) without restricting other standard expenses. I've informally consulted some people involved with fundraising, and they see it as an adequate use of Debian funds (= our regular donators are unlikely to read this as an insane way to spend their donations, that would jeopardize future donations). If you feel strongly about this, one way or another, please voice your opinion. [1] https://lists.debian.org/debian-devel-announce/2013/10/msg2.html [2] https://lists.debian.org/debian-devel-announce/2013/11/msg0.html [3] https://lists.debian.org/debian-devel-announce/2013/11/msg1.html [4] http://debian.ch/opw2013/ [5] http://www.debian.org/News/weekly/2013/18/#opwmatch Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115071811.ga28...@xanadu.blop.info
DPL helpers meeting on wednesday (2013-11-13)
Hi, As previously announced, we will have a DPL helpers meeting tomorrow (2013-11-13), at 18:00 UTC, on #debian-dpl. Titanpad with agenda: http://titanpad.com/debiandpl-201311XX (Please update the status of your action items before the meeting if possible) Lucas -- copy of the agenda below -8 #+TITLE: DPL helpers - working agenda #+DATE: [2013-11-13] * roll call * next meeting * Current DPL TO-DO list See live version at http://people.debian.org/~lucas/todo.txt Q: anything missing? * New topics * Action items from last meeting (please update status and mention if discussion is needed. if not, we will just skip it during the meeting) ** DONE lucas send a doodle poll with possible dates ** TODO rafw add something sensible about anti-harrassement on the website (C: draft almost ready N:once draft is finished, fill a bug similar to #719467) ** TODO zack to draft questions for a survey of DDs ** TODO bgupta improve https://wiki.debian.org/Teams/Auditor/Organizations based on TO definition discussions ** TODO bgupta respond to TO draft thread (after meeting with tbm) ** TODO RichiH to add Debian logins to http://www.debian.org/intro/organization ** TODO bgupta write a proposal for handling of debian.* domain names ** DONE bgupta Work with SPI to get an usaepay API key ** TODO bgupta Work with SPI to get a Debian controlled Paypal account ** TODO lucas,bgupta attend next SPI meeting (date -d @1384459200) ** TODO bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 ** TODO bgupta Investigate accepting crypto-currency donations (With SFLC help) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112220401.ga7...@xanadu.blop.info
Next DPL helpers meetings
On 28/10/13 at 16:17 +0100, Lucas Nussbaum wrote: Due to a lot of travelling for me during the next weeks, I've set up a doodle poll to schedule the next meetings: http://www.doodle.com/tnu46wcan8y69ipg (all times are UTC) The goal is to find one date between Nov. 11 and 14, one date between Nov 26 and 27, and one date between Dec. 16 and 19. Based on the attendance of the last meetings, I'll wait for answers from (at least): bgupta, paultag, rafw, richih, zack. Hi, The next DPL helpers meetings will take place: - on Wed 13/11, 18:00 UTC - on Wed 27/11, 18:00 UTC - on Mon 16/12, 18:00 UTC Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131108075539.ga17...@xanadu.blop.info
Re: Possibly moving Debian services to a CDN
On 29/10/13 at 10:54 +0100, Stefano Zacchiroli wrote: Just a minor nitpick on the point below; for the more general discussion I stand behind the opinion I've previously posted in this thread. On Sun, Oct 20, 2013 at 04:00:42PM +0200, Lucas Nussbaum wrote: After all, if we could use and point to 3-4 CDNs that are advocating Free Software, isn't it better to show that such core Internet services can be run using Free Software? I don't think whether CDN offerings (and/or the companies behind them) are *advocating* Free Software or not is relevant. IMO it's neither relevant for this discussion, nor it's relevant in general to decide the kind of relationships Debian should have with companies. Basically all medium-to-big sized companies are split on how much they advocate Free Software. You invariably find company parts that are hard-core Free Software advocates, and other parts that don't care and turn a living by developing non-free software and services that deprive users of the software freedoms they are entitled to. For the specific case of CDN offerings to the Debian Project, the point---well, my point, I respect the fact that others disagree it's a problem---is whether we're going to force our user to receive the Free Software we're distributing via infrastructures built using non-free software. That problem would exist even if the companies behind those services were big Free Software advocates, which just happen to have a single service (the CDN) built using non-free software. Right; my point is about CDN providers that are public about their use of Free Software (and possibly about their contributions to Free Software) for their CDN infrastructure. Not about companies advocating Free Software in general -- I agree that this would not be relevant. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131031143858.ga27...@xanadu.blop.info
Re: DPL helpers meeting on wednesday (2013-10-23)
On 20/10/13 at 17:53 +0200, Lucas Nussbaum wrote: Hi, We will have a DPL helpers meeting on wednesday: $ date -ud @1382547600 Wed Oct 23 17:00:00 UTC 2013 on #debian-dpl. Hi, Minutes: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-23-16.58.html Minutes (text): http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-23-16.58.txt Log: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-23-16.58.log.html Agenda: http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=blob;f=meetings/20131023/agenda.txt Also archived in: http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=tree;f=meetings/20131023 Due to a lot of travelling for me during the next weeks, I've set up a doodle poll to schedule the next meetings: http://www.doodle.com/tnu46wcan8y69ipg (all times are UTC) The goal is to find one date between Nov. 11 and 14, one date between Nov 26 and 27, and one date between Dec. 16 and 19. Based on the attendance of the last meetings, I'll wait for answers from (at least): bgupta, paultag, rafw, richih, zack. New action items: ** DONE lucas send a doodle poll with possible dates ** TODO rafw add something sensible about anti-harrassement on the website (C: draft almost ready N:once draft is finished, fill a bug similar to #719467) ** TODO zack to draft questions for a survey of DDs ** TODO bgupta improve https://wiki.debian.org/Teams/Auditor/Organizations based on TO definition discussions ** TODO bgupta respond to TO draft thread (after meeting with tbm) ** TODO RichiH to add Debian logins to http://www.debian.org/intro/organization ** TODO bgupta write a proposal for handling of debian.* domain names ** DONE bgupta Work with SPI to get an usaepay API key ** TODO bgupta Work with SPI to get a Debian controlled Paypal account ** TODO lucas,bgupta attend next SPI meeting (date -d @1384459200) ** TODO bgupta Write an HTML mockup for new donations page, and attach mockup to bug #681501 ** TODO bgupta Investigate accepting crypto-currency donations (With SFLC help) I've added those to an agenda at http://titanpad.com/debiandpl-201311XX Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131028151706.ga23...@xanadu.blop.info
Re: Possibly moving Debian services to a CDN
On 13/10/13 at 08:44 +0200, Tollef Fog Heen wrote:
We appreciate feedback while we continue our investigation of CDNs.
Hi,
I'm trying to summarize the discussion so far and add my own
understanding/thoughts, in a set of Q A.
Q: What problem are we trying to solve? What's the current status?
==
The Debian project needs to distribute content over HTTP; mainly
packages (on ftp.d.o and security.d.o) and websites (such as www.d.o).
For that, a set of machines running Debian and managed by DSA and
located in various datacenters all over the world are used.
Additionally, for ftp.d.o, Debian relies on mirrors provided by third
parties. Those mirrors are not managed by DSA, and might be running
non-free software (that could include primary mirrors, ie
ftp.*.debian.org).
Mirroring the Debian archive is tricky, as files need to be copied in
the correct order (to avoid having files in dists/ point to files
not yet copied in pool/). A script (ftpsync[1]) is provided by the
mirrors team, but is not used on every mirror AFAIK.
[1] http://www.debian.org/mirror/ftpmirror
The performance of our {packages,website} delivery network is an
interesting question. Like many things on the Internet, it's related to
a mix of bandwidth, latency, and application behaviour (e.g. use of HTTP
keep-alive). More and more, the dominating factor in network
performance is latency (as others are easier to optimize), and the
only way to reduce it is to have servers close (geographically or
network-wise) to end users. Benchmarking mirrors by measuring
bandwidth is generally not very relevant.
This raises several challenges:
- DSA needs to interact with many datacenters, often for only one
machine. This is very time-consuming.
- The mirrors team needs to constantly monitor mirrors and notify mirror
operators in case of problems. Notifications are automated, but DNS
updates to *.debian.org when a mirror fails are not.
- There are parts of the world that are not so well covered. For
example, http://deb.li/y8GA is the current map of security.d.o
mirrors (which are all managed by DSA), we don't have any point of
presence in Asia, which causes poor performance. There are discussions
in progress to buy a server and host it somewhere in Asia, and the cost
for Debian would be between $1500 and $2500 depending on the server's
specs.
One solution that has been developed is http.d.n. It's a redirector
service that redirects to the closest working mirror (the mirror
checking is automated). However, the http.d.n machine is still
centralized: round-trip time to it is still a problem, so, if the
service would become official, several geographically-distributed
instances of the service would have to be set up. Also, as each request
goes through a http.d.n redirect, there's a lot of additional latency.
If we want those http.d.n redirector machines to be managed by DSA
(which is probably something we want), it doesn't really improve the
situation in terms of machines DSA has to managed.
Q: What are CDNs? How do they compare to our mirrors network?
=
Content Delivery Networks (Akamai, Fastly, Amazon Cloudfront, etc. [1])
can be seen as giant location-aware caching networks. They provide
local points of presence and manage global caching of external data
inside the CDN network.
[1] http://www.cdnplanet.com/cdns/
As a solution based on caching, they work and perform quite differently
from our mirrors (where the Debian archive is fully replicated). It's
not easy to compare their performance, especially if you want to
consider access patterns on the mirrors (file sizes, long tail
distribution, etc.)
Q: Do CDNs raise more security/privacy concerns than our mirrors?
=
Not easy to answer. I'm inclined to say that they both raise about
the same amount of concerns. There's more discussion about those points
in the subthread starting at
http://lists.debian.org/2a773832-09f2-4adb-9b10-2a554b6dd...@2013.bluespice.org
Q: How does that meet with Debian's Social Contract and Free Software in
general?
Some CDNs use Free Software. As data points, Fastly[1,2] uses and
contributes to Varnish, and the frontend servers of Amazon Cloudfront
are running Apache.
[1] http://www.fastly.com/about
[2] http://www.fastly.com/about/open-source
Building a CDN is mostly an infrastructure problem: bring PoP in many
parts of the world, manage those servers, etc. It would be about Free
Infrastructure more than Free Software.
How much do we (Debian) care about Free Infrastructure?
The Social Contract says:
1. Debian will remain 100% free
[..] We promise that the Debian system and all its components will be
free according to these guidelines. [..] We will never make the system
require
Buying hardware with Debian money
Hi, I received a few requests for hardware purchases, that I think are worth discussing with the project as a whole in order to progress towards having clear guidelines for what is acceptable and what isn't in terms of spending Debian money. Please provide feedback on the proposed decisions -- they are not final yet. A. Memory expansion cards for m68k buildds (expected cost: 500 EUR) === Widely quoting from a private mail: | Debian has an unofficial m68k (Amiga) port. It became unofficial | mainly because build daemons were not fast enough to keep up with | security updates in a timely manner. The port has an active developers | community (see https://lists.debian.org/debian-68k/). Debian is the only | Linux distribution with a working m68k port, and m68k is still popular | among fans of retro computers. It takes little financial effort to keep | the port running; what is needed is money for small hardware upgrades. I'm inclined to APPROVE the request, for the following reasons: - even if the port is unofficial, and is very unlikely to become an official port again in the future, it benefits from an active developers community composed of several DDs. - experience has shown that porting work on one architecture often benefits other architectures (since similar problems show up across different architectures). - the amount of requested money is relatively low. Obviously, the following conditions would apply: 1) the hardware bought would have to go to buildds used through debian-ports.org, and/or to porter boxes that are widely open to the Debian community. 2) if the machine stops being used for Debian-related work, the hardware must be transferred to another DD. B. Powerful machine for d-i development (expected cost: 1.5k-2k EUR?) = A debian-installer developer writes: up to now, I've always used my own hardware for Debian work, but I'd like that to change slightly due to my work on d-i. I intend to work on at least the following topics: 1. performing more frequent d-i uploads: http://lists.debian.org/debian-boot/2013/10/msg00194.html 2. implementing some kind of official images with backported linux kernels (and possibly other needed bits from the right suite); 3. implementing automated regression testing, so that we can work properly on 1., 2., and also on stable uploads; dailies would also benefit from that; people from -cd@ (Steve, mostly) would probably appreciate it as well. Some desktop machine with fast disc(s), a bunch of RAM and some CPU power would be nice, so that I could play with a bunch of VMs (most likely, primary targets will be amd64 and i386, but virtually anything qemu can deal with). Some disc space to hold a local (possibly partial) mirror would be a plus, since there's plenty of deb/udeb fetching during d-i builds and when testing installation. Do you think something can be arranged on Debian funds to that effect? If that looks reasonable, any specific site/vendor I should be looking into to come up with some specs that would be nice to have, so that you ACK/NACK it? In which case, any upper bound? Or any other ideas? Of course the HW can be shipped over to the next person wanting to work that much on d-i in case/when I start burning out. (FWIW I don't plan on leaving the d-i RM position before jessie is released. ;)) [ Also, I do realize having some nice hardware racked up in some datacenter would be nice for testing purposes, but until automated regression testing is implemented, one needs to rely on clicking and typing into a VM, so as to debug/develop some framework to perform automated testing. A datacenter-hosted machine would also not help with the “preparing an upload” side, which still needs some trusted, local machine IMVHO. ] I'm inclined to APPROVE the request, for the following reasons: - the machine would be primarly (only?) used for working on Debian - the specifics of the tasks justify hardware hosted locally (VNC to a remote machine is possible of course, but latency makes it quite inefficient to do testing that way) Of course, as quoted in the original mail, if the DD were to stop their involvement in d-i development before the machine reaches its end-of-life, the machine would have to be shipped to someone else. C. Laptop for developer (expected cost: 1k-1.5k EUR?) = A DD is asking for help to buy a new laptop. He maintains or participates in the maintenance of a few medium-to-large packages. His only mobile computer is an Atom-based netbook with a rather small screen, which is not powerful enough to do packaging work (he also has a desktop computer). He describes himself as a first world middle class person, is currently a student, and cannot afford to spend money on hardware. I'm not sure of
DPL helpers meeting on wednesday (2013-10-23)
Hi, We will have a DPL helpers meeting on wednesday: $ date -ud @1382547600 Wed Oct 23 17:00:00 UTC 2013 on #debian-dpl. Titanpad with agenda: http://titanpad.com/debiandpl-20131023 (Please update the status of your action items before the meeting if possible) Lucas -- copy of the agenda below -8 #+TITLE: DPL helpers - working agenda #+DATE: [2013-10-23 Wed 17:00] * roll call * next meeting FIXME * Current DPL TO-DO list See live version at http://people.debian.org/~lucas/todo.txt Q: anything missing? * New topics * Action items from last meeting (please update status and mention if discussion is needed. if not, we will just skip it during the meeting) ** TODO zack find status of debbugs submissions over HTTP ** TODO zack to draft questions for a survey of DDs ** TODO bgupta respond to TO draft thread ** TODO bgupta improve https://wiki.debian.org/Teams/Auditor/Organizations based on TO definition discussions ** TODO lucas to include call for help for press team in next bits ** TODO lucas to follow-up on press team issues ** TODO RichiH to add Debian logins to http://www.debian.org/intro/organization ** TODO rafw add something sensible about anti-harrassement on the website ** DONE lucas check whether NE.ch was already counted in the surplus the NE.ch donation was already counted in the announced surplus. ** TODO bgupta investigate how to make a donations page on www.d.o -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131020155357.ga20...@xanadu.blop.info
Re: DPL helpers meeting on wednesday (2013-10-09)
On 08/10/13 at 22:29 +0200, Lucas Nussbaum wrote: Hi, We will have a DPL helpers meeting tomorrow: 2013-10-09 17:00 UTC (date -d @1381338000) on #debian-dpl Titanpad with agenda: http://titanpad.com/debiandpl-20131009 (Please update the status of your action items before the meeting if possible) Minutes: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-09-16.59.html Minutes (text): http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-09-16.59.txt Log: http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-09-16.59.log.html Agenda: http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=blob;f=meetings/20131009/agenda.txt;h=9784b6fa673f996909a5e84b1d5e6ceae570b2f7;hb=HEAD Also archived in http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=tree;f=meetings/20131009 Next meeting: $ date -ud @1382547600 Wed Oct 23 17:00:00 UTC 2013 Action items for next meeting: zack find status of debbugs submissions over HTTP zack to draft questions for a survey of DDs bgupta respond to TO draft thread bgupta improve https://wiki.debian.org/Teams/Auditor/Organizations based on TO definition discussions lucas to include call for help for press team in next bits lucas to follow-up on press team issues RichiH to add Debian logins to http://www.debian.org/intro/organization rafw add something sensible about anti-harrassement on the website lucas check whether NE.ch was already counted in the surplus bgupta investigate how to make a donations page on www.d.o Agenda for next meeting: http://titanpad.com/debiandpl-20131023 Thanks! Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131010112300.ga21...@xanadu.blop.info
