Re: Thoughts/questions for any candidate
> "Anthony" == Anthony Towns writes: Anthony> Number one is something like "where should the innovation come from?" GN> You may notice that unlike in previous years, I do not have a Grand GN> Vision, not in the same sense at least. MD> Of course, those are not trivial questions and I don't claim I have MD> answers. Solutions and ideas will come from contributors. Solutions MD> will come from you! Do not be shy and do make proposals. Anthony> I think it's fair to say algernon and mehdi both emphasise the role of Anthony> supporting other people's innovative ideas rather than promoting their Anthony> own. (Maulkin splits the difference a bit, I think, given he's got a Anthony> specific proposal for PPAs and buildds in his platform) Anthony> That's a very workable plan, but it has one (IMO) huge drawback: the Anthony> DPL position is /the/ optimal place to be in Debian if you want to be Anthony> innovative. I respectfully disagree. The DPL position is the perfect place to be visible, and to attract attention. It is a terrible position to innovate from. There is this great picture I saw just the other day: https://pbs.twimg.com/media/BwCLXMrIQAAxHEA.jpg A similar idea applies to the DPL's role in innovation. Anthony> You have resources, your ideas have been scrutinised and Anthony> (to some extent) approved by the developers, and (almost) Anthony> whenever you want it you've got the immediate attention of Anthony> developers, users, the press, or sponsors at your beck and Anthony> call. Is it fair to expect cool new innovations within Anthony> Debian if all the attention goes to someone who's not doing Anthony> cool new stuff? Yes, it is fair to expect that. Except, that attention can be directed further, where it needs to be directed. It's easy to look at the DPL, and see all the attention the position gets. But, one of the tasks the DPL has to do, is to lead that attention to ideas and people who deserve it. The DPL doesn't just lead a project, but also leads - at least in some way - the incoming attention and resources to their rightful place. Anthony> So, specific question: do you also see this as problem worth attending Anthony> to? Do you have any solutions in mind? I believe that the perception that the DPL position is - or should be - the source of ideas and innovation is a problem worht attending to. Anthony> Number two is something in that nature of "how to share the DPL's Anthony> workload". I think this is widely acknowledged as a challenge, eg: NM> the job of the DPL is a tough one that requires a lot of work, and NM> I don't want to bite off more than I can chew MD> The DPL role is very time-consuming. To be able to do it seriously, MD> I will put on hold my other Debian activities for the duration of MD> the mandate. Anthony> I have three thoughts on that. First is that (I believe) one of the Anthony> biggest workloads for the DPL is conflict resolution/mediation. But Anthony> there's recently been some talk about the tech ctte addressing that same Anthony> issue eg [1], [2]. It's obviously an open question whether it will work Anthony> or not, but I'd be interested to know if the DPL candidates are thinking Anthony> of trying to help make it work, and (if/when it does) to refer folks to Anthony> the ctte freeing up DPL-time for other things? I'd rather keep that workload closer to the DPL position, and delegate other tasks instead, at least in the short run. As mentioned in [1], giving this task to the CTTE would be considerable effort, and would also require buy-in from current and future members of the committee. On the other hand, I agree with the idea of approaching the TC sooner. Just not with the idea of the TC being the *primary* body of conflict resolution/mediation. That requires a very different skill set, than deciding on technical issues alone. Anthony> The second idea on this I have is perhaps a little twisty. First a Anthony> reference from a while ago: [3]. There have been lots of ideas on how to Anthony> scale the DPL role -- teams, 2ICs, boards, helpers, etc. Problem is, none Anthony> of them have worked perfectly, and everyone who's elected DPL is a leader, Anthony> not a follower, so they come up with their own plan from scratch. Then Anthony> that idea doesn't work perfectly either, rinse, repeat. At some point, Anthony> we need a DPL who'll take one of the previous ideas that worked a little, Anthony> improve it only slightly (ie, so it's still recognisable), and turn it Anthony> into a tradition that can keep improving. Any chance of that happening Anthony> this year? I do not think that the plans this year - or the years before, going back a few - are entirely from scratch. Each year, there are more and more common themes between the platforms
Re: Q to all candidates: Debian in five years?
> "Lucas" == Lucas Nussbaum writes: Lucas> In five years, what should Debian's position and role be in the Free Lucas> Software ecosystem? Lucas> Are there other positions where we somehow risk ending up? Lucas> What can we rely on to get to that ideal position/role? Lucas> What are the main things we should worry about (including, but not Lucas> limited to recent trends in the Free Software world)? There's a move towards running services in containers, which favour specialised distributions. Staying true to the "Universal OS" tagline, we have a great opportunity to offer ways to customize the OS in ways suitable for a very small and specialized container. That's one thing to aim at within five years, if the current trend sticks (which I hope it won't, but that's besides the point). Our role there would be to provide a strong, reliable base system to build upon: like we are the most "forked" distribution on the market already. The trust we built up over the years, our technical excellence and our commitment to the Social Contract are some of the things we can rely on when trying to enter another segment of the distribution world. A threat I worry about most goes hand in hand with moving to other people's computers: more and more people seem to accept non-free services, more and more people build their solution on non-free platforms. Sure, there are some free software components in there, but if you are tied to non-free platforms, that is a cause for concern. This is the trend I fear and worry about most -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: dropping SC §5
> "Bas" == Bas Wijnen writes: Bas> Everyone seems to mention firmware; I don't hear anyone saying we really Bas> need to support games with non-free game data, or shareware programs. Bas> And I agree. Bas> So to the candidates: can you please let us know whether you would be in Bas> favor of restricting non-free, so that it will only contain things that Bas> are required for making hardware work, and for which there is no fully Bas> functional free alternative? If not, do you think restricting it on Bas> other grounds is a good idea? If so, which criteria would you Bas> suggest? We also have documentation in non-free. Documentation of Free Software. I don't think it would be a good idea to keep non-free firmware for closed hardware, but throw out documentation for free software, even it if fails to meet the DFSG. Having sub-categories on the other hand... Bas> This is also related to Paul's point: Bas> On Tue, Mar 17, 2015 at 02:16:09PM +0800, Paul Wise wrote: >> Add an extra component that d-i could add to sources.list when >> non-free firmware is needed, instead of adding all of non-free. >> >> Likewise for drivers, GNU documentation, the web, tools for external >> APIs and other common categories of non-free things. Bas> (Aside: I like all the ideas in Paul's mail, but this one is relevant Bas> here.) Bas> Would you be in favor of such categories of non-free, where we can Bas> perhaps include some of them (firmware) by default on installation Bas> media? This would be useful, but I still wouldn't enable any such category by default. D-i could tell the user they may need some of those repositories, but in the end, adding them should be a conscious choice From the user's part. But that - again - wouldn't bring us any closer to dropping SC §5, yet, would complicate a number of things, for - in my opinion - little gain. I'd support such an initiative, if the relevant parties are all for it, but I wouldn't actively push for an implementation. -- |8] signature.asc Description: PGP signature
Re: More women in key positions ?
> "Charles" == Charles Plessy writes: Charles> You probably noted that no woman was candidate this year, and that no woman was Charles> appointed to the technical committee in the recent replacements. Charles> Do you think that it is a problem that there are no women in key positions in Charles> Debian ? If yes, what do you plan to ameliorate the Charles> situation as a DPL ? As Mehdi noted[1], there are women in key positions already, and considering how few women we have in the project, I agree with him that the status quo is not terribly bad - even remarkable, if you look at the ratios. [1]: https://lists.debian.org/debian-vote/2015/03/msg00095.html I wouldn't mind having more women in key positions, be those technical or non-technical positions. But to get there, our aim should not be to have women in such positions, but to have more women in Debian, in the wider Free Software community, and in the even wider CS/IT field in general. And that's one tough thing to accomplish, but we made - and are making - progress. A more welcoming environment certainly helps, but sadly our industry is not nearly as welcoming (or tolerant) to women as we'd like it to be. My aim is to help change that situation, in whatever way I can. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: SWOT analysis
> "Lucas" == Lucas Nussbaum writes: Lucas> Hi, Lucas> You are probably familiar with SWOT analysis Lucas> (https://en.wikipedia.org/wiki/SWOT_analysis). I am not familiar with SWOT analysis, but read through the wiki quickly. Lucas> From your perspective, what are Debian's main strengths, weaknesses, Lucas> opportunities and threats? Our strengths lie in our core values, in my opinion: in the social contract and the DFSG. That, combined with our distributed, volunteer developer base are what give us an advantage over others, in my opinion. And therein lies our weakness too: noone really has control over Debian, which is a terrific strength, but also a great weakness too. Why? Because driving an entity such as Debian forward is way more difficult with a large, volunteer developer base. And not only that: keeping it working smoothly, keeping it relevant amidst conflicting interests is going to be considerably more difficult, than if we didn't have these strengths. A major "threat" I see is the increased reliance on other people's computers, and containers, that make general distributions like Debian less relevant. That's a segment where we aren't all that strong as we could be. Not to mention that this environment can easily encourage more liberal use of non-free software and tools. While that may not directly threat Debian, those are a threat for our core values, and therefore, to Debian too. Our major opportunity would be to react to the changing environment. Why would that be an opportunity, one may ask... It would be one, because we may have an advantage there: we have well documented and understood values and policies. Strong beliefs in what's right for our users. We have been reliable for decades, and stayed relevant all these years, despite all the change in and outside of Debian. With these experiences, with our commitment to our values, we have the opportunity to conquer the new world too. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: the "DPL team"
>>>>> "Anthony" == Anthony Towns writes: Anthony> On Mon, Mar 16, 2015 at 09:46:04AM +0100, Gergely Nagy wrote: >> The DPL already has the power to delegate tasks. I do not see how >> electing more than one person would help with sharing the work: if it >> can be shared, it is already possible to do so. Anthony> Hey, that's a good question. How /is/ electing more than one person Anthony> different to electing one person and letting them delegate? Anthony> Here's some ways: Anthony> - no single point of failure (if the DPL disappears, there aren't Anthony> new delegations) If the DPL disappears, we shouldn't be afraid to elect a new one. And according to 7.1 of the Constitution, the Secretary and the CTTE Chair can stand in for the DPL meanwhile. I would not be opposed to officially delegate a small number of people (likely from DAM/MIA/Secretary) who can declare the DPL absent, and thus, allow the Secretary and the CTTE chair to take over responsibilities quickly. With this in mind, I do not think the DPL is a single point of failure, because we already have procedures to handle that situation. Anthony> - delegates don't have authority of their own, and the DPL can just Anthony> undelegate them; so an elected position is "more impressive" than a Anthony> delegated one, and you can maybe do more impressive things with it? I may be biased, but I believe that delegates are more impressive, than elected positions. An elected person can also be removed from office - though, that's much harder to do than undelegating someone. Anthony> - delegates tend to have specific, well-defined powers/responsibilities Anthony> while the DPL position can be used for lots of things (mediation, Anthony> inspiring speeches, handing out money, setting roadmaps, negotiating Anthony> with partner organisations, ..) I do not think this is a bad situation, to be honest. Having different people handling the mediation, money, roadmap and other stuff can quickly become confusing. Even more so if the involved people are not in full agreement. Anthony> - if one person goes off in a weird direction, it's easy to throw Anthony> them out and choose someone different; if a whole bunch of people do, Anthony> getting rid of all of them can be harder Well, that's a good reason for having a single DPL, instead of a team. :) >> Electing more people would also overcomplicate the process. Anthony> So if one elected person and delegates is better for the DPL, shouldn't Anthony> that apply to the tech ctte too? Just appoint a chair and let them pick Anthony> half a dozen folks to help out. Yes and no. The CTTE must work together with the DPL, therefore the DPL having a say in its composition can be desirable. Furthermore, I believe it is healthy to let the CTTE choose their own Chair, and that wouldn't work well, if the chair was appointed. I toyed with the idea of trying to push a CTTE reform, but have given up on it by now. I came to the conclusion that the CTTE works better as a (reasonably) DPL-independent body. I'd like to see how well (or how bad) the recently introduced new rules work, before pushing for any bigger changes. -- |8] signature.asc Description: PGP signature
Re: Q to all DPL candidate: PPA
> "Thomas" == Thomas Goirand writes: Thomas> On 03/15/2015 09:57 AM, martin f krafft wrote: >> Neil, >> >> in your platform, you advocate PPAs and modernising our build and >> infrastructure. >> >> What's the DPL's role in this? Or, put differently, couldn't you >> just start working on this without the DPL hat? Why not? What's the >> difference here? Thomas> Well, actually... Thomas> To all: what do you think you can do to make the PPA thing happen? That's a tough one, because PPAs depend on a number of things, and the DPL has little influence on some of those. What a DPL can do, is encourage, try and get the appropriate people together at a sprint to push things forward. I think pushing PPAs forward would be a good candidate to spend Debian funds on, as they would benefit us tremendously in both short and long-term. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: spending money
> "Lucas" == Lucas Nussbaum writes: Lucas> In his platform, Neil wrote: >> I will spend some money we have horded. Debian currently holds >> approximately $200,000 at SPI alone. Our donators didn't give us money >> for it to be sat around in a bank account, we should spend it to make >> the project more successful. Lucas> Other candidates: what will be your approach to that? Already touched this elsewhere, at least in part, but a non-exhaustive list would be: * Outreach: One of the problematic thing about Debian is the lackluster recruitment. We hardly do any active recruiting. This is an area where supporting the outreach could yield great results. I'm not only thinking about Outreachy (but that's a wonderful programme too, about which I talked about briefly in an earlier mail), but about reaching people in other ways too. Sprints and meetings, while useful on their own too, may also be used for outreach. That would obviously runs the risk of making the sprint and the meeting less effective, and places more burden on the people involved. But perhaps if we've done them more frequently, with more people involved (just not at the same time), we could balance that out. Just to give an example: an ftp-* "sprint" that goes through NEW, and at the same time teaches the intricate details of licensing to participants would be educational. It may not attract many people, but who knows? I'm sure we can come up with Debian-funded events that benefit both Debian, and the wider community we want to recruit from. * Meetings, sprints: Great stuff. I'm a big fan of in-person collaboration, and would like to encourage more of it. Possibly with travel or accomodation sponsorship. * Conferences, events and the like: Similar to what Neil wrote: banners, leaflets, whatsoever. I'd even go as far as suggest that we could use Debian funds to cover the expense of people participating in paid-for events in some cases. Of course, one has to be *very* careful and strict about this one... I'm not entirely convinced it would be a good idea, but I'll just throw it in. * Accounting & Treasury: See my reply to Martin. In short: outsourcing accounting & treasury to a professional agency is something I'd seriously consider. Lucas> All candidates: how will you reconcile that with the fact that the DPL Lucas> currently only has a limited vision of what funds are available, and how Lucas> they evolved over time? See my reply to Martin's suggestion of outsourcing accounting & treasury. Having a limited vision of what funds are available is something we should fix, one way or the other. But until such time that we have a clear view, seeing the larger picture, a rough estimate of how much we get in, and how much we spend, is enough to base reasonable decisions upon, without the risk of running out of money. (Better err on the side of safety, and so on.) -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: spending money
> "Martin" == Martin Zobel-Helas writes: Martin> Will you revoke <20131008134615.ga19...@xanadu.blop.info> or do you Martin> think this authorization is useful? I have no plans of revoking that authorization. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: spending money
> "martin" == martin f krafft writes: martin> also sprach Lucas Nussbaum [2015-03-12 10:16 +0100]: >> All candidates: how will you reconcile that with the fact that the DPL >> currently only has a limited vision of what funds are available, and how >> they evolved over time? martin> All candidates: what do you think about outsourcing some of the martin> gruntwork related to accounting and treasury to professional martin> agencies? The goal here would be to free up our volunteers to martin> develop Debian and actually force us into more discipline. While I understand the concerns of doing so, but I would support outsourcing accounting & treasury to a professional agency. Even if it wouldn't help us having a better overview of our current and past financial status, we'd have a much better idea of it in the future. I wouldn't worry about locking ourselves into one such agency. Switching agencies isn't that terrible: we have all the data and papers, which we can transfer to the new agency, if so need be. On an arguably much smaller case, I switched accountants a number of times, with no issues at all. I had insights into businesses that did the same, without a hiccup. I do not think we need to find an agency that uses free software only. We do not apply that principle to other companies we work with, either. We buy hardware designed with non-free tools. We take part in programs run by companies that use and write a lot of non-free software. And I could continue the list. What counts, is that we get the job done, and we can work together in such a way that *we* only rely on free software. I do not think we'd be any less Free, would we pay a professional agency to handle our accounting and treasury. It would cost us money, though. But seeing as our funds are growing, and we're talking about how to spend that money, this would be a good option. It would help us see clearer, and would take the burden off of volunteers, who would rather do something more enjoyable instead. Of course, if there are enough people within the Debian project, who want to handle these issues, all the better. Yet, if over the years, they didn't make themselves known, I don't think we should expect them to magically appear. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: fundraising
> "martin" == martin f krafft writes: martin> What is your perception of fundraising in and around Debian? I think fundraisers can be great, for specific non-recurring tasks, or as an additional source of funding for significantly larger ones, which would be very hard to fund otherwise. In my opinion, if a recurring project is successful, and we keep doing it year after year, then we should try our best to minimise the amount of fundraising required. martin> If anything, what changes would you like to help implement? I'd like to find stable funding for recurring tasks, whenever possible, be that through sponsors, or from general Debian money. Furthermore, my experience with fundraisers is that hard to obtain goals are rarely reached. On the other hand, running additional fundraisers for the stretch goals can yield a lot more support, than running one larger thing. I have not followed Debian and Debian-related fundraising efforts recently, but if we have not tried alternative ways of running one, perhaps we should. Sponsors doing matching donations is also something that sends a signal of importance and stability, which encourages people - at least some people - to take part in the effort. Therefore, finding more such sponsors would be a useful effort. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: spending money
> "Stefano" == Stefano Zacchiroli writes: Since Stefano asked the other candidates to answer too, my answers are below: Stefano> On Fri, Mar 13, 2015 at 06:44:45PM +, Neil McGovern wrote: >> * Outreach. Every team complains (quite rightly!) about the lack of >> people to do the work. Yet we seem to be rather poor at actively >> recruiting people to come and do things for us. Outreachy is a great >> initiative, and I would love to see a Debian Apprentice scheme (though >> that's probably a bit of a stretch goal!) Stefano> So, to be clear: would you authorize to use regular Debian funds to Stefano> sponsor Debian participation into Outreachy (which costs ~6000 USD per Stefano> intern), rather than going necessarily through dedicated fund raising Stefano> campaigns at each edition? I'd authorize the use of regular Debian funds to sponsor our participation into Outreachy. Stefano> Considering that there are 2 Outreachy sessions per years, how many Stefano> slots per year do you think it would be sensible funding on general Stefano> Debian funds? From the top of my head, I'd think at most two interns could be sponsored (per year) from Debian funds. But I'm not opposed to others more involved in GSoC and/or Outreachy suggesting more. It would take quite a bit of convincing to make me accept that sponsoring less than two interns per year would be more beneficial than supporting more than two. Stefano> (And of course doing the above wouldn't rule out running dedicated fund Stefano> raising campaigns to sponsor *extra* slots.) While there is also a fundraising question on -vote@, I'd like to share my general feeling of fundraisers here, too: fundraisers can be great, but when a project is done year after year, and the results of it are so valuable that we keep doing it, then perhaps it is time to figure out a better way to fund it, than having to run fundraisers. Fundraising can still be an additional source of funds, may even be a required part of funding, but in these cases, it should not be the only source. Preferably, the more times a recurring thing occurs, the less it should rely on fundraising. I'll try to share a few more thoughts in the 'spending money' and 'fundraiser' threads later. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: dropping SC §5
>>>>> "Stefano" == Stefano Zacchiroli writes: Stefano> On Mon, Mar 16, 2015 at 09:31:03AM +0100, Gergely Nagy wrote: >> So, the only way I could see the drop of SC §5 as a worthwhile goal, >> is if we also removed non-free (and possibly contrib) too. Stefano> I respect this point of view, even though I disagree with it: I think it Stefano> is desirable to drop SC §5, without (at least at the same time) dropping Stefano> contrib/non-free from our infrastructure. Stefano> But let's embrace your point of view for now! It seems to me that doing Stefano> so result in the impossibility to *ever* drop SC §5. Because: Stefano> - The only way to drop SC §5 is by voting, and we know from experience Stefano> that voting on something does not make the needed volunteer to Stefano> implement the vot (= getting rid of contrib/ non-free) magically Stefano> appear out of thin air. Stefano> - On the other hand, contrib/non-free cannot be removed while SC §5 is Stefano> still around. Stefano> Should I conclude that you consider impossible to ever drop Stefano> SC §5? No, not quite. I very much would like to drop it, along with non-free, and I believe that there will be a time, hopefully in the not too distant future, where we may be able to do that. Over the past few years, from my point of view, we've been getting closer and closer. They should be dropped at the same time, because removing only one makes - in my opinion - little sense. Mind you, dropping contrib / non-free does not need to happen immediately. A commitment that we'll do it at some point is good enough for me, so we don't have to pull volunteers out of a magic hat. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: DebConf orga
> "martin" == martin f krafft writes: martin> Dear candidates, martin> What is your perception of DebConf and its organisation? martin> If any, what changes would you like to implement? Unfortunately, I have no insight into how the DebConf organisation works. My perception, from what little I saw and see, is that the inner workings aren't as awesome as the resulting conferences (based on my experiences in Banja Luka and Vaumarcus). The most immediate change I'd implement has nothing to do with the DebConf orga team: I'd like to have more insight, and that's up to me. I have a huge backlog (mostly mailing lists and IRC) there, which I have to work though, and a number of people to talk to (because not everything happens on lists I'm subscribed to). Regardless of the outcome of the DPL election, I'd like to get up to speed, and maintain at least a read-only involvement, if for nothing else, then because I'd love to bring a DebConf to Hungary at some point. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: the "DPL team"
> "martin" == martin f krafft writes: martin> Have you considered working with a "DPL team" and if so, why have martin> you decided against including such plans in your platform? Working with a DPL team has been at the back of my mind since zack's DPL helpers initiative. However, this year, I have not considered it at all. At least, not in the same sense. martin> On the other hand, if you're open to the idea, what do you think martin> worked well and what did not work in previous attempts? How would martin> you approach a "DPL team"? The DPL already has the power to delegate tasks. I do not see how electing more than one person would help with sharing the work: if it can be shared, it is already possible to do so. Electing more people would also overcomplicate the process. If the "DPL team" would not be elected, then how would it be different than a special delegation? The only situation I can imagine that may work better than the status quo, if people nominated themselves together, as a team. That would be interesting to see, how it works. I see great potential in that, yet, that's a much larger effort than running solo. Requires more coordination, for one. Makes it harder to have a single point of contact, whom other projects and entities can talk to... - just to name a few things off the top of my head. martin> Do you have other ideas involving close cooperation with a few martin> people for increasing the efficiency of the DPL position, especially martin> since I understand none of you will be working on this full-time (… martin> which would be a whole different issue…)? Since I will not be working full-time (to say the least), if elected, I will *have to* involve people in close cooperation. I have a few people in mind, whom I'd like to approach (but the time for that, in my opinion, is after the vote). As I wrote in my platform, one goal of mine is to take back the DPL role to a level that is reasonably doable by a single person, and delegates. To lower the expectations towards the single DPL, and instead, spread that out over the entire project. -- |8] signature.asc Description: PGP signature
Re: Q to all candidates: dropping SC §5
> "Stefano" == Stefano Zacchiroli writes: Stefano> do you think the time is ripe for dropping section §5 of the Debian Stefano> Social Contract [1], namely "Works that do not meet our free software Stefano> standards" or should we wait more? [...] Stefano> - Dropping SC §5 would not necessarily mean removing contrib non-free Stefano> from our mirror network, from our dak instance, etc. It might simply Stefano> mean stopping publicly sanctioning that Debian aims at supporting Stefano> mixed free/non-free setup. Developers interested in working on Stefano> contrib/non-free will not be stopped by doing so even if SC §5 would Stefano> get dropped. Stefano> No matter the timing, do you see dropping SC §5 as a worthwhile goal at Stefano> all? That's a tough thing, to be honest. On one hand, supporting non-free sends a message I'm not particularly happy with. On the other hand, it allows a lot of people to work with free software, on hardware that doesn't work without non-free - and this is beneficial. If we keep non-free on our mirrors, and allow such packages to use the BTS, what exactly does removing SC §5 buy us? I'd think that would do more harm than good, because while we would say we're not supporting such software, we'd still provide infrastructure for them. That's a worse message than accepting some people's need for non-free. So, the only way I could see the drop of SC §5 as a worthwhile goal, is if we also removed non-free (and possibly contrib) too. Unfortunately, I do not think we're quite there yet. But - in the long run - it would be a worthy goal to pursue. -- |8] signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2015: Call for nominations
I hereby nominate myself for the forthcoming DPL election. -- |8] signature.asc Description: PGP signature
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
> "Aigars" == Aigars Mahinovs writes: Aigars> If you do not liek where Ian is coming from with his point of view - Aigars> do not argue with him. Argue with other people. Or, better yet, argue Aigars> with the facts. This sounds awfully similar to "Don't feed the trolls", and we've seen how well that works (it doesn't). -- |8] signature.asc Description: PGP signature
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
> "Josh" == Josh Triplett writes: Josh> For the sake of clarity, I'd like to point out that I didn't start this Josh> thread solely because of a single IRC log, but rather because of a Josh> pattern of behavior over the last year that shows no signs of Josh> changing. Regarding the pattern: see the the CfVs[1][2][3] called in extreme anger, back in February. Those show a similar pattern. Concerns were expressed back then (including contacting the DPL and DAM), but apparently, nothing of substance changed since then. [1]: https://lists.debian.org/debian-ctte/2014/02/msg00344.html [2]: https://lists.debian.org/debian-ctte/2014/02/msg00353.html [3]: https://lists.debian.org/debian-ctte/2014/02/msg00355.html -- |8] signature.asc Description: PGP signature
Re: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy writes: > Here is the text: > > --- > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the question > has already been resolved and thus does not require a General Resolution. > > --- Seconded. -- |8] pgpzyCI9JnbfH.pgp Description: PGP signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna writes: > I would like to propose the following amendment proposal, > and I hereby call for seconds. > > ** Begin Alternative Proposal ** > > 0. Rationale > > Debian has decided (via the Technical Committee) to change its > default init system for the next release. The Technical Committee > decided not to decide about the question of "coupling" i.e. whether > other packages in Debian may depend on a particular init system. > > This GR reaffirms the Debian Social Contract #4, in such a way > that Debian acknowledges the choices made by both the software > developers (also known as upstream developers) and the Debian > package maintainers to provide the best free software to our users. > > Upstream developers considering specific free software (including, > but not limited to, a particular init system executed as PID 1) > fundamental to deliver the best software releases, are fully entitled > to require, link, or depend on that software, or portions of it. > > Debian maintainers' work is aiming to respect the Debian Social > Contract, in such a way to provide our users the best free software > available. > > Debian maintainers are fully entitled to provide modifications to > the free software packages they maintain as per DFSG #3, if they > judge this necessary to provide the best software releases. > On the other hand, Debian maintainers are fully entitled to adhere > to upstream's decisions to require, link, or depend on specific free > software (including, but no limited to, particular init system executed > as PID 1), if they consider it necessary to prevent delivering broken, > buggy, or otherwise incomplete software packages. > > The Debian Project states that: > > 1. Exercise of the TC's power to set policy > > For jessie and later releases, the TC's power to set technical > policy (Constitution 6.1.1) is exercised as follows: > > 2. Specific init systems as PID 1 > > Debian packages may require a specific init system to be executed > as PID 1 if their maintainers consider this a requisite for its proper > operation by clearly mark this in package descriptions and/or > by adding dependencies in order to enforce this; and no patches > or other derived works exist in order to support other init systems > in such a way to render software usable to the same extent. > > 3. Evidence of defects (bugs) > > We strongly reaffirm Debian maintainers are not deliberately hiding > problems (Social Contract #3). No technical decisions shall be > overruled if no proper evidence of defects, issued in the Debian Bug > Tracking system, is found. Fear, uncertainty, and doubt are not > considered as evidence of defects. > > This resolution is a Position Statement about Issues of the Day > (Constitution 4.1.5), triggering the General Resolution override clause > in the TC's resolution of the 11th of February. > > The TC's decision on the default init system for Linux in jessie stands > undisturbed. > > However, the TC resolution is altered to add the additional text above > in sections #1, #2 and #3. > > ** End Proposal ** Seconded. -- |8] pgpVgi48kMiV7.pgp Description: PGP signature
Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain
Luca Falavigna writes: > I'd like to draft an alternative proposal to the GR. > Would anybody consider it a nice addition to the proposals we > currently have, and eventually second it if I asked for it? I'd second this proposal. -- |8] pgpd8kf_TBaYa.pgp Description: PGP signature
Re: How should we deal with bad maintainers?
Raphael Hertzog writes: > assume that a package maintainer is active but is doing a bad job > regarding our standards (things like ignoring problems in stable, breaking > backwards compatibility for no good reason, not packaging new upstream > versions in unstable, etc) and is not really cooperative (closing bugs > hastily, not responding to help offers). > > What shall we do in those situations? > > Best case, I'm very motivated and I hijack the package but assume that I'm > just interested in having a working package because it's a dependency of a > package that I use but that I don't care enough to take it over. What are > my options? On a similar topic, a couple of years ago, there was an effort to set up a salvaging process. Not quite for the situation Raphael describes, but somewhat related. My question to both candidates would be: what's your opinion on salvaging packages? If favourable, what do you think, could move it forward? -- |8] -- 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/8738i21xx9@balabit.hu
Withdrawing my nomination
Due to unexpected events, my plans and life got turned upside down (for the better) in the past few days, and because of that, I have to scale down a number of things. Unfortunately, running for DPL is one such thing. However unlikely my winning would be, it would be dishonest from me to continue running while I'm fully aware that I would not be able to fill the role. Therefore, after a lot of thought, I'm withdrawing from the Debian Project Leader elections of 2014. Apologies for any extra work and problems I have caused, and may be causing with this. -- |8[ pgpFgcSxOX9_X.pgp Description: PGP signature
Re: Debian Project Leader Elections 2014: Call for nominations
I hereby nominate myself as a candidate for the 2014 DPL election. -- |8] pgpPLYFFD5GpK.pgp Description: PGP signature
Re: [all candidates] Removing or limiting DD rights?
gregor herrmann writes: > On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote: > >> On 25/03/13 at 16:22 +, Steve McIntyre wrote: >> > Are we strict enough with our existing contributors? When we're trying >> > to work together as best we can to make the Universal Operating System >> > happen, what could/should we do with contributors who hinder our work? >> > Sometimes that hindrance is inadvertent, sometimes it seems >> > deliberate. At other times it looks like we have developers who are >> > just not paying attention to what they're doing or who just don't care >> > about the goals of the project. > > Thanks for this question, which I would like to extend a bit. > Im my understanding you are pointing to unconstructive behaviour > related to technical work. What we also see (and discuss) every now > and then is behaviour that is socially questionable or clearly > unacceptable (from disrespect for peers to blatant abusive language). > > I guess we all remember such examples, which have led to > demotivation, frustration, hurt feelings, and have driven > contributors away. Indeed, I do remember. But - like Moray - as far as I see, this happens fewer times than it did in the past, at least on the most public lists (it does happen nevertheless, especially in those long threads we all know and "love"...). This being less of an issue than it was a decade ago, is good. There's certainly room for improvement, nevertheless. >> One small thing that we could improve on is earlier official >> communication. For example, in case of seriously problematic behaviour >> that could eventually lead to censure or expulsion, official warnings >> could be issued to the DD, and Cced to -private@. In some cases, that >> could help the DD realize that s/he needs a behaviour change, and also >> limit the surprise effect if/when a final decision is taken. > > What other ideas do you (plural, for all candidates, in case you see > the necessity to improve the handling of "social problems") see as > viable? I'll answer your specific answers first: > Examples that have come up in the past and might or might not be > helpful: > - Encourage everyone to chime in when they see potentially > unacceptable behaviour? In public/private? The problem with this is that multiple people independently chiming in has the tendency to make things worse. A more coordinated effort would help that, and if we had single coordinating contact point to help, that'd be great. (These do exist, owner@bugs.d.o and listmaster@, as Don mentioned earlier, but I am as of yet, unsure whether they're used this way, and how often.) I would encourage chiming in privately, and in a coordinated manner, with a single statement publicly, to discourage others from public flaming (and instead, point them towards the coordinated effort). > - Should we try to establish a Code of Conduct for project members? > Cf. https://openhatch.org/wiki/Project_codes_of_conduct for > examples. > If yes, how would we do this, and how could we make sure it gets > respected? > - Could the CoC for mailing lists > (http://www.debian.org/MailingLists/#codeofconduct) > be used as a starting point / be extended? > - Or Enrico's Debian Community Guidelines? > http://people.debian.org/~enrico/dcg/index.html I'm not a terribly big fan of Codes of Conduct, because they're vague and very, very general, and as such, subject to interpretation. What I would consider a flame, or common sense may be much different than someone else thinks. I've grown up on IRC, and frequented channels where foul language and flames were a daily show (and I'm not ashamed to admit, that I enjoyed these, one could learn a lot about how not to behave, and what triggers a flame. I found it very educational at the time.) Enforcing the CoC is also quite a big task. However, there's one good thing about them: they send a message, that we're serious about caring about and nurturing our community. For that reason alone, a CoC is worth it. I do like Enrico's guidelines though. Something along those lines, and the mailing list CoC would make sense, in my opinion. Perhaps both! A CoC, a short, generic code, and the Guidelines, for more in-depth suggestions. The Guidelines would be treated only as such, though - guidelines, not enforcable, but a reasonable basis of peace talks. > - Another recurring topic is the Social Committee, cf. e.g. > https://lwn.net/Articles/221077/ (or the ombudsman team mentioned > in the article: > https://lists.debian.org/debian-project/2007/01/msg00101.html ) > Would such a body make sense? With which powers? I would find such a body useful, but not in the way it is explained in Gustavo's mail (there's quite a few things I disagree with, like a public pseudo package in the BTS for the task). As for powers - I would not wish to grant the body any particular power, but rather, ask them to channel issues to the DPL, and they together would decide how to proceed, wit
Re: [all candidates] What to do with debian-private ?
Charles Plessy writes: > If this has not changed, is that something that the DPL candidates would > like to tackle ? (Bonus question to the DPL candidates: are you subscribed > to debian-private ?) Private is like it always was (I am subscribed, and have been for every day of my DDship). Fortunately, modern mail clients can mark a whole thread read, so if the subject is not interesting, it's just a button away, and the whole thread disappears. And if I don't read it, it's not hard to keep that information private, whether it belonged to -private in the first place, or not. As such, whatever goes on on -private, it doesn't really bother me. The traffic is low enough to handle. (But then, I'm subscribed to -bugs-dist@ AND lkml, so my definition of low may not be shared by most.) Nevertheless, I have no intention of trying to change how -private@ is used. I could imagine ways to make it more useful, but I don't see the effort being worth the trouble. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762087fi6@galadriel.madhouse-project.org
Re: [to all candidates] Free Software challenges and Debian role
Lucas Nussbaum writes: > (I still hadn't replied to that question -- I'll do that by following-up > on Moray's reply since I agree with most of it) ...and I'll take the easiest route, and follow up on Lucas' mail, since I mostly agree with both of them. Sorry! > On 12/03/13 at 17:11 +0300, Moray Allan wrote: >> [...] >> >> - End-users are moving to web applications/"the cloud". Few of the >> most heavily used ones are free software. Even if they are, >> centralised web applications remove users' ability to modify >> software to their own needs unless they duplicate a large amount of >> infrastructure. And in many cases cloud services reduce users' >> control even over their data itself, not just over the platform. We >> used to have trouble with the network effect of e.g. Microsoft >> Office file formats, but free-of-charge web applications can be even >> worse for free software, since objectors need to argue an >> ideological point to say why they want information in another way, >> rather than only explain that they haven't bought that piece of >> software or that it won't work on their OS. >> >> - Server users are also migrating to "the cloud". In many cases >> this means that their services move to sit on a non-free platform, >> and it often reduces ease of modification even in free parts of the >> platform. > > Note that in that case, the cloud is also a great opportunity for us, > since most IaaS clouds users use them with free software. So the Cloud > tends to reinforce the position of libre operating systems for server > OS. While the cloud is a great opportunity for us, as Moray said, quite often, we'd sit on top of a non-free platform. I usually put this under the same label as non-free hardware, because hardware is being replaced by virtualization - but the setup remains fairly similar. I'd add two more things I see as an increasing risk for free software in general: One is code dumps, where the software itself may be free, but development behind it is not, when vendors abide the letter of the license, but not the spirit. That is something that is becoming more and more common, and I find that very worrying. Not only because it does not follow the spirit of free software, but because it makes it much harder to contribute and work with the software in question. I can easily see it alienating people, who'd otherwise become part of the larger free software community. Not only does it not follow the spirit, I believe it actively works against it. The other issue I see is bundling (often patched) third-party libraries. That is hard to untangle, makes security support a nightmare, and has all kinds of negative side-effects. All that to make it slightly more convenient for vendors, who never really learned how to work with free software. (This also applies to careless find & sed forks, though those are thankfully much rarer). There's quite a lot we could teach them there, and the world would become a much better place. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9pl7pz8@galadriel.madhouse-project.org
Re: to DPL candidates: getting new people to Debian
Gunnar Wolf writes: > Gergely Nagy dijo [Sat, Mar 16, 2013 at 01:32:32PM +0100]: >> Debian is also not impressively different, so to say. We have a distinct >> culture, we have great technical solutions, but those are hardly enough >> to impress someone who just casually looks. We need to reach out and >> show them that there is much more under the hood than they may imagine, >> that we can, and we do provide something unique. >> >> And we need to impress them. That's a very, very hard thing to do, and >> something that we'll need lots of help to accomplish, and not >> necessarily from technical folk. (Which is why one of my primary aims is >> to reach and and recruit non-technical contributors to Debian.) > > How would you suggest "impressing" them? A new, shiny user interface > is not what it takes, or at least, not all it takes. We have packaged > *great* user interfaces for a very long time. Even other Linux > distributions, aimed at the desktop, have given a lot of extra shine > and polish to their UIs, someof them (i.e. our derivative Ubuntu) > developing completely new frameworks, targetted IMO to touch-devices, > which are all the rage now. And I still cannot say it impresses or > dazzles newcomers. It's not the UIs I would focus on - everyone is doing that, and it's never going to be really impressing, in my opinion. Impressing anyone with technical gizmos is hard, and most often, only possible when they were interested anyway. We're not going to reach too many people that way. How we can reach a lot more - see the end of my previous mail. The stories we can tell, the achievements we can show, our entire culture is something that noone else can show. These are *very* impressive things, we should be proud of them, and we should use them as part of our recruitment too. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hajt7tgy@galadriel.madhouse-project.org
Re: [all candidates] delegation
Gunnar Wolf writes: > However, this topic does raise a question: Knowledge transfer. I might > be arguing on something marginally related to the vote at hand, but > anyway, when delegations shift (be it due to burnout, retirement, > rotation or whatever), we should make it as easy as possible to > transfer the acquired knowledge from the ex-delegates to the new > delegates. Yep, agreed. In some teams, there's the "wizard" role, someone who isn't all that active anymore, but there's knowledge in his head, and he's willing to share it. I find this a great way to not loose the knowledge, while still allowing someone to move on. > Writing documentation is often seen as a boring, painful task. Yet, it > is a very important thing to do. So, prospective DPLs, would you see > as part of the delegation the requirement for outgoing (if possible, I > know it's not always the case) and incoming delegates an obligation to > check and update documentation with the latest practices? I'd encourage it, yes. But would not make it a strict requirement. I value hands-on training more than written documentation in many cases (esp. when it comes to using and working with our own tools), and in that case, if I'd have to choose whether to encourage the aforementioned wizard role or writing/updating docs, I'd go with the former. This should also apply to DPL transitions, by the way. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obe27db3@galadriel.madhouse-project.org
Re: [all candidates] delegation
Thomas Goirand writes: > On 03/26/2013 09:28 PM, Gergely Nagy wrote: >> I see >> Zack's DPL helpers initiative as a step in this direction, and I'd like >> to take it a little further. > > How? Make it formal? Have new "official" positions? Or just push more > people to help and that's it (which is ok too...)? I was primarily thinking about shorter term, formal delegations, for one particular task. And of course, promoting the idea further, encouraging people to participate. (Which will likely need more and better communication) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8b7sb9@galadriel.madhouse-project.org
Re: [all candidates] lack of women in Debian
Mònica Ramírez Arceda writes: > I would like to know your opinion about this graph (thanks Francesca!): > http://blog.zouish.org/posts/dw/ > > Note that I'm not asking for a way to recruit women (there are already > efforts on that). I would like to know if you think that this lack of > women affects (or not) the Debian project and how. I'm both happy and sad about the graph. Happy, because it shows improvement, sad, because it doesn't show enough of it. Though, I'm hoping that if we had better tracking, if the graph would include translators, doc writers, event organisers and all kinds of other contributions, the curve would be much nicer. I'm also afraid that this is just a hope at this point. Nevertheless, the lack of women does affect Debian, and not in a good way, but, as you wrote, there are already efforts to recruit more women (with the recent announcement of participating in GNOME Outreach Program for Women[1] is something I was very happy to hear). [1]: https://lists.debian.org/debian-women/2013/03/msg00013.html Diversity - be that gender diversity or any other kind - is in general something to strive for, something that benefits us greatly in many, many ways. So having so few women within the strictly viewed project is worrying. > I also would like to know if you have any proposal related to this topic > that you would like to do if elected. Improving our recruitment strategy and our outreach efforts are core parts of my platforms, and these naturally include efforts that specifically target women. However, I do not (yet) have any specific plan (related to the topic of women in Debian) in mind, that would be different from efforts already in motion. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjxp6jwj@galadriel.madhouse-project.org
Re: [all candidates] on distribution-wide changes and scalability
Stefano Zacchiroli writes: > Folklore goes that performing distribution-wide changes in Debian is > hard and time-consuming, due to a couple of reasons: (1) the time needed > to make a decision that affects the whole archive (this is related to > our flat structure, which has many benefits, but surely not that of > providing a clear decision structure for cross-cutting concerns), and > (2) the time needed to deploy the needed technical changes in all > affected packages. It is, indeed hard and time consuming. I do not neccessarily see that as a problem, but see below. > This "inertia" folklore is surely supported by past history of the time > it took us to deploy specific changes in large sets of packages. But on > the other hand, in the last 5 to 10 years we have massively improved our > ability to decide and deploy large changes by the means of: (a) large > maintenance teams who are able to decide on "their" packages and deploy > changes using shared-access VCS, and (b) a more liberal use of NMUs than > in the past. > > Questions for the candidates: > > - on the judgement spectrum between "there is no inertia in Debian and > that's good" and "there is a lot of inertia in Debian and that's bad", > where would you put yourself? On both sides, of course, and sometimes somewhere inbetween. We've seen cases where we had inertia, and turned out it was useful. We've seen others where it turned out to be a bad thing. So it really depends on the context. > - if you don't think that we're at our best on this front, what do you > propose we change to improve? (See below, but keep the above statement in mind.) > As mere thought experiments, feel free to consider the following > possible "changes" as part of your answers: > > - Debian should use the Technical Committee more proactively than we > presently do, to decide on "any technical matter where Developers' > jurisdictions overlap"; not only to solve conflicts (as we already > do), but also to *design* forthcoming changes in an authoritative > manner. [ Many large FOSS projects out there have technical boards > that work that way. ] Involving the tech-ctte earlier may be a good idea, but pushing the task of designing forthcoming changes onto them, even if done in cooperation with the other parties involved, is not something I'd push for. I see the tech-ctte more as a decision making body, or a technical mediator, than an entity that designs change. Getting the tech-ctte involved more often, not only as a last resort can have benefits, but then we need to make clear that we expect help, and not neccessarily a solid decision. (FWIW, Constitution 6.1.5 already grants the tech-ctte to offer advice, we should exploit this power more often, and more pro-actively.) > - Debian should decide to use a single VCS (say, Git), for all packages, > uniform repository structure and work-flow, and give by default > read/write access to all DDs. This would allow push-button changes to > all packages in the archive. We often speak about "reducing package > ownership" during DPL campaigns, well, this is the ultimate step of > it. [ Ditto: I know no other large FOSS project out there allowing > the extreme diversity in VCS, work-flow, and ACLs that we have in > Debian at present. ] No. Most definitely no. There is *no* structure, nor workflow that fits all packages and all packagers, trying to force one down our throat would be counter productive. While this would certainly have advantages, I find the costs too high: - Adapting to a single repository structure can be needlessly painful (esp. when you need to adapt the upstream structure too) - Settling on a single VCS is not going to happen, ever. - Sometimes it is more convenient / straightforward to use the same VCS upstream uses (which may or may not be git). (Especially when one is upstream) - Sometimes one is maintaining the same package for not only Debian, but derived distributions aswell, which use or prefer another VCS. Trying to force the hand of our downstreams this way is not productive, in my opinion. - There is no workflow that fits all scenarios. Trying to shoehorn everything into a simplified view is just going to hurt in the long run. - People are people, they're hard to change, and in a purely volunteer based project, that has a long history of giving pretty much free hand to the maintainers as long as they comply with policy and some amount of common sense, moving towards a more controlled environment by force is bound to cause quite an uproar. (I've worked with BSD ports/pkgsrc for quite a while, where there is a single VCS, a uniform repository structure, and pretty much one canonical workflow. It was horrible. So very inflexible, it was a pain to adapt things that weren't designed with that particular layout & workflow in mind.) I'm all for encouraging putting packages under collab-maint or team maintai
Re: Debian for third party (read: propietary) apps/vendors
Lisandro Damián Nicanor Pérez Meyer writes: > There are third party vendors (read: propietary) that support the > installation > of their software in Debian, but mostly because selfish reasons: they need to > be present everywhere for their business model to work. A clear example of > this is Skype. Most proprietary packages exist for the same reason: there's demand for it, demand that can be turned back into money. Very few (if any at all) proprietary vendors package up their software for distributions just to be nice. > Now there is a second class of apps/vendors which do not need to be ubiquitous > for their business model to work. Most of the examples that come to my mind > are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of > propietary vendors that give support for Linux but just on Red Hat and > sometimes, Suse. And they are a PITA to make them work on Debian. This makes > IT workers need to have RH/Suse/CentOS boxes even if the rest of them run > Debian. [...] > Now my question is: without going against the Social Contract, is there > anything Debian can/should do wrt this situation? The difference between Debian, RedHat and SLES (SUSE Linux Enterprise Server) is that there's commercial support behind the latter two, there's a company where vendors can turn to if they need support. There's no such entity behind Debian. There are companies that do sell Debian support, but that's not quite the same. This status quo means that vendors rarely invest into preparing Debian packages, because only a very small percent of their users are running Debian (due to their business requiring support contracts from the vendor, which is much easier and straightforward to obtain in the RHEL/SLES cases, for example), and investing into making proper Debian packages is simply not worth it. As such, there's nothing Debian can or should directly do. On the other hand, we have downstream distros where the parent company does provide similar support guarantees that RHEL and SLES do. If third party vendors start creating packages for these distributions, that may very well make it easier to run said software on Debian too (like how the RPMs are often run on CentOS instead of RHEL). This would help Debian users who, for some reason, need to run said proprietary software. But even then, I would not wish Debian to go to great lengths to accomodate non-free software. We should not make it unnecessarily hard, either, but that's about it. If vendors don't provide Debian packages, there's nothing we - as a project - can or should do to change that. We're not the users that matter for the vendor, we're a target platform, and it's not the platform that matters, but whether there's enough users to make the effort of supporting the platform worth it. (It's not like it's hard to make debian packages. It most definitely is not. It isn't particularly hard to support Debian stable, either [my employer provides packages for one of our propriertary tools for Debian Sarge(!) too, it's not terribly hard].) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v5a899d@galadriel.madhouse-project.org
Re: [all candidates] delegation
Thomas Goirand writes: > One of the key role of the DPL is to delegate. > > What are your intention in this regard? Do you think that the current > teams and roles are well filled? Or would you like to change some of the > people currently holding a position? Why (not) changing anything? I believe that the current delegations are well deserved, if elected, I wish to reaffirm people currently holding a position (unless they wish to step down, of course). On the other hand, most of our teams are lacking manpower, which is something I would like to improve. To remedy the situation, I'd need to learn a bit more about the various teams than I was able to while peeking in from the outside. I'd like to think that we have quite a bit of manpower to spare, we just need to aim them at the right team. Or if that fails, improve our recruitment to make joining the teams lacking manpower most more appealing, and more rewarding. In some cases, likely more visible, and better defined too. I also plan to delegate more tasks, to make the DPL job sustainable in the long run. These would include representational tasks just aswell as organising things on behalf of the DPL, and so on and so forth. I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2um8f49@galadriel.madhouse-project.org
Re: [all candidates] Removing or limiting DD rights?
Steve McIntyre writes: > Are we strict enough with our existing contributors? When we're trying > to work together as best we can to make the Universal Operating System > happen, what could/should we do with contributors who hinder our work? I do not believe we're strict enough, not in general. On the other hand, I'm not a big fan neither of overruling DDs, nor of limiting them. I'll explain below. > Sometimes that hindrance is inadvertent, sometimes it seems > deliberate. At other times it looks like we have developers who are > just not paying attention to what they're doing or who just don't care > about the goals of the project. Occasionally we see direct action to > censure or even expel DDs, but these are only ever in the most blatant > of cases. By the time that happens, large amounts of damage may be > done to the project: delayed releases, lost users, loss of motivation > for other contributors. > > I'm wondering: is this something that you think is a real problem, and > if so what do you think we could do about it? The worst case (when it comes to expelling or severely limiting a DD) is fairly rare, and I certainly hope it will stay that way (and we really should not let things get that far). However, causing damage (due to negligence and/or lack of attention) is far more common, and is a real problem, one we should be dealing with much, much better. The salvaging effort was/is something that gave me great hopes, because it approached the problem from a less personal angle. The less personal an effort is, the more successful it can be in this case, as far as I see. Telling people they're harming the project is a lot different than telling them that a particular package needs more love, and then going ahead to aggressively hug said package to give it more love. I think the salvaging idea is something that we should push forward with, aggressively. While this is not a solution to every problem, it would help in quite a lot of cases. How well this works, also depends on the people involved, so great care must be taken to avoid as many bruises as possible. (But not at the expense of dropping it alltogether and doing nothing! Better some bruises and a handshake months or years later than silently holding grudges forever.) But alas, salvaging will not solve everything, and in some cases, it is likely not an option either. In those cases, we should not be afraid of overruling the maintainer, and if need be, forcibly transfer the package to someone else. Yes, this would also have consequences we'd rather avoid, there would be bruises, but if there's no better option, when all other kinds of negotiations failed, then I see no better option. Negotiation is something we should perhaps be practicing more, and earlier. In short, we have the procedures to completely revoke or severely limit DD powers, but this is a power we should exercise rarely. Instead, we should work towards discovering problems much earlier, and work more aggressively towards resolving them, before more harm's done. Among our tools to help with this quest, we have salvaging, and once a problem's discovered, earlier negotiation attempts, possibly involving the DPL as a mediator. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hajy8g4s@galadriel.madhouse-project.org
Re: [all candidates] Return to the desert island (cont.)
Bart Martens writes: > On Wed, Mar 20, 2013 at 09:27:58AM +0100, Wouter Verhelst wrote: >> You can use flashplugin-nonfree to download a piece of software that has >> a nonfree license, which is then installed on your system; the result is >> that you now have a system which has some non-DFSG-free software >> installed. To be able to reach this situation on a system that only has >> "main" enabled would be utterly wrong. >> >> You can use pidgin-facebookchat to talk to a non-free service; but >> whatever you do, the result will *never* be that you end up with a >> system which has some non-DFSG-free software installed. As such, I don't >> think it's necessary that you not be able to reach this on a system that >> only has "main" enabled. > > OK, you seem to draw the line where non-free is installed or not on the local > system. That makes somewhat sense to me. But then the part "which require > software outside of the distribution to either build or function" in > debian-policy should be replaced by something like "which causes software > outside of the distribution to be installed on the local system". What one uses a particular piece of software for, to access a non-free service or anything else, is none of our business. Is it sad that non-free services exist? Yes. Is it bad that we have free software in main, that allows users to extract their data from these services? Definitely not. Is it bad that we have free software that allows users to communicate with non-free services? Nope. We have plenty of software in main that allow things like this, and that's a good thing. Our task is to allow our users to get things done. As long as the software we distribute is free, it does not matter much whether it requires a non-free service or not - we do not distribute the service. By installing software that talks to a non-free service, the system remains Free, that's where our jurisdiction ends. We can, and we should encourage using free services, but whatever a particular software talks to, does not affect its classification according to the DFSG. The whole cloud stuff is a whole different can of worms. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li9b8y7l@galadriel.madhouse-project.org
Re: [all candidates] lack of women in Debian
Lucas Nussbaum writes: > On 19/03/13 at 21:43 +0100, Gerfried Fuchs wrote: >> * Lucas Nussbaum [2013-03-19 07:44:32 CET]: >> > But it's also about how we see our project. I would like Debian to be >> > a very welcoming project, and I hate the fact that it's harder for some >> > groups to get involved. >> >> Given that the context of this statement is "lack of women in Debian", >> why do you believe that it's harder for women to get involved? > > Let's split the process of getting involved into several steps: > > Step 0: Alice knows nothing about Debian > Step 1: Alice is "exposed" to Debian > Step 2: Alice would like to contribute to Debian > Step 3: Alice starts contributing to Debian > > Going from Step 0 to Step 1 is less likely for women, because there are > fewer women in situations to be "exposed" to Debian (studying CS, IT > jobs, etc.). And there's not much we can do (as Debian) for that. I would like to strongly disagree here. Getting involved in, and contributing to Debian does not require one to be anywhere near CS or IT. It certainly helps, because we, as a project, are far better prepared to receive and encourage such contributions, but that's not all there is to it. There are many ways to reach out to non-technical people too (including but not limited to friends, partners, family and various non-technical events), and we as a project can and should encourage this kind of outreach too, and not limit ourselves to technical contributors only. (Also, not being in a position to be naturally exposed to Debian does not mean that one wouldn't become a technical contributor later on.) > Going from Step 1 to Step 2 is also less likely for women, because the > prospect of getting involved in a project with so few women might be a > bit frightening. Agreed, but there's a lot we can do here to make it less so. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqsy8euy@galadriel.madhouse-project.org
Re: [all candidates] discussions in -devel
Serafeim Zanikolas writes: > In the words of Lars [*]: > > We're not very good at dealing with situations where a few individuals > are dominating the discussion by being loud, insistent, and unwilling to > budge > or to give any credence to opposing views. I don't know what to do about > that, > but we clearly need social and possibly technical tools for this. > > According to Lars, behind the scenes diplomacy is not sustainable. It seems to > me that the only way to solve this issue effectively is to make trolling > harder (requiring more effort) than ending it. My impression so far, is that trolling isn't all that common. Ignorance and unwillingness to compromise are much more common (combine it with all parties showing signs of these, and the high amount of traffic, and things will blow up very quickly). The problem is, whatever technical solution we come up with that makes trolling and other misbehaviors harder, will make normal discussions harder too, and that is not something I'd like. > Our usual approach of darwinism (whereby a single hacker's solution gets > gradually adopted) does not work here because any attempted solution (social, > technical or both) requires some kind of upfront policy change (and, for > technical measures, some kind of infra change). > > How do you propose that we go about dealing with this issue, keeping in mind > that it's imposs^Wchallenging to get to consensus about non-technical and > potentially controversial policy (moderation) changes? Unlike Lars, I believe in behind the scenes diplomacy, but perhaps that would need a bit more coordination: a handful of people attempting it uncoordinated may have undesirable results. At other times, it is simply impossible to stop a thread from blowing up, no matter how many people you throw at the task. At these times, it would help if we had a way to close down threads for a short amount of time (ie, anything that shares the same subject, or references any message within the thread would be held for moderation, or simply dropped). A reasonable rule of thumb seems to be: "If it is more than 8 levels deep, or the thread has more than two dozen mails within the first 48 hours, it will be going nowhere." But that's just an idea, and not a terribly good one, either. I much prefer one of Lars' suggestion: "Real-life meetings between participants. Debconf, sprints, FOSDEM, other such conferences. Unfortunately, this is expensive, and we can't reach everyone." Granted, that may not always be an option, but in many cases, I believe it would work remarkably well. When a thread escalates and goes terribly wrong, we can approach the involved parties behind the scenes, and propose a real life meeting to resolve the issue. It's better for them, better for us, and it needs preparation, so their energy will go into gathering their thoughts instead of echoing the same things over and over again to different people in the same thread. Not everyone needs to be present at these meetings - perhaps there will be times when the worst offenders won't even be there. But that's no problem either, as if we get everyone else there, there will be noone to feed the troll, either. In short, I support real-life meetings to resolve these kinds of issues that we usually see escalating, I'd prefer this over (moderation) policy changes or technical workarounds. But if it comes to that, we should not be afraid of working around social shortcomings with technical roadblocks, either - at least temporarily. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ng29v0x@galadriel.madhouse-project.org
Re: [all candidates] Advertising testing and security support
Jérémy Bobbio writes: > Dear candidates, do you think it would be wise to advertise `testing` as > a usable distribution to our users given that state of affairs? Given > that our security support for stable is already not as best as it could > be, do you think we should encourage volunteers to be more active in > security support for testing? First of all, our security team is doing an excellent job, considering the amount of work required and how few people they are, their response time and the quality of work they do is very high. Could it be improved? Yes, of course. With enough manpower at our disposal, we could pro-actively search for and find security issues! But we're nowhere near that, nor should we be, I believe. As for advertising testing: for some uses, we should, yes. But without security updates managed by the security team, those uses are fairly limited, and the consequences must be kept in mind. This makes it hard to make a good case for testing. If we'd have enough manpower to handle security updates for testing aswell (either via unstable, or through other channels), that would help tremendously. Not only our users, but our maintainers would have it slightly easier too. Therefore, I find it a commendable task to encourage volunteers to work on security support (be that for stable, testing or otherwise). > Do you have ideas on how to attract more volunteers to the dull, hard, > and sometimes boring tasks of taking care of security issues in > Debian? Realizing that the task is neither dull nor boring would be one step. It is hard quite often, though. I do have a couple of ideas (shamelessly borrowed from my former boss, who convinced me to work at the support department instead of development), but these may present more problems than what it solves, at least initially. You see, preparing security releases is a complicated task, one that requires a good knowledge in a number of areas: packaging, security, a multitude of languages, upgrade paths, and so on and so forth. It requires a particularly diverse set of skill. That is also that makes it so very interesting (even entertaining, in some respects). There aren't many people who have the diverse knowledge required, and even less who are willing to sacrifice their time to do work that's mostly invisible. To attract more people for the task, we first need to recognise the importance of it, we need to be *proud* of the people who are already doing it. And then, we can encourage volunteers to help out, and existing members to mentor them. One of the hardest parts is this, the mentoring part (due to time constraints and an already high load, just to name two issues), but perhaps we could persuade former members of the security team to take on this role? If one can learn a lot about software and security, when there's someone else to mentor, that makes it - in my experience - a lot more appealing to volunteer, than being thrown into high waters, and hoping one can swim. Having a very, very diverse set of skills can also help one at his or her day job (it certainly helped me), so being part of the security team is easily a good way to further advance one's own career. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v5e9wh1@galadriel.madhouse-project.org
Re: [to all candidates] Accessible software in Debian
Hi! Mario Lang writes: > I'd like to know your opinion on this. Are people with disabilities > something that we want to support, or is it just luck if "they" get a > working system. As a Free Software community, should we make sure that > the digital divide is not going to increase, or is accessibility just > margin topic which we as a community do not really care about? Accessibility is more important than most people realise, yet, it is also a very hard thing to get right when one has a hard time imagining how accessibility features would be/are used by the people they were designed for. My experience is that until you *had* to use a system this way, you'll just be poking around trying to accidentally get something right. So the lack of manpower in the field hurts even more than the lack of it elsewhere. > If you think we should make sure to provide maximum accessibility to our > users, do you have any idea what to do to ensure that? I'm not sure we can ensure anything - not within the scope of a volunteer project. What we can do, however, is making damned sure that accessibility is cared about. I believe many people would like to support accessibility in their projects much better than they do now, but without enough manpower, it's not going to happen soon. They need people who understand accessibility, who can test the software, or tell whether an idea is useless from an accessibility point of view or not. We need better communication, and more people motivated to help. I do have a couple of ideas how we could attempt to motivate - but we must keep in mind, that in the end, we do not want accessibility to be a Debian-only development, we want to take the task upstream. (If it originates from Debian, if we 'lend' our human resources to upstream, that's great, but whatever we come up with, has to go upstream.) > Do you have any ideas what we could do to raise awareness of > accessibility issues, and maybe motivate developers who are currently > not into accessibiility work in any way, to start caring about various > issues around accessibility for people with disabilities. I do have a couple, yes, but I don't want to sound extremely stupid, and would rather consult with someone who understands accessibility first, before I write down the ideas. Nevertheless, the basic driving force behind my ideas is positioning accessibility as an area where work is in high demand, is very rewarding, and can be learned. How? Meet with people. Tell people. Show people. For example, an accessibility workshop at DebConf would be a reasonable way to gather feedback from package maintainers, users within our developer community, and we could proceed from there. Furthermore, we have a thing called "Invisible Exhibition" here in Hungary, an exhibition of sorts, where the goal is to have a blind guide guide the visitors through the exhibition, in complete darkness, teaching them to rely on touch, hearing and smelling, and discover the world of the blind, first hand. They're shown and taught situations, simple things like paying for a cup of coffee at a restaurant. It is a very popular exhibition, and I think it's an amazingly useful one too. We could adapt a similar idea, and have sessions at the Debian booth in various conferences, teaching visitors how people with accessibilities use computer systems (and Debian in particular). I've seen blind people work with computers, and I was astonished: they used it more effectively than I did. That was kind of a revelation, to be honest: why would *they* be disabled, when it is I, who is inefficient? Finding oneself in a similar situation is a real eye opener. We should open more eyes. We have a fair number of people within the project who could help us with that, if elected DPL, I'd do my best to support them in doing so, even if, to open our eyes, we'd need to close them shut first. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2uu9zed@galadriel.madhouse-project.org
Re: To all candidates: which way out of the project ?
Charles Plessy writes: > In Debian, we stay member until we die or quit (or very exceptionally, are > expelled). The consequence is that it is hard to evaluate how much active > members we have. It may also create more crispations about giving membership. > > We often discussed about how to become a member, but more rarely about the > other side of it. I would be interested to read your opinion, especially on > the > implications that the current practice, or possible changes, have for the > project as a whole. Inactive members can also be caught red-handed by way of the MIA team, as Cyril and Lucas mentioned already. I belive we do not need any more exits than what we already have: * People can gracefully retire completely * People can opt to become Emeritus * People can leave the project by natural means * People can be expelled * People can become inactive and spotted via MIA, and dealt with according to the MIA policies. That's plenty of ways already, pretty much all bases covered. We should, perhaps, be a bit more aggressive with MIA checks at times, but that does not really need any big sweeping changes within the project. Right now, uncaught inactive members are not much of a burden, except for having an active account, with all of its security and other implications. Do you see a particular problem, or shortcoming, perhaps, that you'd like to see solved? -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3p2a0uj@galadriel.madhouse-project.org
Re: [all candidates] how to choose Jessie init system
Gergely Nagy writes: > Stefano Zacchiroli writes: > >> Some of the longest -devel thread in recent years have been about >> Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. >> Despite folklore, I don't think those thread have been (entirely) >> trollish, they all hint at a concrete problem: > > (For the record, it's systemd, not SystemD. Sorry!) > >> How do we make an inherently archive-wide technical decision when >> multiple, possibly equally valid solutions do exist? > > What I believe to be a solution in cases like this, is to sit down with > the stakeholders (preferably in person; a conference or DebConf would be > a perfect opportunity for this): maintainers of said systems, porters > (primarily kFreeBSD & Hurd folk), the security & release teams, and if > possible, upstream developers of the individual init systems too. I'd do > this behind closed doors, initially, because the number of arguments and > the level of noise needs to be controlled, and we've seen how well that > works on a public mailing list. Just to clarify: the intent here is not to lock people up until one emerges, that would be useless and counter productive. I genuinely believe that with the right people having a civil discussion can get results out the door in a reasonable timeframe. They just need some careful herding, is all. And face to face, that can be done - over the internet, nope. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4jb9ez8@galadriel.madhouse-project.org
Re: Debian's relationship with money and the economy
Hello, Raphael Hertzog writes: > The Debian ecosystem includes many economical actors, be it companies > or individuals, but we tend to hide those aspects as if they didn't > exist. Well, we have the debian-companies[1] list, we also have a partners page[2], and the debian-sponsors-discuss[3] list too (although this latter one may not be in the same category as the other two). [1]: http://lists.debian.org/debian-companies/ [2]: http://www.debian.org/partners/ [3]: http://lists.alioth.debian.org/mailman/listinfo/debian-sponsors-discuss So, no, I don't think we hide this information. Rather, in recent years, I've seen efforts towards the exact opposite. > Despite Debian's non-profit status, IMHO Debian's growth and success > relies on the capacity of those "actors" to have some "economical > success". And there are many ways to help those actors, without involving > any direct flow of money from Debian to them, in particular at the > press/publicity level. Perhaps. I'm not entirely convinced that most actors would need press/publicity from Debian. As far as press and publicity goes, I'd defer to our very own press team to do as they feel appropriate. Personally, I would not set up a general rule, but decide on a case by case basis, and leave it up to the companies (or any other for-profit organisation, project, whatever) to approach us would they believe that press/publicity from Debian would help them. They'll see this better, and I'm sure we'll be able to figure something out to benefit both parties. > When a project ultimately benefits to the Debian project, we should > not fear to promote it even if that promotion helps the project > initiator to make money (and IMO even more so when the project initiator > is a Debian member). I agree with this. How we'd promote said project is another matter though. I would not issue a press release in the general case, but... see above! Our press team is doing a great job, this is a task they excel at, and I do not want to intrude into their territory. > If yes, how can we shift our culture and our policies towards this goal? As I explained above, I would not want to set up a general rule, nor even a guideline. Not at this point yet, anyway. Rather, have these actors seek us out, and we'll come to a conclusion on a case by case basis. There's no hat that fits all, as the saying goes, especially when it comes to this topic. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738vrbbli@galadriel.madhouse-project.org
Re: to DPL candidates: How do you plan to represent Debian externally?
Paul Tagliamonte writes: > I'd ask the DPL candidates to speak a bit about how they intend to > represent Debian externally -- both in terms out downstream outreach, as > well as upstream (or even side-stream) relations. Like I expressed earlier, elsewhere, I believe that representing Debian is a task that can - and often should - be given to those most appropriate for the task. Who and why is most appropriate, depends on a lot of things, like availability, familiarity with the topic or audience, requirements coming from the organisers, and so on and so forth. That is to say, if elected, I will not be able to represent Debian on every front, nor do I feel that this should be expected from the DPL. What I would like to have, however, is sending the best people to represent Debian to events where they can do that best, no matter whether that event is downstream, upstream or even side-stream. (Of course, this does not mean I plan to hide behind a curtain, I do love the sound of my own voice, and I'm not afraid to use it either, when it is appropriate to do so.) > What sort of plans do you have to collaborate with other F/OSS > communities? Other distros? We, as a project, need to be more visible, more approachable. We also have a lot of people who do upstream work. These two things should be used to further our cause, to strengthen the bond between Debian and other communities. We should coordinate with and talk to our upstreams to make both our lives easier, and with downstreams too, for similar reasons. The less work each of us has to do, the better it will be for all of us, and our users. We have people among us who did great work in this area in the past, if elected, I'd encourage their continued effort, and count on their help too, to move things along. Perhaps we could even have Liaisons, or at least a dedicated contact point towards distros and communities, to make ourselves easier to reach, and the work more scalable. > Realtedly, what sort of messaging (on this topic) can we expect > from the future DPL? I plan to keep in touch with distros and communities we're already in touch with, and open channels towards others where we're not present yet. These channels should be nurtured, and ideally vibrant and active. As DPL, I would make it an important recurring task to review the state of our relationships with others, and step in if necessary - either to intervene and mediate, or to give a little push. As for representing Debian - if elected, whenever there's an opportunity to represent Debian somewhere in an official role, I would strive to find the most appropriate person, and encourage them to take on the task (or do it myself, if I happen to be the most appropriate one). Of course, all this would be done in a transparent manner, by way of delegating the task in the end. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gl3bddk@galadriel.madhouse-project.org
Re: [all candidates] beyond tech: how do you deal with humans?
anarcat writes: > You all have an impressive technical curriculum. Your deeds in Debian > speak for themselves. However, the role of a project leader is unusually > non-technical. In fact, you will have to abandon significant technical > tasks to tend to more "administrative" or "leadership" tasks the DPL > role requires. That I may have impressive technical contributions is something I tend not to believe. You see, even though I am a software engineer by trade, (which trade happens to be my hobby), my true passion lies with words and human arts. It's a twisted turn of events that my hobby supports my passion, and not the other way around. As such, leaving (some|most) of the technical stuff behind, and exchanging it for administrativa, mediation, lots and lots of communication, inspiration and all those things is not going to be something new. In various settings, I've had experience doing all that already. > Why are you good candidates for that role? What social skills do you > bring to the community in terms of mediation and leadership? I'm pretty darn good at mediation, did that both inside Debian (see an example shortly below) and outside of it. It is something I find challenging and satisfying, an area where I have had great success in the past, an area I find particularly interesting (people *are* interesting in general). I speak, I teach, I coach regularly on various topics (Debian included, of course), other times, I use a handful of magic dust, and make things simple. On other occassions, I evangelise. One of my fondest moments of recent years were hearing these words - said very quietly under her breath -, by a person who's been hating GNU/Linux for the past decade or so: "Can you get me a Debian sticker? I love Debian." Other times, I listen, and just stay invisible. To illustrate my skills, let me briefly mention a few accomplishments: - We have the Budapest Clojure User Group meetups running, even though it is still a nieche language, and out of the ~15-20 people who attend the meetups, most of them don't even use Clojure. They found the events and their 'advertisement' interesting. They keep coming back for more. I help organise these events, I talk, and I help bring people in. That's administrativa, communication and inspiration right there. ;) - In a few months, I will spend 100% of my paid time working on free software. I started the initiative at work, I made compromises (like the status quo of 50% support / 50% free software work), I made the case for it, and did not back down even when things looked bleak. I made them want it too. This even involved financial stuff, which I dislike, a lot. Many people in different positions and ideals had to be persuaded, they had to be enlightened, and they had to become motivated to help me push this deal through. - I gave Debian packaging tutorials at work (at one point, we gave a ~6 hour marathon of it with my former boss, that was wicked awesome [not my words, either]), which are in such high demand that I will have to give more. There's one more feat I'm particularly proud of, you'll find it below, because that also answers your last question. > How would you have dealt with the difficult decisions the previous DPL > had to make regarding various conflicts or problems that occurred during > his mandate(s)? Would you have intervened? How? This is something I'd rather not answer, on one hand, because it would take too long, and on another, because in the most interestring (for some values of interesting, anyway) cases, I simply do not have enough historical data to see the whole picture, therefore can't make a well informed judgement, either. > Could you give an example of such a situation where you have > successfully mediated a (potential) conflict? Which tools did you use to > deal with the situation? Although this happened years and years ago, when I was young, foolish and hot-headed, there's one particular feat I'm proud of to this day. I was an Application Manager at the time, and there was this particular person who pissed off pretty much everyone in existence: ftp-masters, prominent maintainers and project members, the Debian Account Manager. So much so, that he had multiple threads over the course of a few months (if I recall correctly) all complaints about his behaviour. We worked together to resolve these issues, it took a long time, but in the end, he ended up becoming a Debian Developer, worked with the very same people whom he pissed off before, and some amazing things were accomplished later on. While skirmishes did occur later too, things did turn out fairly well for everyone in the end. To this day, I'm proud that I helped him achieve that, that with our combined work, he'd become a great collegue to work with the same people who strongly objected to him even applying for a Debian Developer position. This was a tough and dire situation, at a time when I wasn't half as much
Re: [all candidates] how to choose Jessie init system
Stefano Zacchiroli writes: > Some of the longest -devel thread in recent years have been about > Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. > Despite folklore, I don't think those thread have been (entirely) > trollish, they all hint at a concrete problem: (For the record, it's systemd, not SystemD. Sorry!) > How do we make an inherently archive-wide technical decision when > multiple, possibly equally valid solutions do exist? What I believe to be a solution in cases like this, is to sit down with the stakeholders (preferably in person; a conference or DebConf would be a perfect opportunity for this): maintainers of said systems, porters (primarily kFreeBSD & Hurd folk), the security & release teams, and if possible, upstream developers of the individual init systems too. I'd do this behind closed doors, initially, because the number of arguments and the level of noise needs to be controlled, and we've seen how well that works on a public mailing list. We need to estabilish the key requirements (which in this case, will be a though cookie to crack too), and see what compromises the stakeholders are willing to make. The primary role of the DPL in this case would be organisation and mediation, to make sure that those involved understand that compromises will have to be made, or we'll be stuck with sysvinit forever, which is likely not what most of them would want. Also, since there's many people involved, and I would very much like to get upstreams in too, this would not be doable within a single sitting - rather, one discussion where Debian members attempt to come to a few agreements, and another, where upstreams can help us clarify things, or point out any mistakes in our thinking. There will be conflicts of interest, which is another reason I would strongly prefer holding this sprint in person: it is far easier to reason with people in person, far easier to calm the waters when one does not have to fight latency and distance too. Ultimately however, this is a decision that the technical stakeholders will have to make, but the DPL should be there to faciliate the decision, and keep strong opinions from clashing into each other's face. But the task is not nearly done once key requirements are found, not even when compromises are ready to be made - that's just the beginning. A painful transition will have to be planned, the change throughly documented, with strong reasons behind the decision. With all these, the DPL can help, but he'll be at the instructor's wheel at best. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3p3bp6a@galadriel.madhouse-project.org
Re: Your opinion on Debian Maintainer status
Jonathan Nieder writes: > Gergely Nagy wrote: >> Wouter Verhelst writes: >>>> Arno Töll writes: > >>>>> In fact, even the wiki says "Becoming a Debian Developer: You should be >>>>> a Debian Maintainer for six months before applying to the Debian New >>>>> Member Process" [1]. That's somewhat different to the original idea of >>>>> the DM status and not really a direction we should endorse. > [...] >>> Note that, first, the NM frontdesk has always been willing to fast-track >>> someone who is "obviously" skilled (with "obviously" being vague on >>> purpose) and, second, that the DM step is not required for emeritus >>> developers returning to Debian. >> >> This is exactly why I think it is such a bad idea. Because it is too >> easy to make it sound like DM is a stepping stone to becoming a DD. It >> is not. It is *one* of its aspects, a useful one, but in my opinion, far >> from being the most important one. > > I do not even agree that it is useful as a stepping stone. I'll have to disagree, I'm afraid. > DM privileges recognize that a contributor should not have to wait on > a DD to apply improvements within a specific domain where the DM has > shown she can be trusted. This can be a good way for a new > contributor to become useful to the project and to make daily > maintenance less painful while waiting for recognition as a DD, sure. ...therefore, it can be useful as a stepping stone. > With the specific goal of preparing to be a Debian Developer as > quickly as possible in mind, though, it mostly hurts: > > * Becoming a DD means gaining familiarity with how a variety of >procedures affect the entire archive. DM privileges create a >temptation to work only on your own packages and not pay attention >to others'. On the other hand, working on your packages only at first is still useful: you get to learn how to deal with bugreports; getting ported; how your package may affect others (if there's any that depend/build-depend on yours); how other packages and transitions affect you. These are all useful things to learn, and available for DMs too. (Yes, all of these are available opportunities even if one's not a DM, but gets sponsored - but it's very different when you experience these on your own, than when through a sponsor.) > * Becoming a DD means gaining an understanding of how other >developers work and think and how to interact with them. DM >privileges create a possibility of working (and contributing >usefully!) without needing to interact with other people, and >losing an exposure to mentors' styles and insights. Both issues you listed are things that 'may' happen. Some bad things that may happen will not make the entire idea for that domain useless. Every DM-uploaded package had a DD grant the DM permissions for it, every DM has had an advocate - I would expect these people to have a rough idea what the DM wants to achieve: does she want to become a DD eventually? If so, help her. If not, leave her to her packages. DMs should not be left out in the cold, so to say, once they have their status. DM-ship is an opportunity, in a sense. If one does not use the benefits it provides, it will, indeed, not be much of a help in preparing one to become a DD. But it does give you the opportunity to get better prepared. That, in my opinion, makes the status useful as a stepping stone. > The DM process is an excellent answer to new contributors asking the > question "Why must I wait so long for my improvements to be > incorporated in Debian?" On the other hand, I think it is a bad > answer to "I want to be a Debian Developer. What is the first step?" It is a bad answer to the second question, yes. The correct answer is "Start contributing.". Becoming a DM can be one step in that process (though, it will not be start). -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sj3tawkf@galadriel.madhouse-project.org
Re: Your opinion on Debian Maintainer status
Wouter Verhelst writes: > On 17-03-13 02:02, Gergely Nagy wrote: >> Arno Töll writes: >>> In fact, even the wiki says "Becoming a Debian Developer: You should be >>> a Debian Maintainer for six months before applying to the Debian New >>> Member Process" [1]. That's somewhat different to the original idea of >>> the DM status and not really a direction we should endorse. > [...] >> Thank you, for reminding me of that. I haven't looked at that page since >> I re-applied, and almost forgot those words. We really should reconsider >> that paragraph, and preferably kill it with fire (post-wheezy, of >> course). > > As someone who supports that policy (in the general case), can you > elaborate on this? Why do you think it is such a bad thing? > > Note that, first, the NM frontdesk has always been willing to fast-track > someone who is "obviously" skilled (with "obviously" being vague on > purpose) and, second, that the DM step is not required for emeritus > developers returning to Debian. This is exactly why I think it is such a bad idea. Because it is too easy to make it sound like DM is a stepping stone to becoming a DD. It is not. It is *one* of its aspects, a useful one, but in my opinion, far from being the most important one. It can too easily be read as putting more road-blocks in front of people who already know they want to become DDs, and are confident in their abilities. It is too easy to feel discouraged, when you're reading that you should spend half a year as DM, when that really is not your goal. It makes it sound as if the DM status was there to limit new people in what they're allowed to do, as if it was a stepping stone and no more. It can be used as such, but the original intention was not to limit people, but to empower them. The quoted paragraph goes against that spirit. It is great that we can use the DM status as a stepping stone, really. But it sucks if that's what we emphasize most, and it's even worse when we put a time-frame on it, a time-frame of six months. (Too many assumptions hidden in there, for my taste...) In contrast, the DebianMaintainer[1] reads: "It is highly recommended to be a Debian Maintainer before applying to the Debian New Members process to become an official Debian Developer (see the Applicant's Checklist)." [1]: http://wiki.debian.org/DebianMaintainer#Introduction I like that much better, because it does not directly say six months (the applicant's checklist does), and I find it much easier to interpret this as an optional step. A recommended, but optional step. If we could rephrase the "6 months" thing too, into something like (in case of the checklist): "...and have been maintaining and uploading packages long enough that both you and your advocates feel ready to take the next step." That would express the intent better, I believe, without invalidating current practice. TL;DR: Putting the emphasis on DM being something that empowers is much more useful than putting the emphasis on DM being a stepping stone. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87620qchoc@galadriel.madhouse-project.org
Re: various ideas
Paul Wise writes: > Would becoming DPL increase the chance that you would work on any of > these ideas? > > Would not becoming DPL increase the chance that you would work on any of > these ideas? Well, not becoming DPL means I'd have less time to spend on Debian things than if elected, so, technically, not becoming DPL would severely decrease the chance that I'd work on any of the ideas on your list. But, if we take a hypotethical scenario where I'd have all the time in the world, elected or not - becoming a DPL would not increase the chance of me working on any of the ideas, either. That is to say, being DPL has nothing to do with what I find important, and what I'd like to work on, and work towards. There are some very good ideas on your list, that I find important to push further along (just to name a few: better communication [all kinds of it]; touchscreen-only and mobile support in d-i; d-i being able to highlight platform specific freedom issues; Supersedes; etc), but this is only tied to how much time I have, not to the DPL position itself. It's a mere coincidence that if elected, I'll have more time I can dedicate to Debian and DPL duties. It's the availability of time that increases the chance, not the position. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2uycnux@galadriel.madhouse-project.org
Re: not being elected?
Hi! At last an *easy* question to start the day with! Thank you! Paul Wise writes: > What do you plan to work on if you are not elected? I have not made plans. There are many similarities between all three platforms, and in our goals, so most likely, I will first wait and see where things go, and decide how and where to proceed along the way. (But see below) > Will not being elected de-motivate you? Demotivate? No. Perhaps a little sad, for a very short time. > Will you work on the things in your platform even if you are not > elected? Most of the things mentioned there are not DPL specific tasks. If not elected, the time I can spend on these tasks will be much less, as I will not be able to use work time for it. But nevertheless, I'll do my best to further the goals I see as important. > Gergely Nagy, was not being elected in 2012 de-motivating? Nope, not at all. It's not easy to demotivate me, when I set my mind to something. (Read: I will continue running for DPL until I win, and then some more, each and every year, as long as I'm certain I'll have the time needed to be of good service.) I was reasonably happy with the results last year - I hoped to fare a bit better, but the results were in the same ballpark. > In 2004, how did you feel about getting votes after running as a joke > candidate? Relieved, that people have a sense of humour. Happy, because I reached my goal: NotA received more votes than I did. Overall, I enjoyed the whole process, and loved the outcome too. The best though, was the feedback I received during and after the election. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hakacotn@galadriel.madhouse-project.org
Re: Your opinion on Debian Maintainer status
Arno Töll writes: > On 17.03.2013 00:01, Gergely Nagy wrote: >> We have close to two hundred entries in the debian-maintainers-keyring, >> that's a respectable number, which reaffirms my recentish change of >> heart, that the DM status is a good thing, and while it does not solve >> all problems, it is, nevertheless, a useful thing to have. > > although I'm deliberately ignoring all the good reasons you provided, > JFTR, many people feel obliged to become DM these days before applying > as a DD and even many DDs understand the DM concept as a probation to > test potential NM candidates. > > In fact, even the wiki says "Becoming a Debian Developer: You should be > a Debian Maintainer for six months before applying to the Debian New > Member Process" [1]. That's somewhat different to the original idea of > the DM status and not really a direction we should endorse. > > Thus, the sheer number of DMs is not a really a resilient number per se, > although I agree that the DM status itself is a good procedure. Indeed, the number alone is of little value, it is merely one of the data points. I do wholeheartedly agree with you too. One of the reasons it took me so long to change my opinion on the whole DM status was those few lines from the wiki you quoted. (It delayed my return to Debian by at least half a year - whether that's a good thing or bad is to be decided by my dear readers.) Thank you, for reminding me of that. I haven't looked at that page since I re-applied, and almost forgot those words. We really should reconsider that paragraph, and preferably kill it with fire (post-wheezy, of course). -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obeidej2@galadriel.madhouse-project.org
Re: [all candidates] Debian as an FSF Free Software Distribution
Paul Tagliamonte writes: > What work will you be doing to continue Zach's efforts to negotiate with > the FSF over Debian's status as a Free Software Distribution? I do not plan to be on the front line, but it is an important effort that must be continued. If elected, I'll make sure that the appropriate people are empowered to continue the effort, and I will be available for mediation, support and any other task that may arise. I will not, however, wish to become a driving force, because there are others who do that much better in this case than I would, and I'm more than happy to let people do what they're passionate about. > Will you treat this issue as a priority? Can we expect continued open > dialogue with the FSF on this issue? Would you be willing to help find > the right concessions on both sides to collaborate? Yes, yes and yes. > What is your opinion on this matter? While getting debian recognised by the FSF as a Free Software Distribution would be useful for both parties in my opinion, I see little hope for that to happen, because while we generally agree in principle, and our goals align quite well, there are subtle differences. That, however, is not a bad thing. I do not wish neither the FSF, nor Debian to compromise in either of our ideals, for that would be disastrous. It would still be useful to agree on what exactly we're disagreeing on, and why, and treat those disagreements respectfully and openly. Recognising that our goals align, and the differences are really just in the details would already be a great step forward. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjy3cm5x@galadriel.madhouse-project.org
Re: Usage of Debian's Money
Lucas Nussbaum writes: > On 13/03/13 at 00:57 +0100, Raphael Hertzog wrote: >> 3/ Buy advertising space on various media to recruit new contributors and >> lead them into our (improved) mentoring infrastructure. > > I think that we have other, better ways, to improve the project's > visibility than to use paid advertising. For example, do cool stuff, and > get it covered by the press. ;) Let me disagree a bit here. While it may not apply to all kinds of press, my impression so far is that waiting for press to happen is a nice dream. To achieve maximum effect and reach, you have to influence the press, and just doing cool stuff will not be enough for that. Quite likely, they won't even realize cool stuff happened, or only when it's already old news. But even if they do, will they consult us? Will they paint a correct picture, that does us good? I would not be so sure, and would rather avoid this whole problem by delegating the task to OUR press team whom we do trust, and then persuade the media to use our press team's material, in exchange of some green bills or virtual coins. Everybody wins. Mind you, I'm not saying that accidental press is bad - it surely isn't. All I'm saying is that we can benefit from both. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9q3e3e6@galadriel.madhouse-project.org
Re: Usage of Debian's Money
Raphael Hertzog writes: > Since both of you want examples of possible uses of money, here you have > some that I quickly came up with: > > 1/ Grant some amount of money to the release team to offer as bounties on > release blocker issues that are not going forward. While such one-off bounties would help the release further along, would it be worth it? As far as I see, our releases are slow, because we're terrible at dealing with RC bugs, we have tons of packages lingering in a sorry state, and there's no bounty that'd fix any of these. It's a bit of an exaggeration perhaps, but bounties for release blocker issues sounds like pulling a tooth. It makes the pain go away, but if you don't wash your teeth, it doesn't help much in the long run. > 2/ Have the ftpmasters write up a spec of what needs to be done to finally > have "ddeb support" (or "PPA" or ...) and use Debian's money to contract > with someone (unaffiliated to Debian?) to actually implement the spec under > the > supervision of ftpmasters. Copyright of the code written would fall under > Debian/SPI. The problem with this approach is that writing the spec and supervising the person or people implementing it is no small task, either. I dare say it is actually harder than writing the code itself. Therefore, I would find it unfair to spend money this way, unless ftpmasters are getting paid for their part too. I find the GSoC model reasonably acceptable for these kinds of things, however. > 3/ Buy advertising space on various media to recruit new contributors and > lead them into our (improved) mentoring infrastructure. Offer goodies as > rewards to new contributors who successfully played some game which > tricked them into contributing to Debian. This, on the other hand, does sound like a reasonable idea. However, I think that our primary goal should not be the recruitment of new contributors (not directly, anyway), but to increase our visibility, and to show the wider world, that we're more than a group of geeks who do a distribution. I won't go into details right now (too many other questions to answer, sorry!), but feel free to prod me, if you want me to explain further. (Although, I probably touched the subject partially elsewhere - but not quite in this context, so.. if you want me to explain, let me know, and I'll happily do so.) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehffe3z1@galadriel.madhouse-project.org
Re: Usage of Debian's Money
Raphael Hertzog writes: > On Tue, 12 Mar 2013, Moray Allan wrote: >> If there was general support then we could look at organising a >> funded program, but I would need a lot of persuasion before wanting >> to get into the question of Debian picking specific individuals to >> pay for their work while everyone else is unpaid volunteers.[2] >> >> [2] Some of you will remember Dunc-Tank. > > Despite the above statement, your platform mentions “I would seek > suggestions on how we could try to advance Debian's goals by spending > money in ways we're not currently doing. While I think we should be > careful with money, I would be willing to authorise spending to try out > new ideas from others, where goals can be defined and the success of an > initiative can be judged.” > > What kind of new ideas would be acceptable? Feel free to invent some > hypothetical examples to illustrate. > > To other candidates, do you believe that we could benefit from using money > for other things than hardware and meeting/travel reimbursment? If yes, > what kind of things? Yes, I believe we would benefit from using money for other things than hardware and meeting/travel reimbursment. We already use money in other ways (sprints come to mind, for example, but one can argue that these fall under meeting/travel reimbursment). As I mentioned a few times here on -vote@ already, one of the things I'd like to see is more events, that are not strictly Debian related, but rather Debian sponsored. The intent there is to meet people who are not yet interested in Debian, may not even heard about it, and learn from them, to help us better understand how we could lure them towards us. All this under the disguise of doing something completely different. I'll give you an example! Imagine a CodeRetreat[1], a day long, intensive practice event (a great way to learn a lot, meet people, and for a lot of other things too). This is often done by having ~45 minute sessions, where during each session, people work in pairs (or well, together with others, does not need to be only two - point is, never alone) to solve a particular problem. Each session adds a new twist, and after each session, the participants discuss the previous one: what they learned, what they found interesting, how far they got - and so on. Then change pairs, and proceed. [1]: http://coderetreat.org/about This, so far is nothing earth-shaking, but meeting with new people, potential contributors is already a big win: the power of corridor-talk is not to be underestimated. However, there is more! We can twist and turn the goal of the sessions, the problems to solve in many ways, and therefore, we can bend it to our will, too. We can prepare sessions where participants solve a particular issue we have (or had) within Debian. Obviously, these need to be lightweight ones, with whih one can progress far enough within 45 minutes, and where the CodeRetreat facilators can help. So one idea would be to pick an issue we already solved one way or the other, and let the participants have at it. In my experience, when this is done well, participants will sooner or later (and often sooner) dive deeper, and by seeking more knowledge, contribute in the process. The various teams (be them packaging teams or other kinds) are in the perfect position to benefit from these kinds of events. I will do whatever is in my power, to help them use the opportunity, to help them organise (and I'm counting on local teams here too - a project-wide collaboration, whee!). Another idea - which falls somewhat under travel reimbursment - would be to have Debian people give guest lectures at universities. When I was attending a technical university, I loved the guests (that was pretty much the only thing I loved about it, to be honest, which is one of the many reasons I never finished one :P), for they showed how things go in the real world, how even one person can make a difference - and that was very inspirational. Add to this, that we have able speakers, we have university connections, we have people from a vast amount of technological - and non-technological - fields. We should use these to our advantage, and support those among us who like to speak, and do that well, so they can do what they do best. There are countless people out there we could reach, if we only took the effort to find them and talk to them. Not just at technological conferences, or as guests lecturers on a programming class - there's much more to Debian than that. I'd like to think that money spent on making Debian being known for something more than a mere distribution (no matter how awesome we are at that), is money well spent. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip4re51b@galadriel.madhouse-project.org
Re: to DPL candidates: getting new people to Debian
Serafeim Zanikolas writes: > On Sat, Mar 16, 2013 at 11:21:05AM +0100, Lucas Nussbaum wrote [edited]: >> But asking students to contribute to Debian during university projects is >> quite >> difficult (I have thought about it numerous times, but never found a >> good-enough idea). it would be interesting to share feedback on that, to >> identify and suppress potential blockers. > > If you refer to university students in some software-related discipline: have > you considered assignments for the preparation of patches for wishlist bugs in > native and pseudo-packages (eg. infra-related sw projects)? That doesn't really help, in my opinion. It will be a 'forced' contribution, one which will not continue past the assignment. That's not really what we should aim for. Unless you make it interesting and worthwhile for them to continue contributing, they will not do anything more than strictly required, simply because that's not what they find satisfactory. Prove them that it's worth it, that having significant contributions to Debian (or any other bigger free software project for that matter) on their resume is a good thing, and you're much closer to the goal. Simply telling people to do this and that, because you have the power to tell them will have the exact opposite effect. Instead, we must find a way to make these tasks not only visible and known, but interesting and worthwhile to pursue too. (Which also means we need people on the Debian side too, to help and mentor the students - without that, it's an exercise of futility.) > More generally, I think that our needs for native development are not nearly > as well advertised as are those for packaging-related work (WNPP). ...and this highlights another issue I have with our infrastructure: wnpp can be quite an intimidating mess, with over a thousand packages in ITP and RFP state. That's a lot. I get scared just by looking at the number, and I'd like to think I'm not the only one. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwu3e6zm@galadriel.madhouse-project.org
Re: to DPL candidates: getting new people to Debian
Hi! Instead of answering Timo's question directly, I'll answer to Gunnar instead, in the hopes that I can answer both of them in a satisfactory manner. Gunnar Wolf writes: > Timo Juhani Lindfors dijo [Sun, Mar 10, 2013 at 05:34:58PM +0200]: >> Hi, >> >> I'd like to have each DPL candidate briefly discuss the challenges of >> getting new people to Debian. > > Riding on Timo Juhani's question (and not yet having read the two > answers that it has already): There was an interesting discussion > (sadly, in a private forum I cannot quote here, but the fact of having > had the discussion does not disclose private information, yada > yada...) that had as one of its interesting points the current age > distribution, based on the entered data in Debian's LDAP entries. It > shows the project as a whole is aging, and not only in the sense that > Moray describes in his platform, but in the sense that we developers > are getting older — When I joined the project I remember being happy > and proud to be slightly under the (perceived) average age (among > DebConf attendees). Today, I am 36 years old, and my age is... I don't > remember whether the mode or the average. > > At the same time, now that I have started teaching at a university, we > have a once very active LUG (complete with a meeting laboratory and > all!), and it has gone almost deserted. My friends at the Faculty told > me we need a way to attract younger people into Free Software > development - It's not as easy to do it as it was ~10 years ago. There is another additional fact that makes this all the more worrysome: we have far more technically apt young people now, than we had ten years ago. I see people around me teach their children to use and control computers, to build things with them, even before they learn to write. They have their toys, they build stuff, sometimes they unknowingly write programs - before the age of eight. I find that astounding (I used to be so proud at writing my first program before I could write - now it isn't all that rare, and that's a good thing, that people have the opportunity to do that). The thing is, Debian is often not available on the devices younger people start off with - and even if it is, not by default. Someone who just began to experiment, to play, will not install a whole new world onto his/her device. That's advanced stuff. Debian is also not impressively different, so to say. We have a distinct culture, we have great technical solutions, but those are hardly enough to impress someone who just casually looks. We need to reach out and show them that there is much more under the hood than they may imagine, that we can, and we do provide something unique. And we need to impress them. That's a very, very hard thing to do, and something that we'll need lots of help to accomplish, and not necessarily from technical folk. (Which is why one of my primary aims is to reach and and recruit non-technical contributors to Debian.) > So, do you think this demographic shift towards older developers is > harmful to the project, or that it is just a fact and we should not > worry? Harmful? No, not necessarily. We should be aware of it, nevertheless. > How would you intend to attract more young, interested, talented > people? This is briefly mentioned in my platform, but, see below too. > What do you think we, DDs spread all over the world, mostly working on > a professional setting (and not anymore mostly students enjoying heaps > of free time) should do to bring in more, younger contributors? Share the knowledge, share the culture, the stories. I've attended a couple of code retreats recently (they seem to be quite popular, and for a good reason), and found that they're a great forum not only to meet others, learn and teach, but to spread the word too, to evangelise, so to say. Much like DebConf, but for the not yet initiated. What I think would help, are more local events - not always strictly Debian related, as you'll only reach a tiny fraction of people with that. But things where the attendance can be impressed, to bring them closer to our culture, to our ideas. Once interested is sparked, we can proceed further, but it is a gradual process: we won't win anyone for the project overnight. We need to impress the young. We won't be able to do that with technical feats alone (though those do help, and are required, and we have much to improve there too, at least in the being readily available for all kinds of fun devices department). Most of the younger people I talked about Debian with in recent years were in their early 20s, and what they seemed most impressed about is not our technical feats, not our quality, not anything like that. But the culture. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4jfed9b@galadriel.madhouse-project.org
Re: All candidates: Development and technical issues and challenges
Lars Wirzenius writes: > Gegerly, Moray, and Lucas: > > We're currently in the middle of a freeze for the next release. We've > been in this release since June 30. That's over eight months. That's a > long time, even for a project the size of Debian. Releasing when we're > ready is all well and good, but it's a problem when it takes us so long > to get ready. > > In your opinion, what are the fundamental reasons the release freeze is so > long, and so painful, and what do you propose to do, as DPL, to fix them? The fundamental reason is that fixing bugs isn't all that rewarding in many cases, and considerably harder than doing packaging, especially in cases where one can't rely on upstream help either (for any of the million reasons). What we could and should do (and this includes everyone, not just the DPL) is to make upstreams, downstreams and everyone else involved realise that if we work together, we'll release faster, and if we release faster, we'll have more up to date software, which benefits everyone. I've heard many an upstreams (and users of downstreams too) complain about how old packages in Debian are. I myself am annoyed too about this from time to time, when I'm wearing my syslog-ng upstream hat, for example. But the only proper way to make things better if we combine our knowledge. To do this effectively, we need to learn another thing: we are not our packages. There is no shame in asking for help, or even giving up a package. There is no shame in joining a team. There is no shame in working together. All these things make us better, make the packages better, make Debian better, make the world better. Why we need to learn this? Because there are many half-abandoned packages in the archive, that make the release a lot slower than it needs to be. These should be found and taken care of *before* the freeze, and we should be doing this continously. We have a lot of data points that help us recognise these cases, we need to solve the social issues if we want to avoid these problems in the future. For that to happen, we all need to realize that we're not our packages. > What other development process problems do you see, ones that do not > directly affect the freeze, but make the development of Debian less > productive or less interesting? I feel the collaboration between Debian and downstreams is far from perfect, and that is usually a fault of both sides. Tiny little speckles of dust in the machinery some of these problems are, but if enough dust accumulates, the machinery will suffer. We need to figure out if - and how - we could work together more closely, to reduce the workload on all sides, as that also reduces the annoyance we may have with one another. > Finally, what are the main technical challenges you see for Debian in > the next five years and what should we, as a project, do about them? Most of the challenges I foresee in our immediate future are non-technical. We're fairly good at solving technical problems, so no particularly huge challenge there. At least, not anything we haven't seen before. Nevertheless, what I do find worrysome, is that there seems to be a trend of upstreams bundling third-party components (often slightly patched) into their zillion-component, big and complex solution. Untangling this mess, packaging it, and keeping it functioning is very challenging, to say the least. Persuading upstreams to not do that is - sadly - simply impossible, so we need to either work around this, or bite the bullet and package the forks too, either separately, or bundled with the application (yuck). Another - at least partially technical - challenge would be to improve our own infrastructure and processes, in order to attract more (or at least, drive away less) potential contributors. (See https://lists.debian.org/debian-vote/2013/03/msg00157.html for more details) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8reess@galadriel.madhouse-project.org
Re: [all candidates] vote time?
MJ Ray writes: > How much time do you think voters should spend reading these discussions? Enough time to make an informed decision - or throw a dice, whichever they prefer. Noone's required to read all (or any) of -vote@, it is entirely up to them how much time they want to spend on it. Myself, I enjoyed reading -vote@ in the past (and still continue to do so, albeit answering everything is much harder than reading only, especially when there's overlap and noise involved too). > With the benefit of some hindsight, do you feel that you are being > concise enough to achieve that time? Yes and no. Yes, because people have the ability to stop reading me anytime they want. No, becuase my intention is not to shorten the campaign period. I could do that, by saying "I suck, vote for NoTA over me!", or just link my platform to every second question, but that would not really do me anything good (and it would be quite dishonest too). > Would you change anything about the DPL or GR processes to help achieve that > time? Once thing that I thought about was a pre-arranged questionnaire for the candidates: collected the week after platforms are published, before the campaign period, then posted, with the candidates having a week to answer. Once answered, further questions are collected and organised again, and posted in a followup questionnare - you get the idea. This would eliminate overlapping questions, and would make it easier for the candidates to answer. On the other hand, it would be a lot of work, would be terribly boring, and I'd hate it. So lets not do that. I do like the element of surprise in our current campaign process. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjy3egp8@galadriel.madhouse-project.org
Re: Are there problematic infrastructure or processes in Debian?
Raphael Hertzog writes: > Debian's infrastructure and processes have grown organically over the > years, with all the strengths and weaknesses that it implies. Sometimes > it's a good idea to step back and look whether some of those need > to be amended/replaced/dropped/etc. > > Based on your own experience, which infrastructure(s) or process(es) would > benefit from significant changes? > > Are there infrastructures or processes that we're (still) lacking and that > could make a significant difference in the work of Debian's contributors? As far as infrastructures go, what I find a bit troublesome is that our tools are sometimes too diverse: too many languages, too few people to understand and improve them. This is also a project-wide problem of not being able to make use of our human resources better. This, in turn, leads to situations where some of our tools look like they're stuck in the past millennia, which is quite a bummer when it comes to attracting new contributors, especially when said tool is something they'll see early on. (Yes, I'm talking about the BTS, which is a terrific thing, and I wouldn't trade it for anything else, but from a usability point of view, it is behind times. It would help tremendously if we had more people working on it, as one person can't cover all aspects.) To attract new people, we need a bit more than technical excellence, we need to impress them, and impress them fast. This - as blasphemous as it may sound - may require our user-facing tools to look nice, and be friendly to newcomers. A big problem with parts of our infrastructure is that this is not the case. On the topic of processes, I'd emphasize mentoring & sponsoring. This is where we're... well... I'll be honest: we suck at it, in general. We do have some amazing teams that do this well, we have a lot of it going on in the background, hardly visible. BUT, we also have a lot of problems, and they are sadly far more visible, which can easily drive off new contributors. In my experience, mentoring and sponsoring over the internet rarely works effectively, due to a whole lot of things, including but not limited to language barriers, lack of knowledge (on both sides, but in different areas), noise, lack of time, impatience and so on. What does work, as far as I saw is meeting and talking in person. Things can go a lot smoother and faster in real life, as there is the personal connection. If we could have "mentoring sprints", that would be very useful, in my opinion. (Encouraging & empowering local teams to help this cause further would be an important thing.) Another area we're lacking in is recruiting non-packaging contributors. I believe that local events, much similar to the aforementioned mentoring sprints would be a great way to reach out to more people, be them technical or not. Show them how Debian makes a difference, *impress* them, and we're halfway there. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ngbfvue@galadriel.madhouse-project.org
Re: [all candidates] DPL salary
Stefano Zacchiroli writes: > Due to time and travel demands, there are blockers in being DPLs. Most > of them are work related. Within that category of blockers, some could > be solved by a salary but many (according to your judgement) could not. > If we agree on this, it means that we are losing many potential good DPL > candidates due to those blockers. > > The broader question is than: what can we do to loose those blockers and > profit more from the abilities that we do have in our community? First, we need to know those blockers. We can figure some of them out on our own (travel time, work, etc) - but the best way would be to ask, as I said so in my earlier reply too. Once we have more input, we can try to find a solution. Most likely you have way more information about the matter than I do, but right now, I don't feel we have enough knowledge to start thinking about how to remove the blockers. > Maybe the answer is "nothing"; it's just the way it is, and we should > accept a "deficit" on that front wrt other communities. But maybe there > is something else we could do... what? One thing that does come to mind, is that people need to realize that the DPL is not a one man army. The DPL does not need to do everything alone, and is not expected to do that, either. (Or if so, we're doing something terribly wrong) The DPL must know his or her limits, and - with the help of the project - find ways to counter them, be that delegations or something else. It is not, and should not be a one man show. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v5nfxel@galadriel.madhouse-project.org
Re: [all candidates] DPL salary
Stefano Zacchiroli writes: > On Tue, Mar 12, 2013 at 01:31:08PM -0700, Russ Allbery wrote: >> For example, I would question whether one could do the role of DPL with a >> conventional full-time job in IT, at least if you want to keep any other >> hobbies outside of those two jobs. The amount of media and expected >> travel to represent Debian is rather intimidating (particularly to an >> introvert), as are the number of things that are relatively >> time-sensitive and require a lot of effort. > > Thanks for providing the background for a question I wanted to ask! > > I totally agree with you and I'm worried about that. I've been lucky in > having the flexibility needed to be DPL and I wish the same flexibility > to the next DPL. But, in terms of Debian sustainability, I'm worried > that we de facto rely on people having that kind of flexibility to be > good DPLs. I believe we are losing, via preemptive self-selection, many > good candidates (from IT or other fields) for precisely that reason. We're losing out on a lot of good candidates for many, many reasons, and I do not believe that a DPL salary would help in any way, quite the contrary! I'll explain below. > The ground shaking question to all candidates is then: what do you think > of providing a DPL salary using Debian funds? I know it is a touchy > topic, and I propose it on purpose :-P I do not think this is a good idea, and I would strongly object to such a proposal. While it does solve one particular problem, that of the DPL being able to focus all his time on Debian, it also presents quite a lot of problems, that make the whole thing not worth it. For me, Debian has always been something I contribute to because I love doing it. It never was, and never felt like a job. Getting paid to do it would ruin that for me: I have a job that pays my bills, a job I love, a job I don't wish to leave. Havin a day job also means I'll have pension once I'm willing to stop hammering on keyboards. There's plenty of other things a day job provides, that would be hard for Debian to accomplish, if for nothing else, then the geographic diversity of DPLs. > Some further thoughts to foster the discussion: [...] > - some of the "dunc-tank objections" do not apply to this case, because > the DPL is the sole elected role in the project. As such it is already > "different" from other volunteers, the difference will not be created > by the salary, only acknowledged to make the job sustainable and more > appealing. It is also a role that de facto demands to take significant > time off your day to day job (on that front, however, it is not the > only one --- DSA and security come to mind due to the need of handling > emergencies, and there are others) I do not agree that the DPL position would be different from any other important role within Debian. The only difference is being elected, and that's about it. Other roles take quite a lot of time from one's life too, I would find it worrysome to single out one particular position, no matter what that position may be. Yes, the DPL likely travels and speaks a lot more (but that's also a perk, as far as I'm concerned) than people in other roles may, and these should not be paid out of one's own pocket, much the same way as people attending Debian Sprints are often sponsored too. This does not, however, require a 'DPL salary'. > - several other, volunteer driven, independent organizations are paying > their "leaders" using donated money since quite a while: both GNOME > and the FSF pay their executive directors, and there are other > examples Both the FSF and the GNOME Foundation have a different structure than Debian. What makes sense there, does not necessarily apply to Debian. They also have more than a single employee. (As opposed to the DPL being the only one in Debian's case.) > - invariably, the salaries paid in those settings are significantly > lower than IT market salaries; but they still allow to be in that role > full-time, although surely not for greed when compared to alternatives However, there's one thing a DPL salary does not provide: a stable job. Noone served as DPL for more than three years yet, and only you served that long. With a job, one can feel secure, does not need to worry yearly about the election (or look for another job, would one decide not to run again). That stability is something I do not wish to give up, and something that being paid for being a DPL would not provide. I mean, even if one's confident about his or her provess to be elected year after year, history tells us that none held the office longer than three years. On the other hand, a lot of people held their job for far more than that. Also note that salaries vary wildly around the world, one won't be able to find a good balance. (For example, with my current salary, if I'd move to the US, I'd be broke within a few months, yet I can sustain a convenient life here in Hungary.) > - deciding to pay th
Re: All candidates - quotes for the press if you win
Neil McGovern writes: > Could you provide a couple of sentences (no more) for the below? > > * How do you feel about having won the election? Sad, ready, happy and humbled. Sad, because only one of us could win. Happy, because of the trust the voters showed towards me, humbled for the same reason. And ready to serve. > * What is the main thing you're looking to change in your first 100 > days? The biggest thing I'm looking forward to changing the first 100 days is the transition period. I'll be working tirelessly to pick up the tasks and start out on the journey of improvement. > * What do you view Debian's greatest challenge in the coming year? The greatest challenge I foresee is growing up, out from being a simple (for some values of simple) distribution with a great community and unimaginable talent into something much more. > * How important is Debian directly, now that Ubuntu and Linux Mint have > grown so popular? Debian is *the* universal operating system. No matter how popular downstream distributions will become, this will always remain the case. It is very important that we not only maintain, but improve our standing, and learn from our downstream's success. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li9rfcju@galadriel.madhouse-project.org
Re: [all candidates] DPL term duration
Russ Allbery writes: > Moray Allan writes: > >> However, the DPL role for a single year is already a big commitment, >> taking a lot of energy and time (typically including a lot of the time >> that person previously spent in other areas of Debian). Already many >> people who would perform the role well choose not to run due to the >> required commitment. > > For example, I would question whether one could do the role of DPL with a > conventional full-time job in IT, at least if you want to keep any other > hobbies outside of those two jobs. I'll have to disagree here, but perhaps my idea of a conventional full-time job in IT, or hobbies is different than yours. > The amount of media and expected travel to represent Debian is rather > intimidating (particularly to an introvert), as are the number of > things that are relatively time-sensitive and require a lot of effort. Fortunately for us, quite a lot of things one does as a software engineer can be conveniently done in a hotel room or while travelling too (been there, done that, didn't find it a big deal). Also, in case one's working for a free software friendly company, going to the same conferences one would go as DPL may very well match those he'd attend anyway. So, yes, travel and media do take a lot of time, but I don't think they neccessarily conflict with having a full-time job. > (I think mediations and helping people work together is much more > difficult than technical work on packages.) This, I fully agree with. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppz3fei1@galadriel.madhouse-project.org
Re: [all candidates] DPL term duration
Gunnar Wolf writes: > One of the difficulties I perceive we have seen over the years is the > time it takes to transfer the know-how and work rhythm from an > outgoing DPL to an incoming one. Several of our DPLs have repeated > their term. In the past, when I was a new DD, there was this strange > and sad tendency that after finishing their DPL term, DPLs tended to > leave the project (or strongly reduce their involvement) — I *think* > there is some correlation with the DPL task pickup burnout time, which > can be an important portion of the term. Indeed, but the solution to that is not increasing the term duration, as that will not make it neither easier, nor faster to pick up after a transition. It merely means longer commitment, which one may or may not be ready to make. > We have seen some discussions in the past regarding whether the term > should be lengthened to two years, with a mid-term referendum (or > chance to politely step down) rather than full election procedure. How > would you feel about it? I'm not particularly supportive of the idea, even though I fully intend to serve multiple terms. > Would you prefer the term to be stated as a longer "journey", or is > one year the right duration? Would you be interested in pushing for > this change? I believe we need a smoother transition, but a longer term does not help that in any way, as far as I see. Therefore, I wouldn't support such a change. Nevertheless, if pushed through and accepted, I would hold my bid committing to two years of service. Another reason I'm not too fond of extending the term is that 'politely stepping down' and 'not running again' sends a much different message. None of our DPLs were in office more than three years either, and a number of them only served a single term too. I do not see why then an increase two two years would be justified. What would help, on the other hand, is making sure that a DPL transition is much smoother. To make this easier, I'd rather propose a different change: have the election sooner, and for the first few months, have both former and new DPL on board. This, I think, would make it much easier for the new DPL to pick up, and would make it easier for the old one too, because she/he would know who to train in the art of being DPL "ahead of time". One of Zack's purpose with the DPL Helper initiative was to train future DPLs (see his platform from last year). That did work to some extent, as all three of us running this year took part in some way. Taking that idea further, the best way to train the next DPL is, in my opinion, to work together. While a helpers initiative is a step in the good direction and certainly useful in its own right too, nothing guarantees that people participating will run for DPL, that they won't be scared away. Serving together forms a closer bond, and would also result in a smoother transition, provided the former and new DPL are at least on speaking terms. I think that's a reasonable assumption to make, though. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txoffev1@galadriel.madhouse-project.org
Re: [all candidates] Work balance and traveling
Hi! Arno Töll writes: > Sorry to tell, but you're all compared to zack leaving back some by-now > established patterns as a DPL. So I wonder, will you step back from > maintainer/team activities during your term? Most likely, yes. While the packages I maintain are fairly quiet and take little time to keep in good shape, the less I have, the more time I can spend elsewhere. I already am in talks with someone who'd take over two of my packages (libmongo-client & ivykis), and I'm open to give up or co-maintain all the rest too (except for dpatch and dh-exec). By the way, I intend to reduce the number of packages I maintain whether elected or not. I'm also looking for someone to take over the unofficial syslog-ng packages I maintain[1], as *that* takes tons of time. Reasonable progress is being made on that front too. [1]: http://asylum.madhouse-project.org/projects/debian/ As for my other activities.. I still owe Ganneff and the ftp-master team a pdiff patch, I intend to see to it before the end of the campaing period (really, this time!). I'd also like to peek at NEW from time to time, and contribute comments, because that is quite often a very soothing experience. On the other hand, if elected, we'll have to find someone to keep an eye on -bugs-dist and misfiled bugs, because that takes a significant amount of time too, and unlike processing NEW, I sadly don't find it all that rewarding. (Noticing said bugs is easy, the research, reassign, comment, etc part is the trouble.) > How do you intend to handle your existing Debian commitment, in case > you're elected for DPL? See above. But in short: keep some, surrender most. > Moreover, I wonder how much time you intend to spend for representative > conference/summit work, where zack once again did an impressive job to > represent Debian in talks, press and presentations. Unfortunately, I don't think I'll be able to match up to Zack in this regard, but nevertheless, I'll do my best. I'm in a fortunate situation where my employer is very supportive, and if elected, I will be allowed to do DPL duties during work hours, among other things (this also includes being able to attend events I otherwise may not be able to). As for conferences/summits, I believe that representing Debian on these events is important, but if the DPL can't make it for one reason or the other, a delegate should. There's a lot of people within Debian who can represent Debian very well, and are far better known than I am, who accomplished a lot more within the project than I did, have a lot more experience speaking, and so on and so forth - it would be great if this part of the DPL duties wouldn't be viewed as being restricted to the project leader alone. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5drfglm@galadriel.madhouse-project.org
Re: [to all candidates] about a DPL board
...and I managed to sign it with the key I use for signing my repos, instead of the correct one. *sigh* Sorry about that. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738w1ghku@galadriel.madhouse-project.org
Re: [to all candidates] using debian funds for Debian's hardware infrastructure
Martin Zobel-Helas writes: > in the past Debian had some generous donors, who donated a huge amounts > of high quality hardware on regual basis to the Debian project. For some > reasons (not to be discussed here) those sources dont exist any more. One idea - perhaps a naive one, as I do not know the circumstances - could be to figure out a way to find hardware donors again, to cover at least part of the expenses. This obviously assumes that this is possible, and because the reasons why these donations stopped is not known to me, neither should the issue be discussed here, I'm unable to elaborate on this idea. But it is, nevertheless, something to consider, in my opinion. > As this hardware comes to the end of it's lifecycle, DSA will need to > buy new hardware. To keep up our standards on hardware for core > infrastrucure, DSA will need to spend several 10k USD on new hardware in > the next year. > > @all: do you think it is worth spending large amount of money donated to > Debian to keep our core hardware infrastructure on its current level? Yes, it is. > @all: do you think Debian should do a fundraising campain where we > collect a larger amount of money dedicated to Debian's hardware > infrastructure? This, I'm not sure about. I donated to a number of fundraising campaings by members of the larger free software community, and it filled me with sadness that quite a few of them never reached their goal. That's discouraging both for the project, and for those too, who did donate. I don't want that. So *if* such a campaing is to be made, it needs to set an achievable goal, and it must not be neither the sole source of funding for Debian hardware, nor the biggest part of it. There's a lot more that needs to be done for a campaign to be successful, ranging from making it known and visible, long enough to receive a usable amount of funds, but short enough to not be seen as 'begging', either. It must have a clear goal, a generic "we need hardware, please donate" is not going to cut it - people want to know what their money is used for, and we want to tell them up front too (that's one of the reasons why the work of Debian Auditors is so important, among other things). But alas, we already have fundraising campaigns within the project, so all we need is get the relevant people involved, and help them prepare and drive the campaign (which, of course, includes learning from past campaigns too, and improving on their ways too). And if we do launch a new campaign, we need to ensure that there is coordination between the new and running campaigns, to avoid approaching the same organisations twice, without knowing about the other, and other similar mishaps. > @lucas, @algernon: in your platform you are not stating how you will > handle money requests, and what do you think about using Debian's money > at all. Can you please elaborate? When it comes to financial stuff, I'm bad at it. Luckily, I'm well aware of that, and even better, so is Debian (Constitution 5.1.10). Therefore, my intention is to, if elected DPL, rely on (and possibly delegate, if that seems more useful) trusted members of our project, who are far more experienced and better at these matters than I am. That's not to say I don't want to be involved, quite the contrary! I just know my limits. Nevertheless, the general idea is to continue down the path we're on, and make spending as transparent as possible. Due to my shortcomings mentioned above, to do my job properly, transparency and involving the larger project in decisions is the only option available to me anyway. If elected, this may result in some bumpy times in the beginning, slower reactions and perhaps more bureaucracy than needs be, but in time, it should become a much smoother procedure. I only touched spending, however. As far as fundraising goes, there are existing campaigns, and there's a need for more. I think we can all agree, that coordinating these would be beneficial for everyone involved, and thankfully, we have people more than capable of undertaking that task, and as DPL, a task like this will have my full support. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gldghtn@galadriel.madhouse-project.org
Re: [to all candidates] about a DPL board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Martin Zobel-Helas writes: > in the past i heared several ideas about a Debian Project Leader board > similar to the SPI board. > > So lets imagine the project would have to vote for several members of > this sort of board, with every member being on-board for (lets say) 3y. > > What do you think about this idea? Would it be worth in long term to > establish such a leader board (and therefore a change to our current > constitution) for the Debian Project, or do you think the DPL should > stay a single person? A few years back - even last year! - I might have said I'd support such a board, it is something that's been lingering at the back of my mind for a long, long time. But no, I would not support such an initiative, for a multitude of reasons: First of all, for a board to function well, we need people with similar vision, who can work together. Electing not one, but 3-5 people is not only much harder for the project, it is also much more risky, as there are no guarantees that compatible people will be elected. Trying to guarantee that with the Constitution or by any other means is just adding insult to injury. Over the past year, Zack started the DPL Helpers initiative, which does show some resemblance to a board, in that it takes load off of the DPL, makes some of the work the DPL does more transparent, thus making transitions easier too, and so on and so forth. It has *all* the benefits of a board, with none of the downsides. All three of the current candidates have contributed to Zack's initiative, which, for me, is proof enough that it works. It is still in its infancy, but it already shows great promise, even though it's only a year old. It does not need a change in constitution, makes it easier for all participants to work together better, as they themselves can figure out if they're compatible, and act accordingly, without any harmful bureaucracy involved. Furthermore, I see other issues with a board: how long should members be elected? One year seems short, unless members are reelected (DPL->DPL transitions aren't trivial as it is, imagine if that would need to involve more than two people!). Three years? That's the longest any DPL ever was in service, do we really want to make that the minimum? Three years of commitment is a long time. Granted, one can always step down, but... that just complicates things. We do not need more complex solutions, especially if the solution is for a problem that does not necessarily exist in the first place. I used to think that a board would have tremendous advantages, such as being able to represent Debian in that role at various events and places much more frequently than a single person possibly could. But do we need a board for that? No. We don't. We need people who can do that, and empower them to do it. The DPL Helpers initiative provides a great forum for that, in my opinion. I just don't see anymore what problems a board would solve, that other solutions can't solve better, therefore, I'd rather encourage those initiatives that already show promise. Perhaps I've seen too many otherwise great projects fail in recent years, due to their leadership board being unable to act and respond to outside events in a timely manner. I've been frustrated with leader boards being terribly slow, and argue over miniscule details. I've seen too many of them being far less agile than our project leaders have been. I believe we have a fairly good system, that can use improvements like the DPL Helpers initiative, but it is a good system nevertheless. I see no need to change what works, and what points forward. There's a lot we can and should change about, but none of that require abandoning the DPL role. Granted, one should be willing to take risks, but amending the constitution and transitioning to a board is a risk too high, with no clear benefits. A risk without clear benefits is a risk we should not take. - -- |8] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJRPtcpAAoJEGznDG6LngZEcmkP/2X048uZy2FbDUTW18BtzdAN OBQxZoS8tUj/2+g8ws6U/QUZIebCvy79mNbYwiWD5GHMy4pkRMDEZEOlTiwSOgpk f0J7tyDF7PXA9MuVX+bCPgsZlbDscpL1+Yd+joMzBydGaDVDhhyGpuD50tRBhir1 5QUwiK7WDgx4xxnhTsgLm6Dunfav12LXfkaeVVV5xa89HWhIr2crHa76DPhYbSGg BtematQc3BBpjzNLkY8WWySvDrolUfyDJWL8qh2+Fq0//Ge1MVr1pzIGvcafYOHw dxnPld9y195HY6kN8+L7L0n/tQzoqpNokbBHc2MzA9PC3wIHvG4HVGpiec53r39i pG8tbLu+1PxsQyW6mPAcP6oyYMvC0Sv43RdlkCiGK3VSxCcpkVovpYmKK7FFgUMy Sr71a2Duh44rx74fLbwnDp/F+ZhcA2NWWg9z6hcm0Udh+QNftk0kBpu2U2eKaUao YNcE/TLmEhbqXDnThV3Uxu+NT3OrK/NoOBfa6yVRIFcPnVuezsS9UwzFJW8/ITJS eIYganZO5VQVlane4ygPy4aVLIgF+E3TkKQu84Lu5eROUNTr0zRjtNyRJNUr+5W0 kpGeSmWy4SEtZYUo8PDbioDstiS626N/PCWweiDSr39Pqj9Sd2Sn8qu23Ch/Ibgz Vk0azgXMr2566h183rON =ss5L -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/
Re: Why do you think you are a good candidate for DPL
Martin Zobel-Helas writes: > Why do you think you are a good candidate for the next DPL term? That's a good question, one that I'm not sure I can provide a useful answer for. Not because I have doubts (I don't), but because why *I* think I am a good candidate has little relevance, and is fairly simple anyway (I'll get there in a moment). What counts, is whether others believe that I can do a good job, whether I can handle the goals I set out in my platform, whether I can handle the unexpected too. I know I can, I do this on a smaller scale at work, every day. But that's not all that convincing, is it? Problem is, I can't imagine any situation where anyone could convince me they're fit for a leadership role, unless I've seen them in that exact same position, and seen them do it well. For this reason, I'm not going to go into minute detail on why I think I'm fit for the role. I'd like to believe that my platform, and the answers I'll be giving over the next few weeks will speak for themselves, and all of them together will give you an answer for this question too. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw01hd28@galadriel.madhouse-project.org
Re: trying to do awesome and risking to fail
Hi! Sune Vuorela writes: > So, over the last years I have seen a Debian where it among the people > is much more important to avoid to fail than trying to do awesome > stuff. While I subscribe to the 'avoid failure whenever you can' school of thought, I do not wish to hold on to that thought at all costs. We do need to risk it at times, and that may or may not result in falling flat on our face. If we do fail - so what? We'll learn. Care *must* be taken though, that if things are going to fail, let it do so early, when it hurts less. Or better yet, if it looks like it's going to end badly, look back and see what were wrong, and correct the course. We have tons of eyes in the project, if even a fraction of them cares about a particular project, we'll have quite many opinions, viewponts and ideas, we'll see and know where things go wrong. In short, failure will happen, we have to take that into account, but that should not stop us from doing awesome stuff, whatever that awesome stuff would be. > Focussing on not failing is helping ensuring to stay mediocre. And not > doing awesome. While I believe one can do awesome stuff and not stay mediocre even when trying very hard not to fail, that's a rare thing indeed. > So, how can we make debian do awesome stuff? By not being afraid to try new things. For this, we'll likely need the backing of a DPL who feels the same, because that gives a more comfortable background for others aswell. Perhaps someone who's not bound by years-long exposure to a management style that tries to avoid all kinds of failure. We need initiators who are not afraid of bruises. If that includes the DPL, so much the better! There are a couple of ideas and plans in my platform, that I hope fall into the 'do awesome stuff' category. As far as I see, the plan of focusing much more on non-packaging contributors is one of these risky plans. I can easily see it fail. But nevertheless, I believe it *is* worth the risk, because if it succeeds, that's going to be big. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3pegth9@galadriel.madhouse-project.org
Re: Debian Project Leader Elections 2013: Call for nominations
Debian Project Secretary - Kurt Roeckx writes: > Please make sure that nominations are sent to (or cc:'d to) > debian-vote, and are cryptographically signed. *clears throat* I hereby nominate myself as a prospective DPL. -- |8] pgpPpM0m_KBtU.pgp Description: PGP signature
Re: Debian's trademarks and logos, and their terms of use.
Charles Plessy writes: > In contrast with what we require for the software we distribute, we are > forbidding to use some of our logos for profit. While there are some clear > differences between software and carriers of visual identity, I feel that > there > is a strong mismatch between what we ask and what we give, if we reduce a > software on one side, and Debian's reputation on the other side, to the fruit > of the efforts of their makers. Said differently, I see a contradiction > between forbidding people making money by printing our name on T-shirts, and > requiring that all the software we distribute can be used for profit. There is a huge difference between copyright and trademark. While I like to see my software under a free license, I would not neccessarily want my name to be used by or associated with some of the places where they are used. > I would like to know your position or vision on our trademarks and logos, and, > if you indend to work on that question as a DPL, what would be the key points > of your action. I think all three of us have a similar position, and vision. Allow me to not echo back what Stefano and Wouter have written already: Stefano explained it well what steps we should take, and what work is already being done to update Debian's trademark policy, and Wouter also expressed his concerns, and the dangers of a policy too weak. If elected, I'd ask Stefano to supervise the work he started, and bring it to completion. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obrc1jyi@luthien.mhp
Re: Wouter and Gergely: software monopoly vs diversity
"Eugene V. Lyubimkin" writes: > What is your vision about how many different software pieces can be > supported by Debian as a project for each part of the software stack, > would it be architectures, kernels, init systems, high-level package > managers, desktop environments or something else? In short: as many as there are enough people to support them with. Exceptions do exist, as always. > In other words, would you want Debian: > > a) concentrate more on the things people use most; > b) or give more choices; A little bit of both, as these choices do not always conflict. What people use most, should be the defaults in most cases. But that does not prevent us from offering a choice, either. However, defaults MUST be consistent, and if choosing a new default would kill off the ability to choose, then I would advise against that change, as freedom of choice is in my opinion one of the great strenghts of Debian. However, too much choice is just as bad as none at all: one gets lost in the maze, and it's a pain to maintain such a diverse system in the long run, both for debian developers, and for up- and downstreams alike. Ideally, we should have a balance of choice and maintainability. Where that balance lies, depends on a lot of factors, ranging from the quality of the choices, to the available manpower needed to keep all of them in good shape, and so on and so forth. There is no silver bullet: monopoly is just as bad as too many possible choices. Ideally, we would need to strike a good balance, and have a little bit of both. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vclk1kqu@luthien.mhp
Re: Raising money for Debian
Raphael Hertzog writes: > there's a discussion going on on debian-project about entering an > agreement with DuckDuckGo to get some sort of affiliate commission from > the money that DuckDuckGo would earn from traffic tagged as coming > from Debian. > > 1/ To Wouter and Gergely: this discussion touches several sensitive topics > but you have not taken position... what do you think of the project? I'm afraid I can't answer just yet: I haven't finished reading the thread yet. After a quick glimpse through the thread, I think there are certainly good arguments to accept the offer, but, as others expressed in the thread, there are valid concerns too. Unfortunately, without reading the whole thing, I'd rather not take a position, and catching up on the thread may take a day or two more. > 2/ To all: are there other ways to raise money that we have not yet > explored and that we should try? One idea that comes to my mind, is that we seem to focus a wee-bit too much on raising money at times. While I agree that we do need money, for hardware, travel and sprint sponsorships and a whole lot of other things I have little insight into, there are alternative ways. The problem I see with 'raising money' is that those who donate have little control over how that money is used. While that works for many, it might very well stop others (especially companies) from donating. Transparency helps here, and Stefano's work on this front is very important. But it's not enough, in my opinion. We already seek sponsors for DebConf, and have had events hosted or sponsored by various entities. This kind of donation is something we should focus more in, I believe. Perhaps it's not (entirely) monetary, and is tied to a specific event, but it's still useful, and as far as I can imagine, it might be easier to find sponsors for specific tasks, than to raise money that can be spent in any number of ways. People, especially commercial companies, do like to retain some level of control on what their money is used for. While this is not neccessarily a good thing in every case, it's something we could explore and experiment with more. > 3/ To all: The commercial world is full of such "win-win opportunities". > Some are more obnoxious than other. Are there some that would be > acceptable in the Debian context according to you? Where would you draw > the limit? This one's a tough question. I do not think we should promote either of the examples you gave. Recognise? Yes. But not promote. There's a very thin line between the two, and I admit I have no idea how this could be accomplished. I believe each of these opportunities should be carefully evaluated. As for where to draw the line? I don't know. I have no problem with listing companies as sponsors for DebConf, for example, nor listing sponsors for sprints and BSPs and the like. I would have a problem with a www.debian.org/sponsors page, though. In general, though, I'd draw the line slightly above where the general consensus within the project does. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkaw1lgd@luthien.mhp
Re: About debian-companies
Raphael Hertzog writes: > you might have read that Stefano is trying to organize > discussions/collaboration between companies that have a strategic interest > in Debian: > http://lists.debian.org/debian-companies/ > > Wouter and Gergely, what do you think of this project ? Would you continue > to promote it if elected ? To be honest, I'm a little bit torn on this. Not because I have anything against companies being interested in Debian, especially not if they're contributing to Debian one way or the other. The only issue I have, is that the list is not open. I suppose there are good reasons for that (and off the top of my head, I can think of a few), but to be able to fully support, and continue to promote this effort, I'd need to be convinced that these reasons really are good. That said, I think the effort is a useful one, I'm just not entirely sure this would be the best way to do it. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nt431wj@luthien.mhp
Re: Gergely Nagy: how will you "search for talent and passion"
Thomas Goirand writes: > "search[ing] for talent and passion" is a great goal, but just writing > "The key to my goal is communication" isn't enough for me. So, how will > you do? I have a couple of ideas, including - but not limited to: * As mentioned in a different thread, I'd love to get a "Review & Mentor" team up and running. This would make it smoother to start contributing to Debian, and with a few people working together to mentor new contributors, it'd be easier to spot the ones we can recruit for the tasks that need more manpower. It would also make it less of a burden to find sponsors, and not having to wait weeks or months certainly helps keeping one's passion fueled. The hows are many and diverse: on one hand, we can make the process smoother even without a review & mentor team, see the DebExpo GSoC project, or recent mails on -mentors@. On the other hand, when the software and infrastructure supports it, the task of mentoring & sponsoring can be split up more easily, which would help forming a team. The hardest part is finding enough people for the team, once the infrastructure is in place. I have a few vague ideas how I'd approach the problem, but no bullet-point plan yet. * Local teams and user groups are another way to attract interested people (somewhere on this list, this was already mentioned, probably by Zack), and they have other uses aswell. Having local teams all around the globe is very useful for organising events, be that bug squashing parties, or training or demo sessions touching various areas of Debian (typically those that'd need some more contributors; as a way to spark interest). As part of this, encouraging the origanisation of local hacklabs where there is demand for it (or sparking demand for it!) is another tool in the talent & passion fishing repertoire. As for the hows: convincing people this is a good idea, finding willing ones to take the lead, and find sponsors to host the BSPs and hacklabs. There are numerous people within the project that have experience with some (or even all) of the above, I plan to rely on their input and experience, and go from there, see how we could help them, and how we could lure more people into being interested. * Knowing what kind of different things attract people to Debian is another piece of information we could work with (to strengthen those parts that already work, and pick up those, that would be desirable, but are lacking at the moment). To help with this, I'd approach the NM front - the AMs and new members in particular -, collect information about what the AMs see in prospective members, the initial experience of new members, what prompted them to apply, and so on. Thankfully, a lot of this is already available via the AM reports, and perhaps I'm mistaken, but I do not think we're doing much with the information gained from these. What I'm especially curious about, is what strugges people have, what obstacles they had to overcome to become contributors. These things are yet another area where we could make ourselves more accessible. * Periodic news aimed at prospective contributors, with a little more verbose introduction to the particular piece the news is about, a little more emphasis on attracting new people would be another tool. Why? Because while reading technical news is interesting, in my experience, that rarely sparks interest. A little bit of non-technical, but still relevant content can go a long way. At the same time, we must not abandon the technical news, either, because those are also tremendously useful for other parts of the project: to those who are already involved. * There have been attempts[1] at introducing a "gift" usertag, to mark easy to solve issues, something a new contributor could do in a short time, and both help Debian, and get a bit more familiar with it, too. I'd like to expand on this idea, too, as it would help with Google Code-In organisation aswell, and could provide a steady stream of easy hacks to work on. I believe such easy hacks can be great introductions, as they lead to a successful contribution pretty fast. [1]: http://wiki.debian.org/qa.debian.org/GiftTag * I plan to attend conferences and events myself, but I can't be everywhere, and I'm not the best speaker, either. So I plan to rely on the press & publicity teams to continue their fruitful work, and try to support those who speak on behalf of Debian. Speaking at major events is important, and I hope that we can support and encourage those with the most skill and experience to attend and speak on every suitable occassion. All of the above, though, can only happen if the rest of the project shares at least some of my goals. I can't do it alone, nor do I wish to. I believe we have the tools to improve our com
Re: Finding sponsors for Debian
Since my thoughts have been pretty much summed up far better than I could, I'd like to refer to Stefano's answers, as - apart from the experience bits, as I obviously have no DPL experience - are very much like my own would have been. Stefano Zacchiroli writes: > On Mon, Mar 12, 2012 at 03:16:42AM +0800, Thomas Goirand wrote: >> Over the years, I've always been very surprised to see that there's very >> little money that Debian is able to get. I'm convinced that this >> situation could change with a bit of involvement from the DPL, and that >> such money could help a lot the project. For example, sending open >> letters to big companies, and letting them know that we do accept >> monetary contributions could help. > > Let me start by observing the obvious: attracting money is not a goal > per se; Putting them into good use for Debian is. I'd like to add here, that in my opinion, there are other ways companies can help Debian, not necessarily just plain money (or hardware) donations. Sponsoring the DebConf or sprint travel expenses of their own employees for example is one such way, and perhaps easier to achieve this than to persuade them to donate money, that they don't directly know how will be used. Even if it would be completely transparent what Debian spent its money on, and even if donations could have usage restrictions (I do not know if they can, or if they're desirable at all - I believe they're counter-productive), I'd still find it a little bit easier to persuade a company to sponsor their own people. Of course, this largely depends on which company we're talking about - some can afford to donate in general, and let Debian use that money as it sees fit. Some are smaller, and would like to help Debian in one way or the other, but would like a little bit more control on how that money is spent. Allowing their employees to travel to Debian-related events, or work for Debian during their paid time can be a nice little boost, too. > According to my DPL experience, we have two main chapters in Debian > budget: travel sponsoring and hardware replacement. [...] > For DebConf travel sponsoring, what you are asking for already happens. > The DebConf sponsor team each year go knocking at companies door asking > them to sponsor DebConf. The DPL is de facto a member of the DebConf > sponsoring team, because he/she usually have company contacts and is > happy to share with other team members. > > DebConf travel sponsoring dominates our overall travel sponsoring costs, > so it makes sense to go knocking at companies door yearly as part of > DebConf organization. I don't think it would be useful to do so more > than once per year. Companies would feel split among the different calls > for donations and they would hardly give more. The DPL being already > part of the effort, I don't see margin of improvement on that front > either. I too, agree that it wouldn't be useful to go knocking more than once a year, but - as mentioned above - there's another option: not direct donations, but things like sponsoring one's own employees. That can benefit both Debian (since more people can attend DebConf, for example), and the company (because the event also has the potential of being extremely useful for those participating). They'll know that their money went into 'their' guy, and they still helped Debian in some way. I'm pretty sure this is done already, but perhaps a little more emphasis on this wouldn't hurt - along with what we're doing now, of course. [...] > In more general terms, I think the best way to encourage donations to > Debian is to show to the world that we know how to use the money to > benefit Debian. Nobody wants to donate to a bank. This has been one of > my main motivation to streamline sprint management and standardize the > procedures that give visibility to what we do during sprints: > http://wiki.debian.org/Sprints . > > Showing what we are capable of doing with money has also been a > motivation for me to invest some time on periodic budged reports, an > ongoing task that I've discussed in more details in my platform. This is a task that needs to be continued, indeed. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcm3fo97@luthien.mhp
Re: Gergely and Wouter: the level of independence from other distributions?
Hi! "Eugene V. Lyubimkin" writes: > Do you think Debian project has enough manpower to differ (if needed) > with other major derivatives and major non-derivatives in the important > non-Debian-specific software choices? Probably, yes. But being different just for the sake of it is not something I would like to see (see below for an explanation), let alone encourage. > Would you want Debian to borrow more from and share more with other > distributions for the ease of maintenance and uniformity, or rather > don't look on others and make the choices independently? I'll touch on the sharing part first: I think we're doing a good job there. It could certainly be improved, but nevertheless, I believe that what we do, by working with upstreams (which indirectly helps other distributions aswell), and by continously improving our packaging (from which derivatives benefit a lot: there is a huge amount of packages shipped with Ubuntu, for example, that are pretty much just rebuilds of the Debian package). We also have maintainers who are also maintainers in derivatives, which is also a kind of sharing (and borrowing). As for borrowing.. that's a trickier question. I do not believe we should blindly follow other distributions, but becoming different just for the sake of it is counterproductive. If another distribution comes up with a good idea, we should evaluate it too, and see if we can borrow it, if it's worth borrowing. While less differences between distributions would be welcomed, Debian as a project should maintain its ability to decide its own path to take. If that does not happen to be what other distributions chose, pity. While uniformity and ease of maintainance are lucrative, if that comes with a cost of going against the wishes or ideals of the project, then that's too high a price to pay. Nevertheless, there are things (not neccessarily technical!) other distributions are doing better, from which we could learn. So, in short: I believe we're good on the sharing front (even if there's improvements that could be made), we're not so great when it comes to borrowing, but that's a lot harder task, too. We can improve in both, but that must come as a result of our own desire, not as something that feels forced upon us. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gyjh575@luthien.mhp
Re: how informed should a DPL be?
Paul Wise writes:
> Recent threads have made me concerned about how well informed some of
> our current DPL nominees are about what is going on within Debian.
FWIW, if I say something stupid, or misinformed, please publicly hit me
with a cluebat. I'm very interested in my mistakes being pointed out, so
that I can improve in the future, so please apply the educational stick
to my head as appropriate.
> How well informed should a DPL be about the activity of the Debian
> project?
Reasonably. I don't expect any human being to be completely well
informed, especially not about something as big and diverse as
Debian. If we consider how many lists, forums, channels and other media
there are that one would need to follow to be completely in picture -
it's insane.
I'd expect a reasonably well informed idea about what goes on within and
around the project, but allow for honest mistakes or lack of
knowledge. The rest of the project - especially those involved in the
respective tasks - can correct this deficiency.
> Do you feel you are sufficiently informed about the Debian project?
Yes, otherwise I wouldn't have nominated myself.
> What might be some deficiencies in your understanding of Debian?
> How would you improve that if you were to be elected?
> Same questions for Debian's relationship with the wider free software
> world and with the wider world in general.
Among other things, I have very little insight into Debian's finances,
and money-related areas, for the simple reason that it's neither my area
of expertise, nor of interest. This should be improved if elected DPL,
and I expect that the people already involved would help me get up to
speed, and that I could delegate the work to someone more knowledgable.
Our relationship with upstreams, downstreams and the wider (free
software) world is another area where I'm a little behind of times, I
think. I'm trying my best to fix that, though, by re-reading the
relevant lists and announcements of the past few years.
In all cases, however, my plan is to continue to improve my
understanding both by keeping an eye open, and by actively researching
areas I feel lacking in - whether elected or not, this is something I am
doing.
I'm also open to suggestions as to what knowledges I'm lacking, in which
areas, so that I can fix that. Sadly, I'm not good at figuring out what
I would need to know (or what I do know), therefore I often rely on
others to figure out my shortcomings - they're in a much better position
to do that than I am.
> 1. http://lists.debian.org/debian-vote/2010/03/msg00059.html
This has a few questions that you did not explicitly ask this time,
which I would like to answer nevertheless:
> Which project and external Debian-related communications media do you
> follow? and contribute to? As well as a general list I'm interested in
> specific lists (for eg #debian, #debian-devel, debian-devel@l.d.o,
> debian-project@l.d.o, the Hardware forum on forums.d.n etc).
I'm on #debian-{devel,mentors,qa,java,soc,newmaint}, #debconf and
#debexpo. I'm most active on #-mentors, I believe, but I'm highlighting
the rest too for interesting keywords.
As for lists, I'm subscribed to a ton of lists (including, but not
limited to -devel, -mentors, -bugs-dist, -devel-changes). Most of my
contributions come from reading -bugs-dist, I think.
I do not follow any forums at the moment, nor identi.ca (I do check it
from time to time, but not on a regular basis).
Oh, I also read planet.d.o (and a couple of other planets of various
free software projects).
> How do you see those two lists changing if you become DPL?
I would probably unsubscribe from -devel-changes. -bugs-dist is the
highest traffic media I follow, and it doesn't take up much time. I
developed a very efficient reading habit over the years, and running
through -bugs-dist takes up very little time. Something I could do on
the way to work using a smartphone if I had one.
If elected, I would most probably overcome my dislike towards
smartphones and invest into one, so that those two hours I travel to
work and back each day could be spent more efficiently. (This would also
allow me to subscribe and follow more lists and the like, for which I
find no immediate need right now.)
> Which of these communications media do you feel is important for the
> DPL to read?
-bugs-dist surely isn't, but that's one of the few things I'm not
willing to give up! ;)
In all honesty, I can't tell. There are so many, that following them all
and doing a good job does not seem plausible. However, periodically
skimming through, and/or relying on others to poke me if there's of
immediate interest is more important than trying to keep up with
everything.
The rest of the questions from 2010 have been answered elsewhere, at
least partly, so I won't repeat them here.
--
|8]
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: ht
Re: Gergely and Wouter: on the need of becoming a DPL
Raphael Geissert writes: > Reading zack's platform, it makes me wonder why would you (Gergely and > Wouter) actually need to be elected as a DPL to do what you mention on your > platforms. Because while Zack's regin as DPL for the past two years have been very successful, and there would be a lot of things I'd do the same way (which Wouter even highlighted as being communication), there are others where our goals for this year differ wildly. To explain this, I'll answer your questions in reverse order, as I believe that would be the easiest way to arrive to a conclusion: > * If zack was re-elected, would you follow his initiative to share DPL > activities with others? Yes, I would, to some extent. Sharing the load and building on the knowledge, skill and enthusiasm of others - or, to put it another way: standing on the soulder of giants - is a good way to avoid spreading oneself too thin, and remain effective. A leader, as the name implies, is there to lead, not do everything by himself. > * If not elected, would you pursue your goals anyway? I would do everything within my power to pursue them. It would become considerably more difficult, though, but not impossible. If it's not impossible, it's still worth trying. If the elected DPL happens to share some of the ideas or goals I set forth, then I see no problem with working together to achieve both our goals. However, with Zack wishing to oversee the completion of projects he already started (an understandable desire!), and with his wish to train prospective DPLs and ease future transitions, I doubt he'd have enough time and energy to follow up on my vision too. > * Why do you think you need to be elected as a DPL to do what you propose? Because I have a vision that points further into the future than the other candidates', I believe. It would be difficult to accomplish what I hope to do, without having the tools at hand, and those tools happen to be in the DPL's toolbox: the ability to delegate, to be noticed and perhaps even listened to, and to stand on a higher pedestal from where one can get a better overview of the project as a whole. All of these can be done without being a DPL, but then, even with the help of the DPL, it would take considerably more time and effort, than if I didn't have to go through another channel. Furthermore, there's the question of "why not"? Since both Wouter and myself intend to continue the great things Zack started and did, what would we loose if the DPL transition happend now, and not next year? Zack could still see his pending projects to completion, as he's the one with the most knowledge regarding them, and as such, can remain in control of these: that would also help the next DPL tremendously, and thus, ease the transition. Which in turn, also helps Zack accomplish his goal of training a new DPL, and everybody wins! Even better, this way there's already a successor present, and Zack does not need to worry about making sure that in 2013 we'll have a smooth transition: we can make that happen this year, while sacrificing nothing from either of our goals. I have doubts it'd work as well if it went the other way around. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa3khe05.fsf@algernon.balabit
Re: discouraging discussion styles - any cure?
Hi! Gerfried Fuchs writes: > it happens every now and then, people assume bad faith in mails from > others and call their action silly and active tries to sabotage, and > there are also people who fight for their right to behave like assholes > and belittle scathingly against people that wish for a better > communication style. There are a few ways one can do in situations like this, which one to pursue, largely depends on the situation and the people involved. In every case, however, it is a very important step to maintain a clear head and not fall for the trap, so to say. So a crucial step is to try and calm down both parties, either publicly, or in private (or both, as appropriate). >From my experience, a large number of name-calling stem from misunderstandings and mis-communications. Both can be fixed, and a third party who steps in, and the others can throw the stones at him has remarkably good effects, as the opposing parties do not have to talk directly to each other, and the mediator can calm them both down, and afterwards, gently guide them to an agreement and apologies. I've seen that work, had stones thrown at me, didn't mind. I've seen others do it, worked out nicely in the end. However, this doesn't always work, as this is best done when the discussion can be taken private, to discourage others from throwing yet more fuel onto the fire. On the other hand, I do not believe in a flame-war-free world, either. We do need heated arguments from time to time, and I see nothing wrong with that, as long as it remains civilised and does not resort to name-calling and an insult duel (unless it's in monkey island style ;). > Besides that I would expect from a DPL candidate to lead by example > (hope we can agree on that part), what else do you think you could do to > discorage such behavior and encourage people, in cases of doubt, to > rather simply ask how something might have been meant than assume bad > faith in the others? The best way is to lead by example, indeed. But it's something that everyone else can do, too, not just the DPL. Sometimes this might mean ignoring a few harsh mails, and continue from a saneer point, by asking for clarification, if one party meant this or that instead of what the other understood. Then, if so need be, in case the falming part of the thread continues, one can post there, pointing out that "hey, how about we stop bickering and ASK first, before shooting?" might just have more desirable results. Nevertheless, this is a difficult topic, as pretty much each and every case needs to be handled differently. And unfortunately, I do not have ready made plans, nor cookbooks for the most common situations. One other thing I'd like to mention is that sadly, there will always be voices that try to disrupt, and generally act as complete jerks. There will always be cases where we can't teach them to express their opinions in a less hurtful fashion. In those cases, we need to ignore these, and not let them get under our skin. This is an even more difficult task, as this must not look like we're allowing such behaviour. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehswhfge.fsf@algernon.balabit
Re: More votes in Debian? Any idea for improvement?
Hi! Thomas Goirand writes: > If you see projects like Openstack or oVirt (sorry for the examples > taken from my area of expertise...), they have elections every 6 months > for project leaders in this or that area of the project. > > In Debian, we just elect a DPL, and then we hope that he appoints people > who then can make decisions on the behalf of Debian. My opinion on this is very similar to Zack's and Wouters: technical decisions should be made by the appropriate teams, not by voting, unless absolutely neccessary. There are multiple reasons for that, including, but not limited to: * The teams having more insight into their job than the project as a whole allows them to make better informed decisions more quickly. * We should not bring politics into technical decisions, that's never good. Appointing delegates is often a technical decision, and even if it has other components, the tech part of it is still significant. * Debian is a do-ocracy in many areas, recognising that with delegation is, in my opinion, the right way to do it. Turn it into a vote, and then it will quickly become a talk-ocracy. * Generally, we should trust our teams to do their jobs well. In case of problems, we have ways to fix it (revoking delegations, etc). Reassuring team member positions by a project-wide wrote every year (every 6 months would be even worse!) would just put extra burden on both the Developer body as a whole, and the team members for, I believe, no real gain. > I feel strange that such a big project as Debian appears to work in a > less democratic way than some software which has adopted open governance > (truth, this is the new hype, but still...). There are things that work for other projects, but don't work for us. Excessive voting is one of those things. It works well if you have a small core of about a dozen people or thereabouts. If you have close to a thousand, even if only a third of those actively participate in voting, that's still a huge number. We also have a lot of teams, who just get the job done. I see no reason to hinder their performance by making their position a matter of voting: most likely, they'd be appointed anyway, and we wates time and effort of both the team members, and of the voters too. > I see no reason why we couldn't have more direct appointments for key > positions in Debian. I feel like it would be possible to have more > democratic, ways to do things, with direct votes. I disagree. I believe in do-ocracy, and that it has served us well over the years, and I'm confident it will work in the future too. On the other hand, I've seen projects that strived to be openly governed fall flat to their face and accomplish nothing. Direct votes introduce an unneccessary burden and a bit too much politics into what is almost entirely a technical decision best left to be made by those who work in or close to that area. > Also, on the opposite side, the DPL is currently having to appoint > regularly others, which is only a formal thing and is sometimes a > useless loss of time (maybe Zack can tell a bit more about this in a > better English than mine...). I believe it still takes less time, and only from a handful of people, than a vote would, and the results would be pretty much the same. > What are the improvements in this area that our 2012 candidates foresee? There are of course, shortcomings of the current system (see Zack's explanation), which might be improved upon. The idea of self-determining, non-synchronized time-limited memberships is interesting, but for that to work, we'd need a slightly larger pool of people to work with. That happens to be very much in scope for my plan of encouraging people to work with the core teams, and to make those key positions and teams more attractive. In summary, I find project-wide voting boring and unneccessary. Once or twice a year is more than enough, more would be counter productive. Smaller-scale votes, within teams is another thing, that can work, and can result in improvement, but that has a few prerequisites to function well - see above! -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obs0hheb.fsf@algernon.balabit
Re: Gergely Nagy: enough packaging manpower?
Ansgar Burchardt writes: > while reading algernon's platform I stumbled over the two sentences > "More packages, more packagers? A solved problem" and "Not raw, > packaging manpower - with hundreds of people, we have that covered". > How do you think about the current state of reviewing uploads for > maintainers without upload privileges (for both new packages and updates > to existing packages)? In short: it's poor. While there have been many improvements in that area (the sponsorship-requests pseudo-package, continuing work on mentors.d.n, and so on), the manpower there IS lacking. Finding a sponsor is hard, and often time consuming. Package reviews are a bit better, as many are more willing to review than to sponsor (especially since non-uploading members of the -mentors@ list can review too, there have been and continue to be examples of that, and that's great). This is one of the areas where we need to find motivated people to help with reviews and sponsoring, on a regular basis, because right now, unless the sponsoree can find a team to work with, the whole process becomes very frustrating, very quickly. There are many things we can do to improve the situation, ranging from encouraging more prospective packagers to approach a team first, to things like improvements[1] to DebExpo that would make it easier for both teams and sponsorees to achieve the same thing. I would also love to see a "Review & Mentor" team, something that could work along and with the NM process, whose task would be to do just what the name suggests: reivew packages, help find a sponsor (or act as sponsor, as appropriate) and keep in touch with both sides. It's going to be a challenge to make this happen, but it's definitely something I wish to work on. Nevertheless, I still believe we have a lot of packaging manpower, we just need to organise and use that manpower better, and turn it from "raw packaging manpower" into "collaborative packaging manpower". [1]: http://wiki.debian.org/SummerOfCode2012/Projects#Semantic_Package_Review_Interface_for_mentors.debian.net -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjhchkiq.fsf@algernon.balabit
Re: Gergely Nagy: Disappearing?
Kurt Roeckx writes: > As your platfrom indicates, you have disappeared from the Debian > project before. Some DPLs started with alot of energy, but somewhat > faded during their term and then disappeared. Do you think there > is a chance of this happening to you? No, there is no chance of that happening again, otherwise I wouldn't run for DPL. All of the issues that built up and comulated in my disappearance are gone, and ain't coming back. A lot has changed in the past few years: I learned how to properly manage my time and energies, so that I won't burn out, for example. -- |8] pgpSmL8a2WK9J.pgp Description: PGP signature
Re: Debian Project Leader Elections 2012: Call for nominations
Debian Project Secretary - Kurt Roeckx writes: [...] > Please make sure that nominations are sent to (or cc:'d to) > debian-vote, and are cryptographically signed. Lets make this more interesting than the past election has been! I hereby nominate myself as a prospective DPL. This time, there is no-one forcing my hand, and I will do my utmost to make this year's campaign interesting, and the vote a close one. -- >8] pgpoiGNDVJtBE.pgp Description: PGP signature
Re: Question for the Debate/Candidates
> What Muppet character do you see yourself as, and why? This is a question Yamm wants to answer (even though I took steps to keep it away from this years election, it is still reading the lists while I don't watch), and it is torturing me so much, I have to allow this mail. Sorry about that. THANK YOU, FILTHY SERVANT OF ME, YAMM THE GREAT. NOW HEAR WHAT THY TRUE LEADER SAYS TO THEE! Yamm - that is me - sees itself as Yamm. If Yamm wasn't in the Muppet Show, that's because they didn't realize back then that nothing in this world worth a penny, without Yamm, so they did not contract us. Yamm is THE WORLD. Yamm is so huge, that Earth ran away, and Yamm stayed here in its place, using Gravity to keep Humans on self, and to control them. Yamm is the TRUE LEADER, you see? BUT! Allow Yamm to lead Project Scud, behind the scenes (*h*! that's a secret!!1!), and Yamm will make a Muppet show of Debian. Very funny it will be, Yamm promises! -- Yamm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Non-nomination
Hi! If you remember last year, I was running as a joke-candidate. Truth is, I have a megalomaniac tamagotchi (as you all well know, if you followed -vote last year) called Yamm, who made me run in an attempt to seize power. I am afraid he might try the same thing this year... and without Martin running, and Branden still contemplating his nomination... I might even have a chance of winning! Ouch, that would be terrible. You do NOT want to know Yamm's plans. Really. This year, I do not want to be subjected to the torture of being driven into nomination and writing a platform by a HUGE tamagotchi. I only just recovered from the shock... I don't want that once again. Hence this mail, in which I announce my intention to NOT run in this years competition. This is to stop Yamm. So when it wakes up and tries to drive me into nomination, he won't be able, as I already expressed my wish to not run. So, once again, to make it clear: I, Gergely Nagy, in perfect mental health, express my own wish, which was not forced upon me, but is my own, that I do not want to participate in the Debian Project Leader elections in 2005. -- Gergely Nagy signature.asc Description: This is a digitally signed message part
Re: A(nother) question to the candidates
(Being a fun candidate has the advantage of being able to ignore any said and unsaid rules or agreements and whatnot, so I can answer every mail I want to >;) > I have seen lots of discussions about CDD and splitting up Debian > into a core and more-or-less independent topic specific sections recently. > While I can perfectly understand the motivation behind > these discussions, I have one particular "fear" in this direction. > To the candidates: What do you think how we should > determine which software components go into the > core system, and which have to go into separately provided > "distros"? On which criteria, in our opinion, should > we base those decisions? In my opinion, the default setup should be kept as is - everything is debian core. The separation should be optional, so hardcore users will feel at home, while newer, less experienced ones will use the distros layer. Hm. This is not good. This seems to be a sensical answer. EEEK! HELP! I'M SICK! SOMEONE PLEASE PASS OVER THE PIPE! THANKS! -- Gergelybrush Pipewood
Re: A(nother) question to the candidates
(Being a fun candidate has the advantage of being able to ignore any said and unsaid rules or agreements and whatnot, so I can answer every mail I want to >;) > I have seen lots of discussions about CDD and splitting up Debian > into a core and more-or-less independent topic specific sections recently. > While I can perfectly understand the motivation behind > these discussions, I have one particular "fear" in this direction. > To the candidates: What do you think how we should > determine which software components go into the > core system, and which have to go into separately provided > "distros"? On which criteria, in our opinion, should > we base those decisions? In my opinion, the default setup should be kept as is - everything is debian core. The separation should be optional, so hardcore users will feel at home, while newer, less experienced ones will use the distros layer. Hm. This is not good. This seems to be a sensical answer. EEEK! HELP! I'M SICK! SOMEONE PLEASE PASS OVER THE PIPE! THANKS! -- Gergelybrush Pipewood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Candidate questions/musings
> Do you think it's possible for Debian to have a leader anymore? Yes, definitely. > Recent "leaders" have all been coordinator type people. And while > that's fine... they've all been nice, intelligent, thoughtful people > who are of course very dedicated to the project... none of them seems > to have really done much to take Debian anywhere new and interesting. A leader can't really lead a project as huge as Debian wherever he/she wants to, unless the project agrees and supports it. Nor should all the ideas come from the leader only, we are not a bunch of dumb sheeps, are we? If there is nothing interesting going on in Debian (and I think that's not true, even though I haven't been paying much attention to mailing list in the last couple of months), that's not necessarily the fault of our leader. Besides, without a project leader, a person to contact, who would take Debian seriously? I wouldn't, that's for sure. > Frankly, the most exciting development in Debian I've seen lately is > Bruce Perens' UserLinux, which aims to produce something that would be > much more useful to me in a lot of ways than 13 cd's full of packages > that I'll most likely never use. Not that I'm not grateful for them, > it's really handy to have them, just... I want a coherent core + > aptable addons. AFAICS the project to make it easier to build custom debian based distros would solve this "problem" nicely. (I must say that I like that 13cds - if I need something, it is handy. If I just want to install the core system, I burn the first cd, and if I need something that's not on it, it is still aptable, no problem there) > PS Really, I mean no disrespect to Martin or any other past leaders. >The ones I've met have been very nice individuals. Maybe too nice >to kick some ass and make things happen?:-) Though I'm not a leader, and I hope I won't even get close to it, I'll be happy to kick your ass for even thinking about not having a leader >;] -- Gergelybrush Nagywood Mighty Pirate And Ass Kicker
Re: Candidate questions/musings
> Do you think it's possible for Debian to have a leader anymore? Yes, definitely. > Recent "leaders" have all been coordinator type people. And while > that's fine... they've all been nice, intelligent, thoughtful people > who are of course very dedicated to the project... none of them seems > to have really done much to take Debian anywhere new and interesting. A leader can't really lead a project as huge as Debian wherever he/she wants to, unless the project agrees and supports it. Nor should all the ideas come from the leader only, we are not a bunch of dumb sheeps, are we? If there is nothing interesting going on in Debian (and I think that's not true, even though I haven't been paying much attention to mailing list in the last couple of months), that's not necessarily the fault of our leader. Besides, without a project leader, a person to contact, who would take Debian seriously? I wouldn't, that's for sure. > Frankly, the most exciting development in Debian I've seen lately is > Bruce Perens' UserLinux, which aims to produce something that would be > much more useful to me in a lot of ways than 13 cd's full of packages > that I'll most likely never use. Not that I'm not grateful for them, > it's really handy to have them, just... I want a coherent core + > aptable addons. AFAICS the project to make it easier to build custom debian based distros would solve this "problem" nicely. (I must say that I like that 13cds - if I need something, it is handy. If I just want to install the core system, I burn the first cd, and if I need something that's not on it, it is still aptable, no problem there) > PS Really, I mean no disrespect to Martin or any other past leaders. >The ones I've met have been very nice individuals. Maybe too nice >to kick some ass and make things happen?:-) Though I'm not a leader, and I hope I won't even get close to it, I'll be happy to kick your ass for even thinking about not having a leader >;] -- Gergelybrush Nagywood Mighty Pirate And Ass Kicker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q: guidelines for post-campaign period?
> How about you keep it to summaries of mailing list threads and IRC > conversations or similar? Ideally something self-centered, too, as a > summary of another candidate's position will likely result in the other > candidate feeling that they've been (deliberately?) misrepresented, > which would just result in a lot of extra discussion in a period when > people are supposed to be making decisions. As fun candidate of the year, I take the liberty to disobey. So, in the next few lines I'll summarise the traffic the real candidates made on this list: * Lots of interesting ideas * A bunch of plans * No pointing me and laughing (which is a pity, I did try my best to provoke some finger pointing :P) * No mention of having a tamagotchi. EVIL PEOPLE! HOW DO YOU WANT TO RULE^WLEAD DEBIAN IF YOU CAN'T TAKE CARE OF A CUTE LITTLE TAMA?!? I'd also like to note that we have a choice that is so confident in himself, that he didn't do any campaigning. I'd take it as a sign and vote him over myself (to be honest, I already did). This candidate is, the ever silent, the most confident, the most calm, the least cabalistic.. __ _ _ _ __ ___ _ __ ______ / _| | |_| |__ ___ | '_ \ / _ \| '_ \ / _ \ / _ \| |_ | __| '_ \ / _ \ | | | | (_) | | | | __/ | (_) | _| | |_| | | | __/ |_| |_|\___/|_| |_|\___| \___/|_|\__|_| |_|\___| _ __ _| |__ _ _ / _` | '_ \ / _ \ \ / / _ \ | (_| | |_) | (_) \ V / __/ \__,_|_.__/ \___/ \_/ \___| Well, that was Algernon's Summary, brought to you by yours truly, who is on too many drugs again. (I'm seasick, so I took this pills they were selling in e-mail, 'cos a mighty pirate like myself can't be seasick, can he?) -- Gergelybrush Nagywood
Re: Q: guidelines for post-campaign period?
> How about you keep it to summaries of mailing list threads and IRC > conversations or similar? Ideally something self-centered, too, as a > summary of another candidate's position will likely result in the other > candidate feeling that they've been (deliberately?) misrepresented, > which would just result in a lot of extra discussion in a period when > people are supposed to be making decisions. As fun candidate of the year, I take the liberty to disobey. So, in the next few lines I'll summarise the traffic the real candidates made on this list: * Lots of interesting ideas * A bunch of plans * No pointing me and laughing (which is a pity, I did try my best to provoke some finger pointing :P) * No mention of having a tamagotchi. EVIL PEOPLE! HOW DO YOU WANT TO RULE^WLEAD DEBIAN IF YOU CAN'T TAKE CARE OF A CUTE LITTLE TAMA?!? I'd also like to note that we have a choice that is so confident in himself, that he didn't do any campaigning. I'd take it as a sign and vote him over myself (to be honest, I already did). This candidate is, the ever silent, the most confident, the most calm, the least cabalistic.. __ _ _ _ __ ___ _ __ ______ / _| | |_| |__ ___ | '_ \ / _ \| '_ \ / _ \ / _ \| |_ | __| '_ \ / _ \ | | | | (_) | | | | __/ | (_) | _| | |_| | | | __/ |_| |_|\___/|_| |_|\___| \___/|_|\__|_| |_|\___| _ __ _| |__ _ _ / _` | '_ \ / _ \ \ / / _ \ | (_| | |_) | (_) \ V / __/ \__,_|_.__/ \___/ \_/ \___| Well, that was Algernon's Summary, brought to you by yours truly, who is on too many drugs again. (I'm seasick, so I took this pills they were selling in e-mail, 'cos a mighty pirate like myself can't be seasick, can he?) -- Gergelybrush Nagywood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: still more questions for the candidates
Hi! I resist to allow my tamagotchi to dress in Branden and Martin skins, and answer their questions too... I donot know how longer I can keep him from doing that, though... > I have a tamagotchi too! He's called Foo (I have a limited imagination) Why > is > your tamagotchi more suited to running the project and being world dictator > than mine? > How do I get inside the shopkeeper's safe so I can get that credit note? Ask him for credit, tell him you have an income. He'll got to the safe, and open it (write down how he pushes and pulls the lever(?), you'll need to know that). Then tell him you want to fight the swordmaster. He leaves, you open the safe, by pushing and pulling the lever as the shopkeeper did, and you'll find the credit note. > What do we spend the profit on? We hire costume designers to design outfits for our tamagotchies. (Keeping a tama will be mandatory. Did I forget to say so in my platform?) > What do you see as the greatest weakness of the project? Myself? O:) > What new challenges do you plan to present to the project? If elected, it will be a great challenge to the project to survive >;] Other than that, it is s3kr1t, and I'll only tell my plans to the Cabal, that does not exist (or so the member say). Gotta keep something to do after the elections, right? > Do you believe that if either Branden or Martin are elected instead of you > that > you would be able to work with them to achieve the goals you outline in your > platform[2]? A long long time ago, on a different IRC network, there was a #debian-bugs channel, were Master tbm and some of his minions outlined the Great Debilan Plan.. I was one of the minions then, and I believe, I can still work with him to achieve the goals outlined in my platform. Questions is, do we want to achive every goal I outlined there? :) As for Branden... To work with him, I need his Sodomotron. Yamm won't let me speak with him otherwise *cry* :| -- Gergelybrush Nagywood
Re: still more questions for the candidates
Hi! I resist to allow my tamagotchi to dress in Branden and Martin skins, and answer their questions too... I donot know how longer I can keep him from doing that, though... > I have a tamagotchi too! He's called Foo (I have a limited imagination) Why is > your tamagotchi more suited to running the project and being world dictator > than mine? > How do I get inside the shopkeeper's safe so I can get that credit note? Ask him for credit, tell him you have an income. He'll got to the safe, and open it (write down how he pushes and pulls the lever(?), you'll need to know that). Then tell him you want to fight the swordmaster. He leaves, you open the safe, by pushing and pulling the lever as the shopkeeper did, and you'll find the credit note. > What do we spend the profit on? We hire costume designers to design outfits for our tamagotchies. (Keeping a tama will be mandatory. Did I forget to say so in my platform?) > What do you see as the greatest weakness of the project? Myself? O:) > What new challenges do you plan to present to the project? If elected, it will be a great challenge to the project to survive >;] Other than that, it is s3kr1t, and I'll only tell my plans to the Cabal, that does not exist (or so the member say). Gotta keep something to do after the elections, right? > Do you believe that if either Branden or Martin are elected instead of you that > you would be able to work with them to achieve the goals you outline in your > platform[2]? A long long time ago, on a different IRC network, there was a #debian-bugs channel, were Master tbm and some of his minions outlined the Great Debilan Plan.. I was one of the minions then, and I believe, I can still work with him to achieve the goals outlined in my platform. Questions is, do we want to achive every goal I outlined there? :) As for Branden... To work with him, I need his Sodomotron. Yamm won't let me speak with him otherwise *cry* :| -- Gergelybrush Nagywood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
> A. What do you think is the greatest challenge facing Debian in the > coming year? What would you do as Project Leader to try and meet this > challenge? We have quite a few challenges coming ahead. There is this SCO case: we shouldn't laugh too hard at them, because that makes us look bad. Then, we must find the Precious. Last time it was seen on the finger of George Bush, which is quite worrysome to say the least. Mr. Bush being friends with Evil Companies Producing Non-Free Software, it is our duty to retrieve the Ring and destroy it. It is our duty, because we're the distro with the most strict guidelines, and besides, we have the most talented people too >;) Yet another challenge, is making Debian more popular, an idea was suggested by Amaya (in the form of `Debian needs more women'), which I covered in detail here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00086.html > B. What should the Project Leader's role be when Debian comes into > significant and important conflict with other free software > organizations? (As an example, I'm thinking of the conflict with the > FSF about the DFSG vs. GNU FDL.) I think I partially covered this question in a previous mail, see here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00037.html The same approach can be used to solve conflicts with other organisations. I'm working on an ESR skin, and if someone could tell me who do I need to make a voodoo doll about for the XFree license change, I'd be grateful. > C. Being the Project Leader is a major responsibility. What are the > other Project-related and non-Project-related responsibilities which > would compete for your time, and how would you manage that conflict? I'm the primary author of dpatch2, but that codebase has stabilised, so it's not a too tedious task. Other than that, my most important package is tama, and is a great responsibility. As you can see from a few mails of mine (like http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00089.html), breeding a tamagotchi can be quite dangerous, and needs lots of attention. Just like caring for a project would require similar amounts of care and attention. Sometimes, I'd like to think of Debian as a big family of highly themed tamagotchis... At those times, my World Dictator self is ruling my mind, obviously. How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. > D. People become Debian Maintainers by a complex administrative > process, involving three different folks who have to agree on any new > Maintainer: the Advocate, the Application Manager, and the Accounts > Managers. I'm not interested in the details of how this process > works. My question is: Should the Constitution specify at least who > has the actual formal approval over this process? In other words, > right now it's not clear what the exact lines of authority are. I think our Constitution already specifies who has the final word (DAM), and iirc, and as quoted by Martin, he is a delegate of the DPL. My thinking is, that the line of authority is something like this: Yama (the oversized tamagotchi of mine) spares the life of all who believe in him, so the DPL surviving the apocalypse delegates the DAM. The DAM, so that he doesn't have to do everything by himself, forms the Front Desk, who in turn, delegate the bulk of the job to Application Managers. However, since people suck and nominate^Wapply for fun, the NM Cabal introduced the Advocate step. NM Cabal being the DAM, the Front Desk, the Application Managers and other interested people. Seems pretty clear to me! :) > E. Debian does not have a formal process for removing a delinquent > developer. Should we have one? And if so, what are the sorts of > things for which it would be appropriate to remove a developer? (I'm > not inviting speculation here on what such a process would look like.) Yes we should have one. For violating the DMUP, being rude to users and not doing their job as outlined in the developers reference (hi Marillat), calling tama names, frightening away potential female developers, etc, one would need to face serious consequences. Not necessarily a remove from the project... worse. Taking him to a sail in the caribbean on the Sea Monkey, and making him Governor of a deserted island, which has no animals, only a few plants and lots of rum in a hidden cage. However, you didn't want to know the process, so forget the last two sentences, please. The rest, I hope, answers your question. (Though, suggestions to extend my list of BadThingsToDo(tm) are welcome) -- Gergelybrush Nagywood
Re: tb's questions for the candidates
> A. What do you think is the greatest challenge facing Debian in the > coming year? What would you do as Project Leader to try and meet this > challenge? We have quite a few challenges coming ahead. There is this SCO case: we shouldn't laugh too hard at them, because that makes us look bad. Then, we must find the Precious. Last time it was seen on the finger of George Bush, which is quite worrysome to say the least. Mr. Bush being friends with Evil Companies Producing Non-Free Software, it is our duty to retrieve the Ring and destroy it. It is our duty, because we're the distro with the most strict guidelines, and besides, we have the most talented people too >;) Yet another challenge, is making Debian more popular, an idea was suggested by Amaya (in the form of `Debian needs more women'), which I covered in detail here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00086.html > B. What should the Project Leader's role be when Debian comes into > significant and important conflict with other free software > organizations? (As an example, I'm thinking of the conflict with the > FSF about the DFSG vs. GNU FDL.) I think I partially covered this question in a previous mail, see here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00037.html The same approach can be used to solve conflicts with other organisations. I'm working on an ESR skin, and if someone could tell me who do I need to make a voodoo doll about for the XFree license change, I'd be grateful. > C. Being the Project Leader is a major responsibility. What are the > other Project-related and non-Project-related responsibilities which > would compete for your time, and how would you manage that conflict? I'm the primary author of dpatch2, but that codebase has stabilised, so it's not a too tedious task. Other than that, my most important package is tama, and is a great responsibility. As you can see from a few mails of mine (like http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00089.html), breeding a tamagotchi can be quite dangerous, and needs lots of attention. Just like caring for a project would require similar amounts of care and attention. Sometimes, I'd like to think of Debian as a big family of highly themed tamagotchis... At those times, my World Dictator self is ruling my mind, obviously. How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. > D. People become Debian Maintainers by a complex administrative > process, involving three different folks who have to agree on any new > Maintainer: the Advocate, the Application Manager, and the Accounts > Managers. I'm not interested in the details of how this process > works. My question is: Should the Constitution specify at least who > has the actual formal approval over this process? In other words, > right now it's not clear what the exact lines of authority are. I think our Constitution already specifies who has the final word (DAM), and iirc, and as quoted by Martin, he is a delegate of the DPL. My thinking is, that the line of authority is something like this: Yama (the oversized tamagotchi of mine) spares the life of all who believe in him, so the DPL surviving the apocalypse delegates the DAM. The DAM, so that he doesn't have to do everything by himself, forms the Front Desk, who in turn, delegate the bulk of the job to Application Managers. However, since people suck and nominate^Wapply for fun, the NM Cabal introduced the Advocate step. NM Cabal being the DAM, the Front Desk, the Application Managers and other interested people. Seems pretty clear to me! :) > E. Debian does not have a formal process for removing a delinquent > developer. Should we have one? And if so, what are the sorts of > things for which it would be appropriate to remove a developer? (I'm > not inviting speculation here on what such a process would look like.) Yes we should have one. For violating the DMUP, being rude to users and not doing their job as outlined in the developers reference (hi Marillat), calling tama names, frightening away potential female developers, etc, one would need to face serious consequences. Not necessarily a remove from the project... worse. Taking him to a sail in the caribbean on the Sea Monkey, and making him Governor of a deserted island, which has no animals, only a few plants and lots of rum in a hidden cage. However, you didn't want to know the process, so forget the last two sentences, please. The rest, I hope, answers your question. (Though, suggestions to extend my list of BadThingsToDo(tm) are welcome) -- Gergelybrush Nagywood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Just a single Question for the Candidates
> > > As a female hacker/geek/DD I find myself more and more concerned about > > > the gender ratio in the Debian Developer/User comunity. How can we say > > > make a "Universal" OS when it's do scarcely related to half the > > > population of the world... I think we all agree we want to see more > > > women involved in or using Debian. > > > > Indeed, we do! All these Debian parties seem to look like gay parties > > (not that I have anything wrong with gay people, as long as they don't > > try to molest me. Even more, I definitely would not have any problem > > looking over the lesbian movie collection the all-time DPL has access to > > - as some nasty rumours say) > > > You *PROMISED* me that I could molest you in return for my vote! I feel > BETRAYED! You *TOLD* me you were a bi-girl! Stupid internet thing! I'm sooo going to drag it into the recycle bin..! I will DELETE ALL OF YOU! HA! Now apologize! Or else...!1!! (I'll do the developer dance) -- Gergely `Ballmer' Nagy
