Re: non-free?
Stefano Zacchiroli z...@debian.org writes: On Mon, Mar 24, 2014 at 04:58:22PM -0700, Russ Allbery wrote: If one of our upstreams said that they wanted to rename a public API in a widely-used shared library because they thought the old name wasn't very accurate, we would almost certainly beg them not to, due to all of the pain this would cause for marginal benefit. I encourage people to think of the archive URLs in the same light. If anything, the pain is even worse. Just a side comment on this: your reasoning here is valid for full blown API renames, because they break backward compatibility. But the reasoning does not apply to: add a new public API, document it, preserve backward compatibility for the old API, drop the documentation for the old API --- in your analogy, it is this second option the closest to my (very) long term evil plan behind non-free.org. I think the analogy holds, though. With a shared library, you don't drop the old API until you have to do an ABI break for other reasons, which means that old binaries won't work against the new library anyway. At that point, you have a pretty clean break point where, provided people have addressed deprecation warnings, you lose nothing by dropping the old interface. For our archives, there is no such thing as an ABI break (or at least hopefully there won't be), so there is no point at which doing this would stop being painful. It's similar to dropping an interface from libc6. The right thing to do is just never do that, unless there's something so serious and so problematic you don't have any other choice. You will probably disagree that there is value in such an exercise, which is merely at the communication level, and which had never even been really promoted (yet). But this second criticism is definitely not in the realm of inflicting pain to existing users. I understand that inflicting pain isn't the goal, but that's what this actually does, whether intended or not. You have to go change sources.list on a bunch of systems, redo mirroring, find and change all your documentation, and so on. Plus, many of us have internal archives that parallel the same main/contrib/non-free setup for much the same reason, so now it's harder to explain to users how that works since we can no longer parallel what Debian is doing unless we set up completely separate repository hosts, for no particularly good technical reason. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhvypzzh@windlord.stanford.edu
Re: non-free?
On Mon, Mar 24, 2014 at 11:13:38PM -0700, Russ Allbery wrote: I think the analogy holds, though. With a shared library, you don't drop the old API until you have to do an ABI break for other reasons, which means that old binaries won't work against the new library anyway. At that point, you have a pretty clean break point where, provided people have addressed deprecation warnings, you lose nothing by dropping the old interface. What I'm saying is that there is no need of dropping the old API in any foreseeable future. Just stop documenting it. Because as long as we document it, it's very hard to claim that non-free is not part of Debian, when you could just add it as a keyword side-by-side with main in your sources.list. The point is not dropping the current interface. The point is stop teaching new users, generation after generation, that non-free is just one word away from main. At least make it one domain away! :-) And I understand that if we ever start documenting non-free.org (not that I think it'll ever happen, but just for the sake of discussion) there will be zealous sysadmins which will patch their sources.list because it's the right thing™ to do. I'll probably be in that set myself. But a) it will be their choice, and b) I personally think it would be an acceptable trade-off if in exchange we start putting some distance between ourselves and the current non-free is not part of Debian hypocrisy. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: non-free?
Stefano Zacchiroli z...@debian.org writes: What I'm saying is that there is no need of dropping the old API in any foreseeable future. Just stop documenting it. Ah, I see what you're saying. Okay, that probably minimizes the pain for everyone else, although I still don't really see the point. Because as long as we document it, it's very hard to claim that non-free is not part of Debian, when you could just add it as a keyword side-by-side with main in your sources.list. That's for a good reason: non-free is maintained by the Debian project. It's just not part of the Debian distribution. Yes, this is to some extent hair-splitting, but, well, welcome to free software. :) Doing this stuff requires a lot of hair-splitting, since it involves quite a bit of, as the saying goes, tepid change for the somewhat better. I think we should continue to maintain contrib and non-free as part of the Debian project because, by doing so, we enable people to use more free software than they otherwise would be able to do. So I'm not particularly upset by the fact that the repository system we uses clearly identifies contrib and non-free as maintained by the Debian project. That's honest. It doesn't sit right with me to hide that fact artificially. If we're going to actually stop maintaining those archives as part of our project, that's one thing. I think that would be a mistake, but at least it would be consistent. But I don't see much real hypocrisy in our current stance. I think we're honest about what we're doing: as a project, we have some additional work products outside of the Debian system that are designed to work alongside it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87eh1qpy0z@windlord.stanford.edu
Re: non-free?
This one time, at band camp, Paul Wise said: On Mon, Mar 24, 2014 at 11:51 PM, Neil McGovern wrote: I don't think that splitting this up helps our users. Using debian.org provides a trusted distribution mechanism. I think it's better that people get trusted non-free packages from us, than get them from a random third party by burying our heads in the sand and pretending non-free software doesn't exist. I agree with the last sentence there and note that this doesn't seem to preclude a split between non-free.org and debian.org (a split in name only). I'd rather we didn't split the archive this way. In the .rpm world, people are used to the idea that, for most useful software, you have to look outside the repo. The result is a million not particularly well done .rpms for a given piece of software, and no particular thing to recommend EPEL over lolrpms.cx to a newcomer. Let's not make the .deb world look like that. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Lucas, Since I am one of the local organizers this year for DebConf, which is Debian's single largest annual expense; and in light of the ongoing discussion you and I are having about DebConf budgeting; it should be no surprise that I have opinions on the question of Debian asset management. ;) So I'm going to pile on this thread with some questions to both candidates about their view of the DPL's role in responsibly managing Debian funds. On Fri, Mar 21, 2014 at 05:37:04PM +0100, Lucas Nussbaum wrote: On 20/03/14 at 22:44 +0100, Neil McGovern wrote: I don’t think there’s an “if” here. Ever since I was secretary of SPI, I’ve been concerned about the amount of money that Debian has earmarked. Again, I disagree with Lucas here - I don’t think that saving donors money is a good plan, our donators expect their donations to be spent to progress the project. At the moment, in just SPI, we have 100k USD awaiting being spent. As an indication, that’s enough for a DebConf without any sponsors! Our donations should be spent. Be that better porter boxes, or a better backup service, or simply making sure our core machines are replaced regularly. I would put it differently: in SPI, we have ~$100k. That's barely enough for a DebConf for which fundraising would mostly fail, or for which many unexpected expenses would need to be made! (the amount of sponsorship raised for DC13 was ~ $160k; the deficit for DC10 was $50k despite $90k of fundraising) (To Lucas) Why should Debian need to hold a reserve with its TOs to fully fund a DebConf for which fundraising has failed? I believe the operating principle is that the DebConf organization should never spend money that it doesn't already have - i.e., never more than the sum of confirmed DebConf sponsorship plus money from Debian's general fund that the DPL has approved (with the possibility, but not the guarantee, that it will be returned at the end of the conference). Do you disagree with this principle? If so - why, and what are the criteria you would use to decide a DebConf has failed at fundraising and dip into these reserves? If not - why does Debian need to worry about reserves to cover DebConf? (To both) What kinds of unexpected expenses do you think Debian should keep funds available to cover? What do you think is the appropriate level of cash reserves for the project to hold, and why? We need some amount of savings to care for all the unexpected problems that could happen, and at the same time, we need to spend money where needed to support Debian's goals. The really hard problem is to find a good balance between saving money for the unexpected, and spending more money. We need to be careful with that, and build a good understanding of Debian's historical needs so that we can spend more money if needed without jeopardizing the future. So, yeah, it seems that Neil and I disagree on that, because I don't think that it's as simple as 'our donations should be spent'. (To both) Management of Debian's assets is one of the key duties of the DPL. What principles guide you in deciding how to balance the use of Debian's assets (infrastructure, DebConf, other Debian sprints, other expenses)? If elected, what will you do to ensure transparency to the project about how Debian money is being spent, and how these expenses affect our overall cash reserves? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: non-free?
On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote: Because as long as we document it, it's very hard to claim that non-free is not part of Debian, when you could just add it as a keyword side-by-side with main in your sources.list. The firmware have been moved from main to non-free a few years ago. The unintended consequences is that almost every system now use the non-free suite. Therefore users are more likely to install non-free packages. Aren't you afraid that we end-up with unintended consequences, where users become prone to add foreign repository... that eventually break their system (the dependency hell...)? Aren't you afraid that users become prone to add various repository... including closed-source/proprietary software? The point is not dropping the current interface. The point is stop teaching new users, generation after generation, that non-free is just one word away from main. At least make it one domain away! :-) What's the workload on various teams and package maintainers for that fancy difference ? Is it really worth the time spent? Regards, Franklin -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395736346.4751.25.ca...@solid.klabs.be
Re: non-free?
On Mon, Mar 24, 2014 at 11:55:56PM -0700, Russ Allbery wrote: I think we should continue to maintain contrib and non-free as part of the Debian project because, by doing so, we enable people to use more free software than they otherwise would be able to do. So I'm not particularly upset by the fact that the repository system we uses clearly identifies contrib and non-free as maintained by the Debian project. That's honest. It doesn't sit right with me to hide that fact artificially. If we're going to actually stop maintaining those archives as part of our project, that's one thing. That's a very interesting viewpoint for me, because it's kinda dual to mine. I understand what you're saying and it has its own merits. But OTOH I see another part of our *current* stance as non honest, the part where we say that contrib and non-free are not part of Debian, because for many practical purposes that's simply not true. Essentially, that statement is true only for who has read it in the social contract, in a weird sort of self-fulfilling way. What is true --- and we should pride ourselves with it --- is that contrib and non-free are not enabled by default. But aside from that choice, often done once and for all, many of our users would have a hard time distinguishing which packages (that they use or otherwise) are from main and which are not. This is essentially why I'm in favor of communicating more and more clearly about where the red line between main (oops, I should have written Debian here instead of main, right?) and the rest is, as well as augmenting our tooling so that user are informed on a package by package basis about the freeness of what they use. An idea I've been toying with, which is up for grab due to the usual ENOTIME problem, is: - add debtags facets to classify non-free packages in terms of which freedom you give up when using it (is it non-redistribution? is it restriction of use? etc.) - make vrms ship APT hooks that tell the user about that Other ideas discussed in this thread goes in similar directions, including a refinement of non-free components, or making our APT frontend be more clear about the fact that the user is about to install non Debian software. (This time it sounds more scary, right?) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: non-free?
On Tue, Mar 25, 2014 at 09:32:26AM +0100, Frank Lin PIAT wrote: On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote: Because as long as we document it, it's very hard to claim that non-free is not part of Debian, when you could just add it as a keyword side-by-side with main in your sources.list. The firmware have been moved from main to non-free a few years ago. The unintended consequences is that almost every system now use the non-free suite. Therefore users are more likely to install non-free packages. Yup. Various conversations have happened around firmware in the last few years, but this is an effect that some people may not be aware of. So... Neil and Lucas: what do you have to say on this front? Of all the things that *could* be done here, what would you like to see personally? -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325102502.gi9...@einval.com
Re: non-free?
Stefano Zacchiroli z...@debian.org writes: That's a very interesting viewpoint for me, because it's kinda dual to mine. I understand what you're saying and it has its own merits. But OTOH I see another part of our *current* stance as non honest, the part where we say that contrib and non-free are not part of Debian, because for many practical purposes that's simply not true. It's a compromise, and as such neither side is happy with it. I think we should treat non-free software as part of Debian, but deprecated and discouraged and with large caveats about how we can't properly maintain it, it undermines user control over their own hardware, and we're providing it only because there is no good alternative. You (and others; I know your opinion is common) would like to push it farther away from the project and basically make it a separate, parallel project to Debian. We currently have a compromise that doesn't make either of us happy, but which is livable. I'm going to object to any attempt to move away from that compromise towards your preferred position, just as you're likely going to object to any attempt to move away from that compromise towards my preferred position. :) Right now, non-free is part of the project in some respects: it uses the same upload rights and vetting, the same bug tracking system, the same developers, to some extent the same buildd network, the same mirror network, and so forth. It's not part of the project in some other respects: no or minimal security support, not considered release-blocking, not enabled by default, and partially not auto-built. The reality is that it is part of the project but a second-class citizen. I think that's what we capture right now by saying that it's maintained by the project but is not part of our distribution. We could probably say that more clearly, but I don't think moving away from that compromise is a particularly good idea. (Unless, of course, you all decide that I'm right and we should just treat it as a deprecated and discouraged part of our distribution. *grin*) Bear in mind my background: I fought tooth and nail to use Debian as the primary (and fairly close to the only) Linux distribution for central computing services for Stanford. Stanford central IT, institutionally, doesn't really care about free software. (Well, that's not *completely* true, but management certainly doesn't care about the ideological argument for it.) Now, don't get me wrong: I believe in the ideology of free software myself, and I'm all in favor of supporting it. But insofar as I have to explain or work around practical, concrete problems with running servers that are created by free software ideology, it constantly reopens conversations that start with the question why don't we just use Red Hat like everyone else? Those conversations are always stressful and never fun. So I'm a little defensive around changes that would make my job, as a Debian advocate in an organization that doesn't have an ideological committment to our project ideals, even harder. I understand that you want to do this in a way that won't cause practical problems, so this is more in the way of explanation for my kneejerk response rather than a considered objection to your proposal. Essentially, that statement is true only for who has read it in the social contract, in a weird sort of self-fulfilling way. What is true --- and we should pride ourselves with it --- is that contrib and non-free are not enabled by default. But aside from that choice, often done once and for all, many of our users would have a hard time distinguishing which packages (that they use or otherwise) are from main and which are not. I think there is some common ground here. For example, I think both of these ideas sound fine: - add debtags facets to classify non-free packages in terms of which freedom you give up when using it (is it non-redistribution? is it restriction of use? etc.) - make vrms ship APT hooks that tell the user about that provided that I can easily disable warning messages with debconf preseeding, APT configuration, or the like on servers where I just don't care. Those sorts of changes feel lower-impact to me than shuffling everything off to a different domain. My concern is that, as part of an attempt to be cleaner and clearer about this, you will recreate all of the annoyances and roadblocks caused by backports.org being a separate project with a separate archive. Merging it with Debian as backports.debian.org was a huge improvement and made my life considerably easier (and I'm sure I'm not the only one). I would be sad to see us intentionally reintroduce that whole class of problems again in a different place. This idea: making our APT frontend be more clear about the fact that the user is about to install non Debian software. I think is fine in a different form. I think we want to say something more specific and concrete than non-Debian. Just
Re: Debian Project Leader?
On Sat, Mar 22, 2014 at 02:23:30PM +0800, Paul Wise wrote: Please imagine a Debian without the DPL position. How would it be better, how would it be worse, how would things work differently, would it be desirable? Hi Paul, I think there's a couple of aspects to this, one from an external project perspective, and one from an internal one. Externally, the DPL role is one that's useful for an interface between Debian and various organisations. This ranges from press, other organisations, and trusted organisations. Without a DPL, it would be quite difficult to have some speak on behalf of Debian in an authoritative way. As press officer, I've issued statements on behalf of the project for some issues, but this is restricted to the view of the project as a whole, so can be limited to the project has made no final decision yet, or developer X says Y. The DPL has a mandate to say things which allows them to be a bit more specific. From a practical point of view, SPI needs someone to approve expenses - I can't think of a simple way of this happening without a DPL. Internally, the DPL is someone who can coordinate and communicate. Talking to other developers, and ensuring that teams aren't being blocked by issues is a key role. Would this still all be possible without a DPL? Yes, but I think it would be improbable without someone *acting* in the DPL role, even if they're not officially elected to it. Recommended reading includes The Starfish and the Spider[0], I would recommend it for those interested in decentralised organisations :) Neil [0] http://www.starfishandspider.com/ -- signature.asc Description: Digital signature
Re: Debian Project Leader?
Hi Paul, On 22/03/14 at 14:23 +0800, Paul Wise wrote: Please imagine a Debian without the DPL position. How would it be better, how would it be worse, how would things work differently, would it be desirable? Someone said that Debian is an extremely functional anarchic project. I love that quote. What would be the impact of increasing the amount of anarchism in Debian by removing the DPL? That's a very good question. I think that the main problem would be with other entities Debian interacts with (other big players of the Free Software world, the press, etc), because such organizations are used to talking to organizations with someone clearly identified as the representative. For other outsiders (e.g., prospective contributors), it might make Debian slightly harder to grasp. Since we are already a quite complex project, it might not be a good idea to make us even more complex :-) Internally, we would need to adjust, but I'm quite sure that we would manage. Actually, the lack of a DPL might make everybody feel more enabled/empowered to solve problems that are usually deferred to the DPL, which could be a good thing. Lucas signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Steve, On 25/03/14 at 00:57 -0700, Steve Langasek wrote: (To Lucas) Why should Debian need to hold a reserve with its TOs to fully fund a DebConf for which fundraising has failed? I believe the operating principle is that the DebConf organization should never spend money that it doesn't already have - i.e., never more than the sum of confirmed DebConf sponsorship plus money from Debian's general fund that the DPL has approved (with the possibility, but not the guarantee, that it will be returned at the end of the conference). Do you disagree with this principle? If so - why, and what are the criteria you would use to decide a DebConf has failed at fundraising and dip into these reserves? If not - why does Debian need to worry about reserves to cover DebConf? (To both) What kinds of unexpected expenses do you think Debian should keep funds available to cover? What do you think is the appropriate level of cash reserves for the project to hold, and why? We need some amount of savings to care for all the unexpected problems that could happen, and at the same time, we need to spend money where needed to support Debian's goals. The really hard problem is to find a good balance between saving money for the unexpected, and spending more money. We need to be careful with that, and build a good understanding of Debian's historical needs so that we can spend more money if needed without jeopardizing the future. So, yeah, it seems that Neil and I disagree on that, because I don't think that it's as simple as 'our donations should be spent'. (To both) Management of Debian's assets is one of the key duties of the DPL. What principles guide you in deciding how to balance the use of Debian's assets (infrastructure, DebConf, other Debian sprints, other expenses)? If elected, what will you do to ensure transparency to the project about how Debian money is being spent, and how these expenses affect our overall cash reserves? (I'm answering globally, but I'm trying to cover all questions) One thing I was quite surprised to discover when I became DPL is the lack of visibility on Debian's assets. For example, we have no good visibility of incomes and expenses on the Debian earmark at SPI, besides the monthly treasurer's reports sent to SPI mailing lists (and those reports have been lagging a bit: the last one was for October, 2013). What I am proposing in my platform (3.3.1) is to build an overview of Debian's incomes and expenses, to make it easier to adjust future expenses to what we know we can afford based on recent history. Quite likely, that will mean that we are actually able to spend more for sprints, DebConf, or infrastructure, because we might currently be too careful due to a lack of overview of Debian's finances. However, the main guiding principle / litmus test when deciding about expenses should remain the same: would our donors agree that this is good use of their donated money, i.e. does that use of money really helps us move towards Debian's goals? Now, DebConf. A successful DebConf is very important to Debian. When discussing the DebConf budget, the DebConf organizers, the chairs and the DPL are actually on the same side, trying to answer a difficult question: how can we build a balanced budget that allows a successful DebConf? I think that the good way to visualize the DebConf budget is as a temporary fork of the Debian budget, with quite a lot of pre-approvals. DebConf is not a separate organization, and Debian will always cover the deficits (if any) of DebConf. That's why it is so important that we all agree on a budget early during DebConf organization, something we have not been doing yet this year, unfortunately. (more minor points:) Regarding transparency, I will continue to list approved expenses in the monthly reports. Regarding the appropriate level of cash reserves, I hope that we will have an answer to that question soon, thanks to the work described above. Lucas signature.asc Description: Digital signature
Re: two questions: fund raising money and publicity
Hi Ana! On Wed, Mar 19, 2014 at 10:21:20AM +0100, Ana Guerrero Lopez wrote: DebConf is one of the biggest expenses of Debian, every year we look for sponsorship and we had (and have) sponsors who were sponsoring DebConf as a way of giving their annual donation to Debian and not necessarily funding DebConf itself. (Do you agree with this part, BTW?) Yes and no :) Having written (if my memory serves me correctly!) the first sponsorship brochure for DebConf 7 I view it as slightly more subtle than that. If DebConf didn't happen, then I don't believe that would mean that there would be an equivalent annual donation that would come in. The funding that's given is committed for a reason - sponsorship of an event raises the profile of the company for the attendees, enable recruitment and offer opportunities for contact building, as well as being give back to the community. I don't think that a general give money to Debian request has quite the same draw. There's a reason it's much easier to raise money for a specific goal/thing than in general :) In recent years, we have started to invest more Debian money in stuaff such like sprints and minidebconfs¹ that sometimes look for external founding. This has lead to some cases where sponsors have been contacted for separate teams in Debian which can be confusing. If you think this is a problem. How do you think we can improve this? I do view this as a problem, and the short answer is that I support Brian Gupta's efforts in the debian-sponsors-discuss list[0]. It's something we should be encouraging, and would potentially draw people into Debian who have not previously felt able to contribute. A great article on fund-raising of a talk from Josh Berkus is at [1]. [0] http://lists.alioth.debian.org/pipermail/debian-sponsors-discuss/Week-of-Mon-20140310/79.html [1] https://lwn.net/Articles/560381/ * Publicizing Debian We have several officials ways of publicizing stuff in Debian: press releases, identi.ca, bits.d.o and the DPN. We also have the bits from the DPL that sometimes overlap with the above sources and announce stuff that should be announce somewhere else instead of mixed with the DPL activity. That said, the coordination between the above sources doesn't work very well, all of them have a lot of room for improvement (and I say that being closely involved in one of them) and I have seen Debian contributors lost about what to do when they want to announce something, sometimes being played as a ping pong ball between teams. I would love to know your vision about how publicizing Debian should work and if you think you can do something as DPL to improve the current situation. Indeed, with my press officer hat on, I'd say that publicity and press is just about scraping by. This isn't to denigrate the fantastic work being done in this area by people, but that I think everyone's overworked, and could do with more help. When Lucas looked at the press delegation, a few of the active publicity people were approached to suggest they may want to become press officers, but unfortunately weren't able to commit the time to do so. Ideally, I'd love to see someone with the enthusiasm and time to take this on, to coordinate our efforts and bring together the different methods of communication we do. As for how to solve this issue, I'll be honest: I don't know. I think that coordination of publicity should go through the debian-publicity mailing list if at all possible, but the core issue is finding someone to take the role and drive it forward. Neil -- signature.asc Description: Digital signature
Question on DPL delegations.
Le Tue, Mar 25, 2014 at 05:44:55PM +0100, Lucas Nussbaum a écrit : Internally, we would need to adjust, but I'm quite sure that we would manage. Actually, the lack of a DPL might make everybody feel more enabled/empowered to solve problems that are usually deferred to the DPL, which could be a good thing. Hi Lucas and Neil, without DPL, there would be no DPL delegations. I have a question for you related to delegations. When a delegate is completely inactive as a delegate, do you think that his delegation should be renewed ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325223112.ga31...@falafel.plessy.net
