Re: General Resolution: Richard Stallman's readmission to the FSF board
Hi, On Fri, Mar 26, 2021 at 1:26 PM Dominik George wrote: > > > The Debian Project make an official statement, along the lines of: > If you want the project to issue a statement, the exact statement should be in the GR, so that people that vote know what they are voting for. -- Besos, Marga
Re: Willingness to share a position statement?
Hi, On Thu, Mar 25, 2021 at 6:59 PM Roberto C. Sánchez wrote: > On Thu, Mar 25, 2021 at 06:15:27PM +0100, Martin Pitt wrote: > > Exactly -- if this is an open vote, I'm afraid that would merely force a > > (possibly) large number of Debian members to not vote at all. Honestly, > in that > > light I haven't made up my mind yet either what to do.. > > > It also means that those who do not vote are by implication considered > to be in opposition. Not at all. In every Debian GR there's a lot of people that don't vote. Maybe they didn't care, maybe they were busy with other stuff in their lives, maybe they just forgot to vote. Not voting doesn't mean you are in opposition. > Essentially, voting in this GR is implicitly > compulsory and there is only one correct way to vote. Also not true. The GR is to vote whether Debian issues a statement about this or not. If you think Debian shouldn't issue a statement about this, that's a totally valid opinion. The point of the GR is to gauge whether the majority of DDs think that the project should or should not issue a statement. We won't know until the voting is over whether that's the case. > Why not dispense with the vote and simply have the DPL sign for the > project? Then at least those who are not in agreement will not feel > directly targeted, though they may disagree with the outcome. > There's many reasons why someone might decide to be against such a statement, and I don't expect people to be "targeted" because of that, anymore that they could be targeted because they voted one way or the other in any of the past GRs. -- Besos, Marga
Re: Question to Brian: Why do you need to be DPL to set up foundations?
Hi, On Fri, Mar 20, 2020 at 11:47 PM Brian Gupta wrote: > On Fri, Mar 20, 2020 at 7:45 AM Steve McIntyre wrote: > > On Fri, Mar 20, 2020 at 09:41:33AM +0100, Enrico Zini wrote: > > >As an example of a voting options that I am considering ad that does not > > >fit with your proposals above, I would very likely vote for you above > > >NOTA for a pure DPL election, and I would very likely vote in favour of > > >a GR option to create a Debian Foundation. I would however rank you > > >below NOTA if you insisted in conflating the two, as I cannot endorse > > >what I see as a misuse of our voting system. You would however > > >incorrectly interpret my vote as a vote against the idea of a Debian > > >Foundation, underestimating support for something you care about. > > > > I hate to just say "me too" on a thread like this, but Enrico has > > totally captured my thinking here. > > > > "Me too". > I'll add my "Me too" here as well. I think I'm in favour of the Debian Foundation (although I'd like to be more informed about this). But I'm definitely NOT in favor of co-opting the DPL election to vote for it, because you dislike GRs. I intend to vote for you below NOTA because of this reason, not because I don't think exploring the Debian Foundation idea is worth the time. > Thank you both. I appreciate the feedback and understand that you will > vote for > what you believe is best for the project. I am largely running to start > setting > up Debian Foundations as a DPL. If you can support that, please vote for > me. If > you don't want me to work on establishing these Foundations, or don't want > me > to be DPL, rank others above me. I'll totally understand. DPL elections are > what they are. > How can we tell you that we do want to explore the Foundation idea, but we don't want to have a DPL that's not taking care of the rest of the DPL responsibilities? I want a DPL that sets a vision for the project, that helps developers find a common cause for collaborating and moving the project ahead. It doesn't seem that this is your goal and so I don't feel comfortable voting for you above NOTA. -- Besos, Marga
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Hi, > === BEGIN GR TEXT === > > Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > > All appearances of the word Chairman shall be replaced with the word Chair. > > === END GR TEXT === It's been 18 days since the GR was proposed and seconded. I'd like to now call for votes on this resolution. Thanks. -- Marga signature.asc Description: Digital signature
GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
The Debian Constitution is very well written, in a way that is almost completely ungendered. The only gendered word left is the Chairman of the Technical Committee. There is no reason for this position to be gendered. Ungendered alternatives for Chairman are Chair and Chairperson. While both work, Chair is simpler and shorter. I'm therefore proposing the following General Resolution: === BEGIN GR TEXT === Title: Replace "Chairman" with "Chair" throughout the Debian Constitution All appearances of the word Chairman shall be replaced with the word Chair. === END GR TEXT === This change can be applied by a simple sed command (s/Chairman/Chair/g). I'm attaching the diff between the current constitution document and the output of said sed command to make it explicit that no other changes are intended. -- Regards, Marga --- constitution.wml 2016-02-25 08:03:04.0 +0100 +++ constitution.new.wml 2016-07-08 15:18:41.857474553 +0200 @@ -37,7 +37,7 @@ The Project Leader; - The Technical Committee and/or its Chairman; + The Technical Committee and/or its Chair; The individual Developer working on a particular task; @@ -69,7 +69,7 @@ A person may hold several posts, except that the Project Leader, -Project Secretary and the Chairman of the Technical Committee must +Project Secretary and the Chair of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. @@ -460,10 +460,10 @@ -Appoint the Chairman of the Technical Committee. +Appoint the Chair of the Technical Committee. - The Chairman is elected by the Committee from its members. All + The Chair is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members @@ -476,10 +476,10 @@ -The Chairman can stand in for the Leader, together with the +The Chair can stand in for the Leader, together with the Secretary -As detailed in §7.1(2), the Chairman of the Technical +As detailed in §7.1(2), the Chair of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. @@ -561,10 +561,10 @@ Details regarding voting -The Chairman has a casting vote. When the Technical Committee +The Chair has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are -the Chairman, in which case they may use only their casting +the Chair, in which case they may use only their casting vote). @@ -627,10 +627,10 @@ -Can stand in for the Leader, together with the Chairman of the +Can stand in for the Leader, together with the Chair of the Technical Committee. -If there is no Project Leader then the Chairman of the +If there is no Project Leader then the Chair of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. @@ -658,7 +658,7 @@ If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the -decision may be made or delegated by the Chairman of the Technical +decision may be made or delegated by the Chair of the Technical Committee, as Acting Secretary. The Project Secretary's term of office is 1 year, at which point @@ -671,7 +671,7 @@ Developers. When acting together to stand in for an absent Project Leader the -Chairman of the Technical Committee and the Project Secretary should +Chair of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. signature.asc Description: Digital signature
Re: [Call for seconds] GR: diversity statement for the Debian Project
I know it's late and repetitive, but still... > TEXT TO BE VOTED STARTS HERE > > The Debian Project welcomes and encourages participation by everyone. > > No matter how you identify yourself or how others perceive you: we > welcome you. We welcome contributions from everyone as long as they > interact constructively with our community. > > While much of the work for our project is technical in nature, we value > and encourage contributions from those with expertise in other areas, > and welcome them into our community. > > TEXT TO BE VOTED ENDS HERE Seconded! Thanks to everyone who participated in the discussion that led to creating such a beautiful statement! It's a work of art. -- Love, Marga signature.asc Description: Digital signature
Re: What exactly is this GR supposed to do?
On Wed, Sep 15, 2010 at 11:45 AM, Bernhard R. Link wrote: > My main problem with this text is that while it may fit to the current > realities, it makes no sense from a formalistic point of view, as large > parts of the text seem to imply there was no way for non-packagers yet > and there were no procedures for that. Answering the subject question will probably clear the whole thing. This GR is supposed to show if there is or is not project wide consensus regarding giving non-packagers voting righ...@debian.org addresses, without giving them upload rights. This is something that is currently possible, and the GR doesn't actually establish any processes. It only encourages DAM to do it. This is all due to the fact that DAM had already tried something along these lines and was stopped, due mainly to a problem in communication. So, this is a start over, saying that the project acknowleges and supports DAMs in implementing this. In other words, the GR is not actually needed, it's just a show of support. And I wholeheartedly support it. -- Besos, Marga -- 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/aanlktinymapdd8ekuc5ubj7q2n88ea09dt=owug7u...@mail.gmail.com
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 3:52 PM, Marcelo E. Magallon wrote: > You say it would be easier if you were DPL. Why do you think > this is the case? It is inevitable that people will take you more seriously when you are the appointed leader than if you are just a random developer. But also, the ability to delegate someone to do something, which is one of the few things that DPL can actually do, could help into establishing the different teams that would have to be put together. > Put in a different perspective, of the things you mention, > what's harder to do (and why) if you don't have DPL status? Many of those tasks could be done by anybody. Doing them all at once is not possible, because time is finite. So, by being DPL, I could delegate to the right teams to get the tasks done. By being just one more DD, I'd have to choose one project and do only that one. Changing the way we handle membership (that I listed as a possible way to reaching more people) is something that is *not* part of my DPL plans, it requires going through a GR that I think should be pushed by the appropriate people (DAM and FD). > The questions are not purely rethorical: I do believe you are > identifying a larger and more complex issue within Debian, one > where there's — from my POV — no agreement about whether or not > it is an actual *problem* in the organization and if it is, what > the solution looks like. Uhm, I think that the lack of enough people is an identified problem by most of the developer community. The ideas on how to fix this lack of enough people may vary, but fact that we need to somehow get more people to help I think it's pretty established. > (and yes, you could argue that I'm bordering on the question of > what do we need a DPL for, but I don't really want to go there) We need the DPL to lead. It's not possible for one person to do everything, we need a leader that manages to get the developers to work together on common goals, so that it's not just a one-person-show, but a project-wide-effort. > If we agree that these tasks do not need DPL status, and if you > are *not* elected DPL, will you try to push forward the things > you mention? I'm not sure. if I am not elected DPL, most probably I will devote as much time as possible on getting squeeze ready for release. But I might try to get the ball rolling for one or two of the ideas listed in my platform. >> * Have a constant contest of bug-fixer-of-the-month and >> bug-reporter-of-the-month. This means listing people and the >> bugs they fixed and/or reported (I consider reporting GOOD bugs >> a very important task for a good release). If possible, give >> the winners of each month some prize (t-shirt, mug, etc), if >> not possible, at least list them in a hall of fame page. > Just for the record, I think this is a very slippery slope. I'm not sure why you think so, but I do acknowledge that this is a hard thing to implement. I'd like this contest to be fair and to be above all about making Debian better, not about personal glory, some limitations would need to be implemented so that nobody tries to abuse it. However, if there are well kept rules, I think that it could mean quite a lot of motivation for a lot of people. I'm open to suggestions on how to make this better and less slippery. -- Besos, Marga -- 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/o2me8bbf0361004011439k9554c50cy61fae1579a353...@mail.gmail.com
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 12:50 PM, Marcelo E. Magallon wrote: > Simple question: How? > > (in case it's not clear: since you seem to think it's part of > the DPL's responsabilities, how do you plan to attract people to > help with these things?) I do not think it's part of the DPL responsibilities. I do think that it's something that Debian needs and that doing it with the DPL hat on is going to make it easier, it's not a requirement (most stuff that DPL candidates list as stuff they'd like to do, do not *require* being DPL, but it helps) I've stated some "hows" on my platform and on other mails during the campaign. There are many things that could be done, here is a small list that could grow larger: -*- For bugs/package contributors: * Have a constant contest of bug-fixer-of-the-month and bug-reporter-of-the-month. This means listing people and the bugs they fixed and/or reported (I consider reporting GOOD bugs a very important task for a good release). If possible, give the winners of each month some prize (t-shirt, mug, etc), if not possible, at least list them in a hall of fame page. * Have two separate "How to help" web pages, one for DDs and one for non-DDs, where all teams can list the tasks that they need help with and how to accomplish them. Give these pages as much visibility as possible. For artists: * Have some centralized place where artists can contribute their designs and where users can get those designs to have a "cooler" look on their Debian system. * Give more recognition to artists that contribute to make Debian Art. Maybe even @debian.org address and the right to vote, to the ones that are committed to Debian. For documentators / translators: * Give more recognition to the work done, as in @debian.org address and the right to vote in elections, even if no package upload rights are given. For everybody: * Make a "Debian/Rules" campaign, with web-banners (for blogs and the like), t-shirts, and as many other merchandise as can be imagined, aiming to replace the image that Debian is too difficult. -*- These are just some scattered ideas, I'm sure that many more good ideas are floating in other people's minds, and if I'm elected I'd be happy to apply them as well. The important point is to really focus on reaching out and make Debian more welcoming towards more people. -- Besos, Marga -- 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/v2ke8bbf0361004011100y237ae384x491876d6a4e53...@mail.gmail.com
Re: Question to all Candidates: we want more, aren't we?
On Thu, Apr 1, 2010 at 4:57 AM, Frank Lin PIAT wrote: > Debian project raise it's expectation every year: higher quality, more > package, more architectures, more Desktops, etc... (cool). > > How do we face the challenge to do more every year? There are two important things involved: improve our way of working with tools that make it easier to maintain and improve the quality of our packages, and get more people to help us do our jobs. > What would you do about it, as a DPL? As I've already said, I will focus a lot on tying to get more people to help Debian, not necessarily through becoming Debian Developers. By being more welcoming towards the help of non-DD contributors, we could recruit the help of more people, thus reducing the current workload on the developers. One important example is fixing bugs. Developers spend quite a lot of time fixing bugs, and most of the time you don't need to be a DD to fix those bugs, anybody can help out fixing more bugs. Another example is the non-code parts of Debian, like documentation or artwork. Most developers don't have enough time for, or maybe just don't care enough about, these areas; we could definitely use the help of people that are not so code-oriented in order to improve the overall Debian experience. In general, the only way to keep up is to recruit more people, and I plan to work on that. -- Besos, Marga -- 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/j2ie8bbf0361004010724qfcfbfbd4u7189479ba90dd...@mail.gmail.com
Re: Questions for all candidates: decentralization of power
On Sun, Mar 28, 2010 at 3:41 PM, Clint Adams wrote: > Well, in the paid employment part of my life, I have been put in > positions where I have needed to work with people I disliked, and > it is not considered professional to refuse on those grounds. Indeed, I guess most of us have gone through similar situations. The difference is mainly what you are already emphasizing: in paid employment, you get paid for your work. In volunteer work, you do it because you want to, nobody can force you to work with someone you don't like, you can just walk away and stop working on that area of the project. > Would you consider it appropriate me to refuse to acknowledge > bugs or patches from anyone I consider to be a bad person? > If not, why would it be appropriate for someone to refuse to > collaborate in other ways? I don't think that refusing to fix a bug is comparable to refusing to work on the same team as someone else. > We theoretically all want good things for Debian here, even > if we disagree on most of the details. Letting groups of > people with privileged access maintain their own membership > creates a power imbalance that I believe has led to much > trouble in the past. I think it forms cliques and > cabals, and encourages territoriality. > > Do you disagree? No, I don't disagree. I would very much prefer that all teams were open and that even taking into account personal differences people could be able to work together towards a common goal. However, I realize that it's not an easy problem to solve, because if the DPL (or whoever is delegated by the DPL to do this) goes around imposing members to teams, or switching members willy-nilly, it would definitely lead to a lot of frustration and resignations. I think that the DPL can talk to the involved parties and make some recommendations, but anything more forceful would be received with a lot of resistance and lead to loss of people. So, I once again turn the question to you, since this was what I intended to ask before, but didn't get the reply I wanted. If you were elected DPL, how would you go about "supervising" team membership? -- Besos, Marga -- 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/e8bbf0361003291242xeb129cbr4a60b78cfc3a6...@mail.gmail.com
Re: planet.debian.org is RC buggy (?)
On Sat, Mar 27, 2010 at 9:39 AM, Frank Lin PIAT wrote: > planet.d.o has became one of the most visible media for Debian, if not > the most visible one. Do you think it is a good thing? As has been already said, I'm not sure it's the most visible media. If it is, it's probably because we are failing to communicate properly by other means, and we should work on improving other areas of communication, not on stopping planet. > DFSG / rc-buggy > ¨¨¨ > I consider blogs as non-free, proprietary material (a very few have a > proper license, the "distribution" media s*cks anyway). > > Breaks DFSG #1: A document (HowTo...) published on planet can't be > distributed in Debian main. Is this a problem? > > Breaks DFSG #3: Derived work aren't allowed. In the few case where it is > legally possible, it is difficult to merge and publish the updated > version. Is this a problem? > > Breaks DFSG #2: No source for stuffs like charts and graphs (HTML is a > valid source here). Is this a problem? As has been already pointed out (sorry I got late to the thread), mailing lists suffer from the same issue. Blogs and mailing lists are just two different forms of communications, and I don't think that either of them should be stopped because the authors retain their copyrights. > Opacity > ¨¨¨ > Replying to a blog entry is very difficult. The replies and the original > posted aren't available side-by-side. The comments aren't available on > Debian planet (a kind of censorship). Actually, some blog even forbid > comments! Is this a problem? No, it's not a problem. People can do whatever they want with their blogs. If they don't want comments, they'll receive feedback some other way, or they won't, but that's not censorship. > The content isn't archived. Is this a problem? a feature? All important content should be also posted somewhere else. Either a mailing list, a wiki page, a documentation file inside a package, or whatever is appropriate. Unimportant information doesn't need to get archived. > Community > ¨ > Do you think Debian Planet reflects the fact that Debian is a community > where people collaborate? Do you think planet encourage collaboration? A little bit. The main point of having a planet is being able to quickly "see" what the other developers are up to, be it personal or project related. When it's project related, sometimes it helps by getting more people involved or spreading some news. However, this is only a side effect, not the core of the planet. > Do you think Debian Planet reflects the fact that Debian encourages to > constitute teams? Do you think planet encourage that? I don't, but I don't think it's relevant to what planet is for. > Do you see a shift in recognizing people for their communication skill > (and/or committed time to communicate), rather that their actual work? No. > What would you suggest and/or do? Nothing regarding planet. I *DO* want to improve on communication. Giving more visibility both to the DeveloperNews and to the news.debian.net sites, and having more information available to users. -- Besos, Marga -- 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/e8bbf0361003291228x4e09cf78h705454af0b0a8...@mail.gmail.com
Re: Question to all candidates: DPL's role in important package maintenance
On Sat, Mar 27, 2010 at 8:27 PM, Kumar Appaiah wrote: > My question to you is, do you envision a role for the DPL in fixing > such inadequate maintenance of important packages, or are you of the > opinion that is it up to the affected Debian "community" to stop > whining and step up with some action themselves? I think my view is somewhat in the middle. I do not think that the DPL should be constantly checking on every maintainer or team in order to see if their job is being done correctly, or meddle with people that are generally doing their job right. However, when such an issue is brought to the DPL attention, I believe that it's part of the DPL role to help in finding the solution that's best for Debian, acting as a sort of mediator. In the particular case of the Python packages that was linked, I agree that the correct place to bring the issue to was the tech ctte, but keeping the DPL involved was also a good idea, because the DPL can help by organizing meetings and the like. Regarding your second question, posted to zack: > The method adopted for > resolution of this conflict has, for better or for worse, happened > "behind-the-scenes". Now, some in the project feel that this is the > best way to avoid a conflagration of sorts, but others feel that this > "back channel" approach does not augur well for a project which > strives to adopt open procedures. Would you, as DPL, facilitate such > negotiations in the open (for instance, on a publicly viewable mailing > list), or under wraps? I've been thinking about this myself, for a while. If I'm elected, I'd like to have a most viewable point of contact that goes through RT or a similar interface, so that requests are easy to track and follow. I'm not sure if the current installation of RT for Debian would be well suited for this purpose, but in case it isn't, it's probably easy to find one solution that is well suited I'm also not sure if redirecting leader@ to that system would be alright, because it might break an expectation of privacy from certain people. But I'd definitely like to have an "open by default" policy, and have "closed" conversations only when the subject of the conversation requires it. -- Besos, Marga -- 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/e8bbf0361003291203r9400a3er7dc2791d15e6f...@mail.gmail.com
Re: Question about membership.
On Fri, Mar 26, 2010 at 10:02 PM, Charles Plessy wrote: >> * Do you need to come up with a GR to change membership procedures, or is >> there >> a different way? > > I will cast a GR if I think it is needed. If I am wrong, the result will be > NOTA, and I will resign as DPL. You'd really resign as DPL if a certain GR that you wanted was not passed? I think, once again, that you are mistaking the role of the DPL. If you were to be elected, it'd mean that enough people had wanted you to lead them. What would be the sense in resigning just because a certain GR is not passed? Being a DPL means leading a community, it doesn't mean that whatever you think is what the community wants. I had said before that I'd vote for all the other candidates. I was giving you the benefit of the doubt, because of the work you've done on DebianMed. However, you've proved more than once that your opinion on the role of the DPL is way to different than mine, so I have made up my mind and decided that I will not be voting for you. -- Besos, Marga -- 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/e8bbf0361003271342y55e04bd0yae8949d259a18...@mail.gmail.com
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
On Thu, Mar 25, 2010 at 1:55 PM, Hector Oron wrote: > Secondly, I was wondering how Debian could make it easier for people > to contribute than other (derivatives and non-derivatives) > distributions. I came up with a really nice draft howto[1] which I > would like to bring up to your attention, so the basic question would > be what do you think you could do to make contributions paths easier > (take in account not all teams, groups follow such community > guidelines) This was already mentioned on another thread. The Community Guidelines were drafted by Enrico. He doesn't want to enforce this as a Code of Conduct, they are just guidelines. I do like these Community Guidelines, and I think that zack's idea of asking people in NM to read them and agree to them is a good first step. I would like to make them more widely known, but I've sensed that there's a general anti-CoC feeling, so actively enforcing them might be hard. -- Besos, Marga -- 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/e8bbf0361003251645s16f066edt56d1b7fe8b10...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 2:17 PM, Raphael Hertzog wrote: > You got me wrong. I don't want to change our processes to force people to > adopt new tools. I want to change our processes so that it's easier to > complete far-reaching projects: in my case, it includes everything from > working on dpkg-source to ensuring that the new formats can be used in > sid. In other cases, it can be modify our infrastructure to collect debug > information and make it available as .ddebs, or maybe modify our > infrastructure so that we can provide updated translations in point > releases, etc. Well, I really don't see a way. Take for example when the Homepage field was added as another field in the control file instead of being in the description. This is a very easy switch, and I guess most packages that have had an upload since then have updated that. This became a standard almost as soon as it was done, because it was easy to adopt and technically better. The change in dpkg is like the other extreme. It's something that implies a lot of things to take into account, a lot of changes, and the documentation is not clear enough (I've looked at the wiki and at the links in the wiki, but there's no simple centralized howto for people to follow). The processes are already established: when something useful is adopted by enough people, it enters policy, first as a should, then as a must. Meanwhile, lintian first informs and then warns about such situation. The problem with the dpkg example is that a lot of people are still not willing to do the migration, and I don't think this can be changed through "processes". >> Now, I do find very interesting this question very interesting. One >> thing is to be more open to new ideas. Another thing is to encourage >> people to try new things. It's mostly a cultural thing, we used to >> have a culture of innovation and now we don't. We need to bring it >> back, but I don't see an easy way for this. I'll ponder some more >> about this. > > Do you believe that our NM process could be responsible of this by > unvoluntarily favoring packagers over developers? Uhm, that's a very hard question. I do believe that the NM process favors patient people over brilliant people. But I'm not sure what you are referring to with "developers". In any case, I wouldn't say that the NM process is the reason why we don't have a culture of innovation. I think there may have been too many flamewars about people introducing changes, so much that it could be that some developers don't like to introduce too innovative changes because they fear they'd be flamed for them. It could also be that other fronts have been better at attracting people with novel ideas than we have been. I find it very hard to find the reason for the situation and to propose changes. However, I think that in order to make Debian great we should fix this. -- Besos, Marga -- 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/e8bbf0361003251039j32b973a8q6813484f00d79...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 7:22 AM, Raphael Hertzog wrote: > 1/ Do you believe that it's a good move to standardize our packaging tools? > (example: debhelper is almost standard, quilt is gaining status of the > standard patch system thanks to the new source format) I do not think that we should force a standard. I think the best way to come to a standard is when the big majority chooses to go with it. What we may do is have clear documentation that state that there is a preferred way of doing things, and so new people will do them that way. However, imposing standards on people that are already working in some other way would only bring flamewars and frustration. The most important way of establishing standards is through common use, and then through policy. Many standards have been first introduced as a suggestion and then turned into an obligation in our policy, and that's how they become real standards. > 2/ If yes, what would be the next thing that it would be good to try to > standardize/uniformize? I think (hope) that in the future there's going to be some convergence regarding VCSs. However, it won't happen through someone deciding that one of them is the right one. It will happen when most of us decide to choose one in particular, and it will probably take some more years. > 3/ Do you have any preference on the tools that we should try to > standardize on (which source format/patch system, dh7/CDBS/yada/etc., > VCS helper, etc.)? No. I don't think that we should _try_ to standardize. > 4/ Organizing changes that have an impact on (a large part of|all) the > archive is very difficult: > [...] > How can we change our processes so that doing/organizing such changes > is less of a burden? The only way is to make it easy and rewarding for people to adopt new tools. I don't think there's any kind of bureaucracy that would make people more willing to change their way of working. Only technical advantages and easy migrations paths work. > 5/ I have the feeling that Debian is innovating less than it used to do. > We are more often followers rather than leaders. > Do you share that feeling? > What shall we do to make that change? I definitely share the feeling. I also definitely don't think that imposing standards is the way to become innovative. Now, I do find very interesting this question very interesting. One thing is to be more open to new ideas. Another thing is to encourage people to try new things. It's mostly a cultural thing, we used to have a culture of innovation and now we don't. We need to bring it back, but I don't see an easy way for this. I'll ponder some more about this. In any case, I think this question deserves its own thread. -- Besos, Marga -- 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/e8bbf0361003250843g791611eem6f321c3dc81a1...@mail.gmail.com
Re: Question about membership.
On Wed, Mar 24, 2010 at 9:17 PM, Charles Plessy wrote: > Following the ‘Membership procedures’ GR, discussion on membership were > started > after the Lenny release, but eventually stopped. In this thread it was > proposed > to trust DDs to nominate other members and I found the idea very interesting. > In order to make it more consensual, there is probably a need for making > concessions like shortlisting the trusted DDs according to some criteria like > the time they have already spent in the project. I would actually be tempted > to > propose a more variable but more symbolic measurment of time: having been part > of the project for at least one full release cycle. I was sad to see the discussion die, because I liked the idea of having ways to integrate people that were not packagers. However, I do not think that simply "nominating" someone should give them full DD access. I think that even if it has it's flaws, the NM process plays a very important role, getting skilled people to work for Debian. Simply nominating someone would mean a lot of people coming into Debian without enough knowledge. This is NOT a good idea. > I have put membership issues as a first priority in my platform. Partly > because > I have contributeed to the rejection of a proposal and feel resposible to not > leave the Project in inaction, partly because I think that the the > contribution > of DMs is growing and I do not feel like leaving them out of the project. In > my > platform, I suggest in my second priority (less restricted operations) that > social control can replace technical control. I think that most DMs could be > DDs now. DMs are not left out of the project. They have a different role, but they are definitely not out of the project. Social control is very hard to exercise on a project as big as Debian. We need to be able to *trust* that person with their responsibilities, the whole point of the NM process is to allow us to trust. A one-person nomination would not give us enough trust. > If I am elected DPL, I will re-open the discussion and lead them in a way that > maximises everybody's contribution, for instance by making pauses if > necessary, > and by posting neutral summaries. After the discussion reaches conclusion, I > will initiate a GR. You don't need to be elected DPL to reopen a discussion or make neutral summaries. You also don't need to be DPL to initiate a GR. I think you are mistaking what the role of the DPL is. > So my question to other candidates is simple: what is your opinion and program > about membership? My opinion is that the original proposal sent by Joerg Jaspert, maybe modified a bit with the comments received during the discussion, is what would benefit the project most. I would very much like the discussion to be re-opened and a GR to be passed. Even if there is consensus, this would be such a change to the current status, that I think validating it with a GR is useful and thus a vote should be called. I don't think the "one person nomination" idea would have much support. I'm not planning on starting the discussion myself, however. I'm more interested in finding ways of attracting and keeping more people active in Debian, and that's what I plan to work on. -- Besos, Marga -- 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/e8bbf0361003250819s3e7c4ac1j8f564a7d7fb8e...@mail.gmail.com
Re: To all candidates: personal mentoring
Hi! On Wed, Mar 24, 2010 at 8:15 PM, Serafeim Zanikolas wrote: > With respect to attracting new contributors, please ponder the idea of a > formal one-on-one mentoring scheme (as opposed to one-off interactions via > d-mentors). There's been a mentoring program inside the Debian Women project since 2004. This program got a few people at the beginning, but very soon we were out of mentees. There was an attempt to revive it at some point, but the problem was the same, there weren't enough mentees. However, I do think that it's a good idea, and maybe the lack of interest was due to lack of enough "marketing" about the program. I agree that it could be a good thing to try out in order to get more people to help in Debian. This idea, as well as many other ideas that we are discussing during the campaign, doesn't actually require the DPL intervention. What's needed to put this into motion is a group of potential mentors, a point of contact for the potential mentees, and a webpage or the like to advertise the program. Anyone with enough motivation can start it. -- Besos, Marga -- 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/e8bbf0361003241653y49dfb24dr7f28d1e6fe9fd...@mail.gmail.com
Re: Question for the other candidates: supermajority.
On Tue, Mar 23, 2010 at 9:24 PM, Charles Plessy wrote: > After the very painful GR about “Lenny and resolving DFSG violations”, > discussions started about our voting system, and the fact that it does not > accomodate well with mixture of supermajority and regular options. Also, > disagreements whether an option needs the supermajority often starts bitter > debates. > > Do you think it is a problem that you would like to solve as a DPL? Not at all. I think this is the kind of problem that should be solved either by consensus or by a GR. I don't think it would do any good to solve it "as DPL". > For the supermajority, I think that it should be used only when modifying > directly foundation documents. As a compensation, we may let the Secretary > declare a GR ‘unconstitutional’ and refuse to let it be applied. This would > remove a lot of meta-discussion in GRs that already produce many emails. In > contrary with our current sytem, constitutionality of an option would only be > decided after it gets the Condorcet majority. I don't think this makes any sense. It'd mean that we would be voting for something only to have it invalidated after it's voted. It would lead to a lot of flamewars, and probably to the resignation of the acting secretary. I think the best scenario is that the secretary states why a certain option would require supermajority, and then the proposer can a) re-formulate the option so that it doesn't require supermajority, b) present it as a separate ballot, c) accept to have mixed options in the ballot. I think that if what's going on is clear for everybody, it's easier to reach some common ground, to find an option that suits the interests of the proposer without requiring supermajority. Having to wait until the end of the election process to hear what the secretary thinks would only mean lost time and a lot of frustration. > This said, I have not mentionned supermajority issues in my platform, since I > think that the main points I propose would keep me busy enough if I am > elected. > I would be pleased however if somebody would self-appoint and lead this > debate, > if there is the impression that it is needed. I would definitely not lead it myself, and I would rather we spent our time in more productive activities. -- Besos, Marga -- 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/e8bbf0361003241304l6ecfa2e5r5704abb38b470...@mail.gmail.com
Re: Getting more people involved in "core" teams.
On Tue, Mar 23, 2010 at 7:25 PM, Kurt Roeckx wrote: > I think that one of issues we have is that there is alot of work > to be done by some teams, some of them even regularaly mail that > they need more members, but they seem to have a hard time keeping > the numbers up, burning the other team members out. As has been said in this thread and others, Debian is currently suffering from lack of involved people in almost all areas, not only in specific teams. And thus we need to reach out and get more people involved, in general, not only for the core teams. But I'll answer about core teams in particular. > What are your ideas to make sure those teams keep running? I'd like to have two "Teams that need your help" pages, clearly listing the teams that need help and what is needed in order to help them. One of these pages would be contributor oriented, and the other one developer oriented. If a team has tasks that anybody can do, and tasks that require DD access, it can be listed in both pages, if you only can help by being a DD, then it can be listed in the developer page only. I also think that sometimes people get burned out when working in the core teams, because most of their work goes unnoticed. I'd like to raise awareness of the work done by these core teams, so that they could get more credit for what they do, and thus feel a bit more respected by the project as a whole. Zack's idea of mentioning the teams that need help in the "Bits from the DPL" message, is also another way of reminding potential team members that their help is needed. I'd do that too. -- Besos, Marga -- 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/e8bbf0361003241250x56fa6269wf6910fe6482cc...@mail.gmail.com
Re: Question to the candidates
On Wed, Mar 24, 2010 at 3:49 AM, Steve Langasek wrote: > As a developer, how do you embody the spirit and culture that has made > Debian a great operating system? This is a very difficult question, because answering it implies that I accept that I do embody such spirit and culture, and I find this statement too arrogant to make it myself. Instead, I'll say that the most important thing about Debian, for me, is that "Our priorities are our users and free software". This line has shaped a lot of what we do in Debian, towards making the Universal OS. One of the great things about our priority being "our users" is that we don't specify which users. Servers, desktops or embedded users; sysadmins, engineers, websurfers or gamers, they are all "our users", and thus we need to work real hard to make the best OS possible for all of them at the same time. I find this very inspiring, and it has shaped how I do my work for Debian. Trying to have the best for everybody is hard, but I think it's worth all the work done. > If elected DPL, how will you inspire the same in others? As I said in my platform, I think we should have project-wide goals. I plan to set goals that would help Debian be even better than what it is today, and hope to inspire more people to work on those goals. I don't plan to come up with these specific goals all by myself, though, I plan to do it in consultation with the whole developer body, but I'd make sure that these goals all had "our users and free software" as their priority. -- Besos, Marga -- 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/e8bbf0361003241236n4ed5edd0t105e67867ec43...@mail.gmail.com
Re: Q for all candidates: license and copyright requirements
On Wed, Mar 24, 2010 at 3:14 PM, Jan Hauke Rahm wrote: > If I understand you correctly, you dissociate yourself from Charles's > POV about what's part of Debian and thus what needs to be free according > to DFSG. In another thread you said all other candidates are above NOTA > for you. Yes, that's correct. > After reading a few very strong opinions about what Charles said earlier > wrt source and binary packages, I suppose some of them (and maybe > others) might find that a bit contradicting. Actually that's how I read > KiBi's last mail in the "Who would you vote for" thread. Yes, I was talking with KiBi about this on IRC just now. I guess there's not a clear position on what rating someone below NOTA really means. I feel that rating someone below NOTA is not to be done lightly, while other people probably feel it's a normal way of showing you disagree. > Would you mind commenting on that? For me, rating someone below NOTA doesn't just mean "I wouldn't like this person as DPL", it means "I wouldn't stay in Debian if this person was elected". Reviewing my past votes, only in 2006 and 2007 have I voted someone below NOTA, and those were extreme cases where I felt very strongly that a candidate might be damaging to the project. KiBi's questioning, however, has made me think that maybe I was taking the below/above NOTA to an extreme. -- Besos, Marga -- 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/e8bbf0361003241146l480cce22v275c9c448b5d8...@mail.gmail.com
Re: Q for the Candidates: How many users?
On Mon, Mar 22, 2010 at 4:19 AM, Anthony Towns wrote: > What's your estimate of the current number of Debian users? Do "Debian" users include "Debian derivatives" users? :) I think this question is indeed very tricky, and I don't see the point of it being posted as a question during the "campaign" period. How can my estimation change your vote? I certainly do believe that we have many more thank 90k users, and the only reason that we don't count so many of them in popcon is that our direct users get to choose whether they want to participate in popcon or not, and many times they don't. I'll refrain from estimating a number. I'll just say that I plan to work on making Debian more attractive to users, not by changing what we do, but by trying to change how Debian is perceived to be (i.e. a "difficult" distribution). -- Besos, Marga -- 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/e8bbf0361003241108h4a66i46aef04dd7611...@mail.gmail.com
Re: Q for all candidates: license and copyright requirements
Hi, On Sat, Mar 20, 2010 at 3:45 PM, Bernd Zeimetz wrote: > with <20100124144741.gd13...@kunpuu.plessy.org> Charles Plessy came up with a > draft GR "Simplification of license and copyright requirements for the Debian > packages.". > > I'd like to know from Charles Plessy if the draft from January still reflect > his > current opinion or if his mind changed. > From the other candidates I'd like to know their opinion and plans (if there > are > any) about license/copyright requirements in Debian. I agree with zack that this is not a decision that the DPL should take. It's a decision that should be done through a GR, that the DPL can support or not, but I hope that Charles knows that even if he won, it wouldn't mean that it'd be ok to change such policy without a GR (or, at least, another form of consensus on this matter). Regarding the proposal itself, I'm not sure I see how much we would be gaining by not mentioning the copyright holder or reproducing the copyright notice. We would still have to analyze whether the license requires the copyright notice, the copyright holder, or both. In that case, I think it's simpler to keep with what we have, but I don't have too strong a position about this. Regarding software in the source packages, I do believe that "The Debian System" is both the binary and the source packages, and as such we shouldn't distribute non-free stuff, either in the binary or in the source packages. -- Besos, Marga -- 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/e8bbf0361003241045o58258be5x3047377b2864e...@mail.gmail.com
Re: Question to all Candidates: Who would you vote for?
On Wed, Mar 24, 2010 at 5:09 AM, Alexander Reichle-Schmehl wrote: > The following question is optional, as it discloses private information, so > feel free not to answer it. But non the less, I'm curious and would > appreciate, if you would be willing to answer. So here it goes: I was actually going to reply, but after reading zack's answer, I agree it's best not to give out the details. In any case, I do have an answer: > Suppose that you would not run for DPL: Who would you vote and why? I would, and will, vote for all of them. I won't disclose the particular order, but they'll all be above NOTA. -- Besos, Marga -- 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/e8bbf0361003241032p779a8b92mf96794c9bd874...@mail.gmail.com
Re: Question to all (other) candidates
On Tue, Mar 23, 2010 at 2:49 PM, Wouter Verhelst wrote: > In my rebuttal, I mention that I lack a sense of vision in your > platform. In case that wasn't clear, this is because the ideas you > mention, while they might work to some extent, seem to be a bit > superficial; I'm afraid they will not strike at the heart of the issues > we face. Do you believe this is correct? If not, can you clarify? That's weird, I definitely thought that there was a "vision" in my platform. The ideas listed are just some things that can be done to achieve the general goals. They are not meant to be a complete list of everything that I plan to do if elected, just some starting points. The main objective is to go towards the goal of making the work done in Debian more attractive and more satisfying to everyone involved. Many of us have noted that one of the serious problems Debian is facing is the lack of committed people in many areas, I think that working actively into making our work in Debian more attractive to everybody is the only way to fix this lack of work force. > Also, you seem to have received a great deal of help in writing your > platform. In the interest of clarity, can you shine a light on how this > happened? To mention two possible extremes, was this more of a "I'd like > to run, but would need a platform, please send me some ideas", or rather > "hey, $RANDOM_PEOPLE, here's a platform, please give me some comments?" > (I realize the truth is probably somewhere in between those two, but > would like to know exactly what we get if I were to vote you second...) As you say, it's some point in the middle. When I first started thinking about running for DPL, I started discussing ideas back and forth with a small number of people, coming up with what would be good starting points and what could be done to make things better in Debian. After that, I drafted the platform and asked a few other people to comment, and then I improved the platform with their comments. I made a point of thanking all whose input was valuable to me, even though it doesn't mean they'd vote for me or that they support me as DPL in any way, because I think that a DPL should be able to listen to everybody's ideas, and make the best out of them, and I think that giving credit is very important. I've already said that I plan to delegate a lot. I don't think it makes sense for a DPL to try to do everything, it only leads to burn-out and dissatisfaction. I also plan to listen to what other ideas people have to make Debian better and put them into motion. -- Besos, Marga -- 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/e8bbf0361003241024x2cecf23fn1ed803a2a3837...@mail.gmail.com
Re: Questions for all candidates: decentralization of power
Hi! On Fri, Mar 19, 2010 at 3:44 PM, Clint Adams wrote: > 5) Is there any part of Debian that should be restricted > to a small subset of developers, and if so why? So, I've taken quite a while to ponder about these questions, particularly this last one. Several people have already replied with particular reasons of why a certain service should be less than open. My general take on the issue is that through the NM process, we can only assure that a DD knows how to package, how to handle bugs and how to do uploads. We can't assure that every DD knows how to handle the wanna-build queue, how to use wml, or whatever special knowledge is needed for a certain task. With that in mind, I think that if the policy to get access is simply "ask and you are granted it", it's basically the same as if everybody had access, with the benefit that you know who is it that is interested in working on some part, and you can make sure that they at least have the pointers to where the documentation is located. A part of Debian with such a policy could not be said to be "restricted" to a subset of developers, but only "currently involving" a subset of developers. As long as an open policy is kept and response to requests is fast enough, I don't mind having to ask to get access to a certain part to which I want to contribute. However, if only certain people who belong to certain circles can work on a part of Debian, then we are probably falling into elitism, and we should inspect that to check what's going on. But also, yes, there are parts of Debian that should be restricted. Even without taking security into account, I think it would be extremely chaotic if we all had root in all the Debian machines. Or, if we all had it but wanted to avoid chaos, we'd need to agree on a group of people that actually take the decisions regarding the setups, and refrain from changing stuff to each one's liking, thus having a restricted group that takes the decisions. Now to the specific cases you asked about: > 1) 114 people have commit access to webwml. Given that version > control makes it easy to undo changes, minimizing risk and > impact, are there any legitimate reasons why this repository > should be restricted to a group any smaller than the whole of > gid 800? As I said, given than the policy here is "ask and you get it", I don't see anything wrong. It's also good to know that you don't need to be a DD (i.e. know about packaging) in order to be able to contribute to the website, which makes this example even less restricted. The legitimate reason can simply be being to be able to know who's working on what, and make sure they are aware of how the work on the website is done. > 2) wanna-build access is restricted to a small number of > developers, but there is no uncorrectable damage that can > be caused by someone making mistakes. Is there any legitimate > reason that wanna-build access should be restricted to any > group smaller than the entirety of gid 800 membership? Others with much more knowledge about this than me have already explained the reasons of why it was so closed in the past and how it has improved in the present. Even if no "uncorrectable" damage can be done, by messing up with the wanna-build queue, someone could hog the buildds, and thus it's important to know that people with write access know what they are doing. This doesn't mean that we should have a closed circle of "wanna-build" gurus, but that to get access you should at least show interest in what's going on. > 3) An ftpmaster cabal of times long past used to use the > phrase "mirror pulse" to justify oppressing the freedom of > other developers, but we do not hear those words used much > anymore. However, the word "trusted" has continued its > prevalence in situations where one developer is considered > better than another. Is there any legitimate reason why > one DD should be considered more "trusted" than another > without having earned such trust? As others, I have no idea what you are pointing at here. I'd say that it is normal that some DDs are more trusted than others, but specifically because they have earned that trust. I cannot figure out in what situation someone is more trusted without having earned such trust. Or what it has to do with the mirror pulse. > 4) The tech-ctte has the power to appoint its own members. > I do not know why they should be allowed to self-manage > when their judgment on the issues raised to them has often > been less-than-stellar. It is also accepted that core teams > should have the same power, and one common claim is that the > team members have the right to exclude anyone who does not > get along with them or agree with their approaches. > Is there any legitimate reason why core teams should be > allowed to select their own members with or without external > oversight? I think that the main reason for this is that it would be extremely annoying for everyone involved if it was done otherwise
Re: Q for all candidates: (Old) Architecture Support
On Wed, Mar 17, 2010 at 10:49 AM, Yavor Doganov wrote: > Debian has been known through the years for its excellent support for > many architectures. In theory, a released arch should be as stable as > the common/popular archs. (In practice, it is/was pretty close, which > is good enough.) Yes, this has always been something that makes me be proud of about Debian, and I'd definitely like for it to continue that way. (... skipping the bulk of the analysis ...) > What do you think the project should do (with or without or regardless > of your help as potential DPL) to preserve this goodness (maximum > supported architectures) for as long as possible? Do you think it is > "goodness" or you're in the "good riddance" camp? I would like to support as many architectures as possible. We cannot deny the passage of time, however, and so we must accept that some architectures are bound to stop being supported. This even happened some years ago with 386. We still call the "common" architecture i386, but a real 386 computer wouldn't be able to run the current systems, since the kernel requires at least 486. The only way for an architecture to be supported is to have enough people interested in it, enough porters working on the toolchain, the kernel, and helping the maintainers with the arch specific bugs. If there's enough interest in the arch, then it's probably going to survive, if too many people lose interest, then it becomes impossible to maintain the port. The root of the problem then comes back to lack of enough contributors, which is one of the problems I plan to tackle if I'm elected. I'm not really sure on how to attract more people to contribute as porters, since that usually requires having access and interest in a particular platform, but with the use of porting tools, like using QEMU to emulate a particular architecture where a bug needs debugging, we could try to encourage more external contributors to help fix porting bugs, and thus help keeping the overall health of the port. Also, we could try to improve motivation on bug fixing, by reminding developers that each time they fix an arch specific bug they are improving the overall quality of the software and that we really appreciate having high quality software. -- Besos, Marga -- 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/e8bbf0361003181302q3af153d2k73484b6b7eede...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
On Thu, Mar 18, 2010 at 9:41 AM, Alexander Reichle-Schmehl wrote: >> Without a leader, the press team would have to be delegated by the >> body of developers, through a GR or similar election, in order to >> actually be "the voice of Debian". > > Leaving out meta questions, when one can be considered to be "the voice of > Debian", but the press team are already delegates. I know, but if we were to be without a DPL, those delegations could not be re-validated. It is not clear by reading the Constitution what would happen to the "DPL delegates" if there was no DPL. However, even assuming that all delegations stand, if someone resigns to their post and there's no DPL then there's no way of replacing that someone with someone else, without some voting implied. I'm sorry, but I really don't see any use to all this mind exercise, could we stop now, please? -- Besos, Marga -- 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/e8bbf0361003180553y2cca3ffhffbdf1da830fe...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
On Thu, Mar 18, 2010 at 2:07 AM, Gunnar Wolf wrote: > Of course - But we do have a press team. If we were to lack a Leader, > the press team would just become the contact point for the press, > right? Without a leader, the press team would have to be delegated by the body of developers, through a GR or similar election, in order to actually be "the voice of Debian". > (note that I am not against the DPL position, I am just entertaining > the idea) I beg you to please stop entertaining it until it at least seems possible. -- Besos, Marga -- 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/e8bbf0361003180502p1bcddf70ia6c664d5e3893...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
On Wed, Mar 17, 2010 at 1:32 AM, Gunnar Wolf wrote: > What would be different if there was no leader? Where would the > project lose more? Would it gain in some aspect? The Constitution gives the DPL a number of duties that would then be vacant. Even though it wouldn't necessarily lead to total chaos, having no one to decide what to do with Debian's money, no one to appoint the necessary delegates when some of them resign, and no one to be the central voice to speak for Debian, could be quite problematic. It could be possible to resort to many more GRs than we are currently having, and vote on everything that has to be decided, but it wouldn't be a good productive use of everybody's time. Mainly, the DPL is the role of a person capable of inspiring all the developers into working together towards a common goal. By losing the DPL role, we would lose the chance of really being a united community and become separate individuals working on separate stuff. I do not kid myself, I know that many times that's what we are, but still I think that the leader helps keep us more or less on track. I can't think of any advantages of having no leader. I second zack's request to please not continue with this hypotheticals, please, I'd rather use my brain to think about real problems and the solutions needed. -- Besos, Marga -- 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/e8bbf0361003171851j2a6aeb9ev18c4608498e5b...@mail.gmail.com
Re: Question to Candidates: Disappearing DPLs?
On Tue, Mar 16, 2010 at 4:30 AM, Gerfried Fuchs wrote: > I have a question to the candidates: History has shown that DPLs more > or less disappear not too long after their period or at least reduce > their visible efforts immensly. I wonder where you see the reasons for > this trend, what your impression is about it and wether you try to > follow that trend or what you will try to do to not have this happen to > you, too. As has been stated by people previously holding the DPL role, it's a very time consuming task, which tends to take away quite a lot of that person's time. Thus, I feel it as only natural to want to have a "break" to catch back with all the stuff that had to be relegated during the DPL term. I don't necessarily view it as a bad thing. Sometimes, taking a "sabbatical" means being able to come back to keep working on the project with renewed energies... Unfortunately, it also sometimes means completely disappearing from the project. Debian plays a very central role in my life, so no matter how burned out I could become, I would not totally disappear after the term. However, I'd like to prevent the burning out as much as possible. For that to happen, I intend to delegate a lot. I don't intend to be a "solo" leader. For all the initiatives that I plan to do, I'd first form a team of people and work with them into putting the ideas into action. -- Besos, Marga -- 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/e8bbf0361003171835h77f500bfm2c96a2df20336...@mail.gmail.com
Re: Question for all candidates: Release process
On Wed, Mar 17, 2010 at 12:56 AM, Gunnar Wolf wrote: > Hmm, you got me thinking here on why this happened, as I share your > impression. Maybe it was because the project as a whole put more care > into the release process after the massive pain it was to release > Sarge, a three-year-long pain we didn't want to suffer again? For > Lenny we lost some of that push, although the release process was > still mostly swift, with a minor slip regarding what we expected. As has been said by others, I don't think this is accurate. It might have been one of the reasons, but there are probably many others. For example, the competition of dunk-tank vs dunc-bank, made Etch one of the best Debian releases because it REALLY had very very few bugs. In other releases, there might have been no RC bugs reported, but the bugs were there anyway. Another thing that I see "special" about Etch, is that Steve and Andreas stayed as managers after Sarge was released, so they came to Etch with a lot of knowledge on their shoulders. After that, it has been sadly very hard for us to keep the RMs for long enough. And there are probably a lot of other factors to take into account of Etch's success. > As for the reasons why we are not freezing yet... I think it is > somewhat a lack of commitment to what the Release Team says, as (too) > many people felt betrayed with the way the freeze-related > announcements were made (a topic that has already been analized > here). I don't agree here. I think that the lack of commitment to the release is more probably due to lack of enough communication from the Release Team and lack of motivation from the general developer body. This is not intended as criticism towards what the RT has done, but it's more of a diagnose: we are lacking motivation and more communication of near-future goals could help us work better as a group. Personally, even though I was shocked in July by the unexpected announcement, I was very glad to see the Release Team find a compromise solution, that fit the project's time better, and thus in no way do I feel "betrayed". I don't think the majority of developers does. I think that the lack of manpower is a much bigger factor. As has been said, here and elsewhere, we are lacking people on this area as much as on many other areas in Debian, and that shows. > So, going back to the questioning of the candidates: Do you agree with > this very simplistic analysis? If so, how would you push to get the > drive and the confidence back? As said, I don't agree. What I plan to do as DPL that would help in this area, is set some project-wide goals, so that developers can be inspired to focus their energies on those goals, and also several initiatives to get more people to help Debian, both by reporting and by fixing bugs. -- Besos, Marga -- 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/e8bbf0361003171822k5f26d409ma77ed9c07e962...@mail.gmail.com
Re: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 1:57 PM, Stefano Zacchiroli wrote: > On Mon, Mar 15, 2010 at 09:10:23AM -0300, Margarita Manterola wrote: >> A new Code of Conduct has already been drafted, but it has never been >> put into practice. > > What are you referring to here when you write "Code of Conduct"? Do you > mean the Debian Community Guidelines (as I guess), or rather > http://www.debian.org/MailingLists/#codeofconduct ? Yes, the Community Guidelines. As I've always understood that the idea of these Guidelines is to eventually replace or enhance the CoC, I consider them a draft for a new CoC. I think that they should be validated by a vote, so that we can know if the community as a whole agrees with them or not. However, I don't know why Enrico hasn't submitted such a vote. -- Besos, Marga -- 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/e8bbf0361003151009r517868bdkc2d74cfefd573...@mail.gmail.com
Re: Question for all candidates: Release process
Hi Frans, Let me first start by stating that I'm sadly concerned about the tone of your mail. Nobody claims that the release process has been done perfectly, there have been mistakes, but we are all human and we can all make mistakes. It's alright to point those mistakes out so that people can correct them, but I find your mail disturbing, because it feels more like attacking the past Release Managers than trying to improve the overall project quality. With that in mind, I'll answer only a few of the issues you raise, those that I feel are relevant to the upcoming election. On Mon, Mar 15, 2010 at 12:30 PM, Frans Pop wrote: > The Release Team should IMO keep in mind that it's not *they* who make a > release, but the whole project together. And the best way to get respect > for their work is for them to respect the vastly bigger amount of work > done by all other DDs collectively. I think that the whole project should keep that in mind, not just the Release Team, and I feel there are many people who don't care enough about releases and thus do not help out. I agree that communicating more often could help, but it would also be necessary to agree on some common goals for the project, so that we really are working all together as a community instead of just doing some solo work. That's one of the things I plan to do as DPL: establish (by talking with the affected teams) some common goals to work on, and communicate them project wide so that we are all working together towards that. > Ideally the Release Manager should > spend more time on communicating with the rest of the project than on > handling transitions. I agree with this (and many of the removed-due-to-being-aggressive quotes). However, the lack of man power means that the Release Managers end up in charge of transitions and lack the time to do the real communication and coordination. The role of the DPL is to help developers do their work as good as possible. In this case, the only thing that can be done is try to inspire more people to help out with the release team, but this is not an easy task, since working on transitions requires extra knowledge that many DDs don't have, and the release team members don't necessarily have the time to train them. We currently and very sadly don't have a Release Manager. Please let me suggest that, when a Release Manager is appointed, you should direct your suggestions about management to them, focusing on what could be done better, without the need to attack whatever was done wrong in the past. -- Besos, Marga -- 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/e8bbf0361003150916o58d9f400x88b4dbe793a7a...@mail.gmail.com
Re: Question for all candidates: Care of Core infrastructure
On Mon, Mar 15, 2010 at 7:30 AM, Marc Haber wrote: > Do you see the diminishing care for our Core infrastructure as a > problem? Do you have any idea how do sensibilize our new blood for the > fact that "new packages" doesn't help Debian if our Core stuff is > diminishing? I know that this is not exactly within the power of the > DPL, but do you think that you, as DPL, can help speeding up Core > development again? As you say, this is quite not in the power of the DPL to solve. The only way that the problems listed by you and by the other messages in this thread could be solved is by inspiring people to work on those issues. How? That's a very tricky question, since people are inspired in several different ways. However, it's quite common for people to approach the project (be it through a mailing list, IRC or maybe personally asking a DD), saying that they want to "Help Debian"... But we don't usually list those core tasks as ways of helping Debian, because they are seen as too important for newbies to help with. I'm thinking that we could try to have a more fancy "Get involved in helping Debian" page, where all teams that welcome help could post their tasks and try to attract new contributors. Maybe even have a parallell page that is only for DDs (since, for example, the release team and ftp team require DDness, because the needed machine access), and invite DDs to contribute more to Debian through it. Having the requests for help more visible and easily findable by more people would hopefully lead to more people helping out. Or not, but I think it's worth trying. Apart from that, I cannot think of a way to fix the core teams lack of manpower. It's not -like it used to be in some cases- that the teams are not accepting new members, so we only need to reach the people that want to join. -- Besos, Marga -- 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/e8bbf0361003150827k7301159dl348b7e436c1d7...@mail.gmail.com
Re: Question for all candidates: Release process
On Mon, Mar 15, 2010 at 4:09 AM, Lucas Nussbaum wrote: > During the last debconf, the freeze of squeeze was first announced to > take place in December, then this decision was cancelled, and now we are > in March. > - How do you analyze what happened during last summer? What went wrong? What went wrong: a decision was taken without consulting the affected teams. This is a situation that has happened over and over again in Debian. The Debian community does not take it well when they are informed of a decision already taken without having a say on it. We should learn from this to never make this mistake again: always keep involved participants in the loop and consult with other people before announcing something as a taken decision. What went right: after the many messages stating that the December freeze was NOT a good idea, specially after Mark Shuttleworth clarified what he meant by "freeze" (stating which versions to include in the release), the Release Team sent a mail saying that freezing in December was not a good idea and that the freeze would most probably happen on early 2010. > - What is your opinion on the motivations for the proposal to freeze in > December? Specifically, in the future, should we try to coordinate our > release process with Ubuntu's? I think it's generally a good idea, *BUT* I think we should freeze about the time when Ubuntu releases the LTS, *NOT* 4 or 5 months before. Because, as we all know, Ubuntu doesn't really freeze until really close to the release. So, freezing before that is the same as not coordinating at all. This would mean that Ubuntu would release the LTS in April and Debian would release maybe in July or August. I'm perfectly ok with that. I also think that releasing roughly every two years, with a kernel/X/etc upgrade in the middle (like was done with etchnhalf), is good. I value stability far more than "bleeding edge", and I know that releasing more often than that is going to have quite an impact in stability. Where I work, most users (about 150) are still using Etch, because they are used to it and have no real need of anything newer. All in all, this is my opinion as just a DD. The release process is the work of the Release Team, and it's their call in the end. However, to avoid the turmoil caused last year after the DebConf keynote / press release, the RT should always keep involved teams in the loop when setting a release (or freeze) date. > - So, we are now in March. What is your opinion with the release process > so far? When do you see the release happening? I'm very saddened by Luk's resignation from yesterday, I think it's mainly the result of having to do too much work by too few people. This leads to stress and frustration, and those tend to lead to resignations. Now we have to give the team some time to re-arrange themselves and find a way to continue. I won't make any predictions, since they'd make very little sense in the current context. I do plan to help the Release Team releasing squeeze, in whatever my capacity, and I'm hoping that it'll happen this year, so that the whole LTS syncing thing can happen. However, if in order to have a stable, robust and clean release we ended up releasing in 2011, I'd still consider it a good trade off, and I'd still back up the Release Team. -- Besos, Marga -- 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/e8bbf0361003150814w52c2ee60h9ab8050311128...@mail.gmail.com
Re: Question for all candidates: Release process
On Sun, Mar 14, 2010 at 6:44 PM, Russ Allbery wrote: > Releasing is regularly the hardest thing that Debian does, not just > technically but also socially. Apart from the standard issues of setting > deadlines, RC bug counts being high, and similar difficult technical > issues, the process seems to eat volunteers. There's usually always at > least some frustration, anger, and upsetness, and there seems to usually > be at least one resignation over the course of a release, often in a way > that hurts other activities in Debian for a time. I think that most of the frustration comes from the fact that the release team is lacking manpower. The job of the release team is very stressful and very rarely do the RM and RA feel that their work is appreciated. > Do you have any ideas how, as DPL, you would (or even could) address this? I've been thinking about this, due to the recent events, and I'm not sure I have a solution. As I've already commented, I'd like to set up some projects that encourage more external (and internal as well) contributors both to report and fix more bugs. However, there's much more to the release work than fixing RC bugs: managing transitions is a LOT of work, that requires extra knowledge, and only DDs can do it. We know from past experiences that throwing money at the problem would only bring more trouble, so that's out of the picture. So, the only way I see to help is documenting the work needed and asking for help. Maybe if more DDs knew the work needed to get their own packages into testing, they would be able to help there, and reduce the pressure on the Release Team. > I'm personally the most concerned with the social issues. A delayed > release can be frustrating but doesn't have that much negative impact, but > volunteers with enough knowledge of Debian to be able to serve as release > managers or helpers are rare. And usually the arguments not only hurt > their contributions to Debian but usually hurt the contributions to Debian > of the people on the other side of the argument as well, who are often > also valuable and difficult-to-replace volunteers. I agree with all of this, and I'm very much concerned about this myself. However, I don't see an easy way to fix this. My ideas are on how to make it easier to help out, but people won't necessary want to help, and I can't think of a way to magically make people want to help. -- Besos, Marga -- 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/e8bbf0361003150642h6d3f431ejb3b1bd852f5b4...@mail.gmail.com
Re: Will you withdraw delegations of DD not behaving correctly?
On Mon, Mar 15, 2010 at 4:13 AM, Raphael Hertzog wrote: > Most of you have answered that it's not possible to regulate the heated > discussions but it's possible to set a good example. If only the leader > behaves properly, it will still be difficult to make the climate change. > But if all the delegates behave properly, and if delegates that do not > behave properly are withdrawn due to this, we might get better results. > > What do you think of this and would you be ready to withdraw a delegation > for a delegate that behaved badly towards another DD (even outside of his > delegated role), that has been warned once by you and that did it again > later on? As you say, I think that it's very important that key Debian people set a good example, not only the DPL but all the delegates, yes. However, I wouldn't dismiss anyone so easily, it would have to be a recurring situation (i.e. more than twice or three times) and of a high level of misbehavior for it to lead to un-delegation, and that would be only when all the other options (like talking privately, mediation, etc) had been unsuccessfully explored. Were such a misbehavior to happen with me as DPL, my first attempt would be to talk privately with the people involved, trying to find a way that the situation can be solved, maybe even with a public apology if that's needed. I think it's better for everybody to try to grow into better selves, than just dismiss whoever is not behaving properly. > Do you think we can draft a code of conduct for Debian and do you think > you can ensure that it would be respected by delegates? A new Code of Conduct has already been drafted, but it has never been put into practice. I guess that we should vote upon it, to see if the developer body wants to have it. If the vote is successful, the code of conduct can be enforced for everybody and not just for delegates. In any case, I agree that the people in the core roles should be the ones that show the best behavior. -- Besos, Marga -- 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/e8bbf0361003150510s3dccc49fhc68c365ab93ea...@mail.gmail.com
Re: Question to all the candidates: communication
On Sun, Mar 14, 2010 at 2:16 PM, Raphael Geissert wrote: > How, how often, and when do you intend to communicate with the project? > (please continue reading to understand the context) > > In the past there have been "Bits from the DPL" emails which have been nice, > but during the last couple of years there have also been some press > interviews to the DPL and statements made which have come as a surprise to > everybody. What do _you_ plan to do? The DPL is elected to lead the developers, not to decide stuff on their own and have the developers live with it. As such, I think that a DPL that takes decisions without consulting with the developer body, or at least with the teams most affected by those decisions, makes very little sense. I don't intend to take arbitrary decisions without consulting with the relevant people. I don't intend to inform the press about stuff I decided on my own or without the developer body consensus. I do intend to communicate as much as possible, trying to do the "Bits from the DPL" when there's enough info for that, or at least by blog posts. I am concerned that by talking to former DPLs or people who were in close contact with them, communication tends to become quite a burden and for the common developers it's never enough. That's why I've been thinking about the RT usage, and if there's something else that could be done to ease the communication with the developer community, I'm willing to try that as well. -- Besos, Marga -- 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/e8bbf0361003141117g792afc2dod226a8bc08ead...@mail.gmail.com
Re: Question to all the candidates: communication
On Sun, Mar 14, 2010 at 12:17 AM, Paul Wise wrote: > 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-de...@l.d.o, > debian-proj...@l.d.o, the Hardware forum on forums.d.n etc). I generally follow quite a number of lists in Debian, -project, -devel, -boot, -release, -women, -vote, -mentors, -newmaint, -policy, -qa, -announce, -devel-announce. I don't always read all the mails in the lists, obviously, but I try to keep up with anything important that is going on. I'm usually in #debian-devel, #debian-release, #debian-women, #debian-ar and #debconf-team. I also read Planet Debian, I have a blog there but it's currently underused. I'm also subscribed to the -bugs-dist list, although I use it mostly for searching bugs and related mails. I don't twitter, and I don't usually read any microblogs, nor do I use facebook. I don't plan to change this. > How do you see those two lists changing if you become DPL? I do plan to blog more, as well as post "Bits from the DPL" on -devel-announce. > Which of these communications media do you feel is important for the > DPL to read? I think that it's important that the DPL keeps up with what's going on in Debian, but it's not possible to read all the Debian lists. That's one of the things that I miss the most about DWN: it allowed us to be updated on anything interesting happening on the mailing lists, without having to read all of them. In any case, -devel and -project are obviously a must. For the rest, I think that anything important that requires the DPL attention would be CC'd or forwarded to lea...@d.o. I've been told that a lot of the DPL's time is spent reading / replying to lea...@d.o mails. I've been thinking about this and pondering whether it would be a good idea to try to direct more of those mails to RT instead of the leader's inbox, so that DDs can keep track of what's being done about their requests, as long as they are not private, of course. > Please breifly comment on how you see Debian's relationship with some > of these media. I'm not sure of what's being asked here. Which of the mentioned media are "these media" here? Because obviously it's not the same relationship with official Debian lists than with microblogging services. > Do you feel any of these media have been misused by Debian people > (DDs/non-DDs alike)? If so, what action would you take if you become > DPL? Again, I'm not sure which are "these media" in this case. In any case, apart from the aggression level discussed in another answer, I don't think there's a level of misuse that we should worry about. > Do you feel the general tone and perception of Debian is positive on > the media that you follow? What action would you take to improve these > if you become DPL? For a lot of people outside Debian, Debian is seen as "difficult" from the user point of view, and "aggressive" from the to-be-contributor point of view. I do plan to take action on both of this aspects if I become DPL. By doing a campaign with the message that Debian is not harder than other GNU/Linux distributions, and by doing events as the one commented on another answer for encouraging contributions. -- Besos, Marga -- 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/e8bbf0361003140927t4c0ad710l30148d9b25359...@mail.gmail.com
Re: Question to all Candidates: Heated discussions
On Sat, Mar 13, 2010 at 11:40 PM, Dmitrijs Ledkovs wrote: > Do you think current frequency/amount of heated discussions is > acceptable for the Debian project? Even though the mailing lists climate is much better than what it was 5 years ago, I think that it still sometimes gets too aggressive, and when it does, it reduces the 'fun' factor, thus reducing productivity. > What would you do to reduce those? I think that the most important thing is keeping a positive climate. Appreciating what the other person has said and done before starting to criticize. We can't hammer this into people, but we can teach by example. Also, when a discussion becomes a flamewar, I think it's useful to talk privately to the parts involved and ask them to stop for a moment to see the big picture. I think that the flamewar problem is rooted in an old concept that Debian is ok with flamewars. The only way to get rid of this concept is getting people that participate in flamewars to understand that Debian is NOT ok with them. We could do this with a renewed Code of Conduct as has been proposed over and over these past years, but I think that social pressure is much more effective than the Code of Conduct itself. -- Besos, Marga -- 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/e8bbf0361003140739p3aaa5666t19396af9ba293...@mail.gmail.com
Re: Question to all Candidate: In ten years...
In Sat, Mar 13, 2010 at 11:35 PM, Dmitrijs Ledkovs wrote: > Please finish "In ten years I'd like Debian" In ten years I'd like Debian to still be thriving as the Universal OS. Things will obviously have changed. But, if we look back to 1993 when Debian started, a lot of things were different; however, the spirit of the distrubution remains. And I think that into the future it could be like that as well. Things will change, it's inevitable, it's expected, it's bound to happen. But we can always adapt into keeping Debian current, keeping Debian a great distribution for everybody, keep working on making the best possible OS. I'm not sure this matters too much for the DPL election, since the DPL role lasts only one year, though. -- Besos, Marga -- 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/e8bbf0361003140731u63e76d65s7624434223a77...@mail.gmail.com
Re: Question to all candidates: financing of development
On Sat, Mar 13, 2010 at 4:18 AM, Raphael Hertzog wrote: > Imagine a DD contacts you, she wants to setup an infrastructure to finance > Debian related projects (i.e. paying people to enable them to work on the > projects that they'd like to do for Debian) but she wants to avoid the > main mistakes made during Dunc-Tank; in her project: > - everybody can propose projects to be financed > - the projects to be financed are selected by the Debian developers and > by the donors > - eligible projects can only concern new developements and not recurring > tasks This sounds quite similar to how the GSoC is done. The main problem in this scenario is actually finding the sponsors to pay for the developers, and then control that the projects get done as expected. > What advice would you give her? > What other pitfalls from Dunc-Tank must she pay attention to? We have already participated in a number of GSoCs (four, if I'm not mistaken), and it hasn't issued any social problems like Dunc Tank did. So, if there were to be other sponsors willing to pay for a similar thing, it's not likely that there would be a bad reaction towards it. However, if it's seen as a "Debian" thing, instead of an external thing like GSoC is, then it might lead to some resentment from the side of the people that don't get any money for their work. > Do you have concrete suggestions for her on how it should be working? The main issue would be that the whole process should be very transparent. When money plays a role, it's very important that everybody knows what kind of money we are talking about, what the responsibilities of the people receiving the money are, and how the whole thing actually benefits Debian. > Would you encourage her to go forward or would you try to convince her to > forget this idea? I don't like it too much, so I would definitely not encourage it. I'd tell them to discuss this idea (with more details) on debian-project and see what the general opinion of the project is, and only decide to go forward with it or not after that. -- Besos, Marga -- 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/e8bbf0361003130735y1a002efav2737b59c8025f...@mail.gmail.com
Re: Question to all the candidates: time
On Sat, Mar 13, 2010 at 2:56 AM, Paul Wise wrote: > #include > > How much time do you currently devote to Debian? How will that amount > of time change for the DPL term? How will you balance your DPL time > and time for other Debian activities. Currently, I'm devoting only a small portion of my free time to Debian, a daily hour keeping updated with mailing-lists, news, and the like and some bug fixing here and there, also a little mentoring towards local contributors. All in all, it doesn't amount to too many hours. This is because after the organization of DebConf8 I needed to reduce the hours spent on Debian in order to keep sanity, so I haven't been as active or involved as I was before. However, I'm ready now to start devoting much more time towards Debian, regardless of the result of the election. If I'm not elected, I'll be working hard during the next months towards bug finding/fixing for squeeze. If I'm elected I guess that I won't have time for that, since practically all my free time would have to go to being DPL. At least, that's what I hear from former DPLs: just replying to lea...@d.o eats up most of the DPL's time. -- Besos, Marga -- 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/e8bbf0361003130720se9b9a8cu95d139248bd63...@mail.gmail.com
Re: Question to all Candidates: 2IC
On Sat, Mar 13, 2010 at 2:11 AM, Raphael Geissert wrote: >> So, while not having a particular appointed 2IC, I do plan to ask a >> lot of people for help on the many things I'd like to accomplish. And >> I also do plan to mention, thank and appreciate all the help received, >> no matter how small the task. > > What tasks do you have in mind that you plan to delegate? There are a bunch listed in my yet-to-be-published platform. But just to give an example from the previous mail, I'd like to have a page with rankings of people reporting and fixing bugs, in order to give some nice Debian merchandise to the ones that help the most, but I don't think I'd have the time to organize the whole thing myself. So, I'd probably find a group of people that like the idea and are willing to put up the work to have the system running. -- Besos, Marga -- 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/e8bbf0361003122147y5fc45980p69df222f81da...@mail.gmail.com
Re: Question to all Candidates: Project Funds and donations
On Fri, Mar 12, 2010 at 8:02 PM, Martin Zobel-Helas wrote: > The Debian Project receives quite a number of monetary donations as well > as contributions in kind via several umbrella organization like SPI, > ffis, debian.ch, etc. > > a) What do you think are valid goals to spend this money on? I've been thinking about this for a long while now. I think that the areas that deserve spending Debian's money are: keeping Debian running, improving the overall quality of the OS, getting more people to contribute to Debian, and getting more people to use Debian. Currently, there's a portion that is used to fund developers travelling to work-meetings or to DebConf, and another one for shipping and setting up hardware. I think that these are all valid ways to spend money, and that we should encourage them. I also would like to see some money spent on promoting Debian, by providing materials for booths in conferences around the world. This would not be too much money from our accounts, but it could make a lot of difference regarding the image that people have of Debian. Another possibility that would help giving Debian visibility as well as improving the overall quality of the distribution, would be holding bug-fixing and bug-reporting bounties, but with Debian merchandise (t-shirts, mugs, stickers, etc) as prizes (i.e. not monetary prizes)... And if it works we could maybe even get sponsors to donate some bigger prizes. I think that more money could be spent in financing travel for developers to attend conferences, meet with other contributors and give talks related to Debian. For this part, I think we should form a delegated committee, like we do for DebConf to allocate the money, so that it's not left to the arbitrary decision of the DPL. Obviously this should all be done as long as there's enough money left in the Debian accounts for hardware and emergency needs. > b) How would you think is a valid way to thank (hardware) contributors? > b) What qualifies a contributor to become a "Debian Partner"? What > qualifies a "Debian Partner"? This feels like a question from the NM process. The way to thank donors is by showing their logos and listing their contributions in the Debian Partners page. I'm not totally sure of what the question is. I don't know how it was decided which contributors are listed and which are not. But I guess that current providers of hardware and big money contributors should be listed, while past contributors should be listed in a separate "Previous Partners" or the like. -- Besos, Marga -- 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/e8bbf0361003122139rdbcba13ucb86e5b09f89d...@mail.gmail.com
Re: Question to all Candidates: 2IC
On Thu, Mar 11, 2010 at 9:12 PM, Joerg Jaspert wrote: > a little question to all those up for the next DPL: > Do you plan on taking on a "2IC" or a team? > If so: Who? And why this/those? I don't plan to take a 2IC or a DPL team, in the sense of someone else receiving lea...@. I do plan, however, to delegate many tasks. Both in the constitutional and in the everyday use of the word. One of the things I learned from DebConf organization, particularly while organizing DebConf8, is that delegating is hard, but it's very important to be able to do it. In my experience, we geeks tend to feel that we have to do everything ourselves, otherwise the task won't get done properly (or at least not exactly how we thought about it). However, my vision is that it's essential to delegate, otherwise the task won't get done at all. So, while not having a particular appointed 2IC, I do plan to ask a lot of people for help on the many things I'd like to accomplish. And I also do plan to mention, thank and appreciate all the help received, no matter how small the task. -- Besos, Marga -- 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/e8bbf0361003121008x2c9de0b8l7944fad35a139...@mail.gmail.com
Re: Nomination for DPL
Sorry for the double post, but since I signed the previous message with my not-yet-in-the-keyring key, this one is signed with both the old and the new keys. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1,SHA256 I've been thinking a lot about this, and I consider that I could try to improve Debian from the role of DPL. I hereby nominate myself for DPL. I'm currently preparing my platform, and I'm open for any good ideas that people would like to see a DPL put into action, in order to make Debian better. - -- Love, Marga -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkuZJusACgkQlAuUx1tI/67HzgCfVubhvuDl/JhQmluG02BKVmXa DFUAoJwVkE8PN9gt9wTKxoYlMdIMau7MiQIcBAEBCAAGBQJLmSbrAAoJEIDQpC/y yFDKReEQAI98LdynsW+Azj89yxUPakdADiz/o/7jz1/mT+7adeAFP/hg+aqJ4usY yo4n4l482Z09h8JvGYQQ+HtcmPnBFqfNBLF7cIj8RCcTiJ/h8IgdcHRMPTOVHoT1 vY3zcHszNm9hHnNEcI/ivdAeZjDREbb42NyiBQFss2lul0XvOO6k3EJ84qsaxwqC nXYw/XUqGuoxSmtZsg6MqbOoDHNLwQZ/Wksi5FB/p9nhEb5FGGlBMNYUZlX0SHDc EAdzOSNykWdD0ZZlFccn8R7ZDMC94VjHNCf3zTHx7QNvwgpKpwmLJZ60S71FnxC3 OsGQzpFqbk6lzQ+8OU0dVD0Xb7EqOzVAeEMI6jYOwt1A2IInVdIWTI0duI9DTlEH g9Ycs2UarA0Ox6/PG00Hf62QkLRIWOLSI6Ahhu1WUF4ZPe2iBOkpUK4IJYs0FY7n sQZFX/q0Ope9P6Teh6UseaCsE2jBdomC53+J0+k/bbCGOXSefExQNLIdgTi88/jb QyR1FduhgVMkMB0p6HTYYmffyfRz1A95Cc71RQtmu6pgjnhnWkgECbbdhbiO6/zI E+iwId+hAx4UuXDVf8JTYsP28LFvJg40cjH9HcyTafB+jIjoMIMC+F8gsMc2xD8M uDnqciBuNqSPmFES3bbcE/NMZXX28wAZhcg5SlBwlbyKfBwtrNN5 =Q8Ad -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/20100311173031.gb7...@localhost
Nomination for DPL
I've been thinking a lot about this, and I consider that I could try to improve Debian from the role of DPL. I hereby nominate myself for DPL. I'm currently preparing my platform, and I'm open for any good ideas that people would like to see a DPL put into action, in order to make Debian better. -- Love, Marga signature.asc Description: Digital signature
Re: Why the gr_lenny ballot is the way it is
On Wed, Dec 17, 2008 at 4:15 PM, Manoj Srivastava wrote: >So, while the power set of the options is not feasible, we could > have a slew of options combining the various proposed options, if > people wanted to vote on a compatible set of options. No. As I've said, people want to vote separately for separate subjects, we don't want MORE options in this ballot. Please, no. Nobody claims the issues aren't "related", but not everything that is "related" deserves to be in the same ballot. There are three questions that need answering, and these questions are independent. You seem to be worried that having separate ballots would be "gaming" the system, and would be prone to "strategic voting". That might be true when the separate ballots actually hold competing candidates, however in this case, each ballot would answer a different question, so there's no such thing as voting for a less desired candidate in order for your desired candidate to win... Yes, all these questions are related to what will happen to Lenny, but that does not mean they should all go into a messy ballot. In this case, having separate ballots will more accurately reflect the position of the project for the 3 issues at hand: 1) What do we do with licensing bugs in Lenny? 2) Does the RT have the power to decide what bugs to ignore? 3) Do we allow sourceless firmware in Debian? These questions are related but separate, each person should be entitled to vote on how they feel about each of them. There's no "gaming" in this, just an accurate and simple way of finding out the position of the project on 3 related-but-separate subjects. Condorcet doesn't allow more than one "winner". And these option should all be allowed to win (you even said that if neither 4 nor 6 win, they should go on separate ballots in the future), thus, they should all go in separate ballots _now_, it makes no sense to have them all in one ballot where only one can be the winner. I acknowledge that there would be some (extremely unlikely) conflicting outcomes. However, if these unlikely outcomes were to take place, we would have understand that that is actually the position of the project and deal with that sensibly. For example, let's say "Delay Lenny" won and "Allow sourceless firmware" also won. Then, sourceless firmware that is otherwise compatible with the DFSG would be allowed, and no longer an RC bug, but the rest of the licensing issues (if any) would need to be resolved. Or, let's say "Delay Lenny" won and "Allow the RT to decide what to ignore" also won. In this case, the RT would have to acknowledge that the project prefers solving the issues to releasing, and thus shouldn't ignore _those_ issues, but would be able to use the ignore-<...> tags in the future with permission from the project. The other outcomes that I foresee (the more probable outcomes) are not so very conflicting and thus would not require much thought as to what to do with them. As I said yesterday, I hope you can take this into consideration, if you decide to re-do the vote. -- Love, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008 at 9:02 PM, Manoj Srivastava wrote: >If there is sufficient support, we could also scrap the current > vote, change our ballot, add options to it, or something, and restart > the vote, but that would need a strong grass roots support (I do not > think the secretary has the power to do so). As far as I understand from reading the immense threads, most people (me included) don't want more options in the ballot. We want separate ballots for separate subjects. This means that 4 and 6 should get their own ballot. This is not "gaming" the system, it's voting separate subjects separately. Also, titles should summarize the included text without bias. i.e. 1: "Delay the release of lenny until all licensing problems are solved", 5: "Allow sourceless firmware as long as the license complies with DFSG", and probably 4, too, since the text does not speak about "DFSG violations" but rather "usage of problematic software". And finally, if we were to do the vote again, there really is no need to have the trio of 2, 3 and 5. They are basically the same thing, you need to be extremely "into" the problem to understand the differences. Only one option, crafted by those who have real knowledge of what the actual problems are (and that does not requiere 3:1 majority), would be enough. If we do all this, we would be voting: A) If we trust or not the release team on making the right choices of which bugs to ignore and which not (regardless of this being firmware issues or what have you). This is from now on, not just for Lenny. B) If we want to allow sourceless firmware in Debian, defining firmware in a way that doesn't give a waiver to anything else without source. This is also from now on, not just for Lenny. But it's only for firmware, not for everything with licensing problems. C) If we want to allow stuff with some problems into Lenny, as we already did for Sarge and Etch. These three issues are obviously related, but are NOT the same issue, a positive result in one does not determine what happens to the others. And creating one mega ballot with all the different possibilities, only creates confusion and frustration. So, this should be three independent ballots. This is, basically the same that dato proposed: http://lists.debian.org/debian-vote/2008/11/msg00126.html And I think (I haven't counted, but I've followed the threads, the chats and the blogs) that most developers that have participated on this matter have manifested that they would prefer a group of sensible ballots to the monster ballot we have now. I hope that you can take that into consideration. -- Love, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
I'm confused by options 2 and 5: On Sun, Dec 14, 2008 at 8:25 AM, Debian Project Secretary wrote: > Choice 2: Allow Lenny to release with proprietary firmware [3:1] > > 1. We affirm that our Priorities are our users and the free > software community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel > firmware issue; most of the issues that were outstanding at the > time of the last stable release have been sorted out. However, > new issues in the kernel sources have cropped up fairly > recently, and these new issues have not yet been addressed; > 3. We assure the community that there will be no regressions in the > progress made for freedom in the kernel distributed by Debian > relative to the Etch release in Lenny (to the best of our > knowledge as of 1 November 2008); > 4. We give priority to the timely release of Lenny over sorting > every bit out; for this reason, we will treat removal of > sourceless firmware as a best-effort process, and deliver > firmware as part of Debian Lenny as long as we are legally > allowed to do so. > Choice 5: Assume blobs comply with GPL unless proven otherwise > > 1. We affirm that our Priorities are our users and the free > software community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel > firmware issue; most of the issues that were outstanding at the > time of the last stable release have been sorted out. However, > new issues in the kernel sources have cropped up fairly > recently, and these new issues have not yet been addressed; > 3. We assure the community that there will be no regressions in the > progress made for freedom in the kernel distributed by Debian > relative to the Etch release in Lenny (to the best of our > knowledge as of 1 November 2008); > 4. We give priority to the timely release of Lenny over sorting > every bit out; for this reason, we will treat removal of > sourceless firmware as a best-effort process, and deliver > firmware as part of Debian Lenny as long as we are legally > allowed to do so, and the firmware is distributed upstream under > a license that complies with the DFSG. As far as I can see, the only difference between these two options is ", and the firmware is distributed upstream under a license that complies with the DFSG". Now, my confusion comes from the title of option 5: "Assume blobs comply with GPL unless proven otherwise", which is not at all reflected in the text. The text says that we will allow firmware that is distributed upstream under a license that *COMPLIES* with the DFSG. Who will be in charge of stating what complies and what doesn't comply? Where does this say that in evaluating what complies and what doesn't we will assume that the blobs are the preferred form of modifcation? And then, what's actually the difference between option 5 and option 1? I really, sincerely, don't see how stating that we allow only firmware whose upstream license complies with the DFSG (option 2) is doing anything different of not allowing non-free firmware (option 1). I'd be glad if someone could explain this. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes: GR: Project membership procedures
On 12/7/08, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > 5efca670-0e7b-480e-9899-ecce3446e087 > > [ ] Choice 1: Ask the DAMs to postpone the changes until vote or > consensus. > > [ ] Choice 2: Invite the DAM to further discuss until vote or consensus, > leading to a new proposal. > > [ ] Choice 3: Ask the DAMs to implement the changes. > > [ ] Choice 4: Further discussion > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > > I confess that the mapping between the ballot options and what's > published on the above URL is not crystal clear. I presume the order > does matter and that hence we have: > > - Choice 1 -> main resolution > - Choice 2 -> amendment A > - Choice 3 -> amendment B > > Can please the secretary or an assistant confirm that this is the case? It doesn't look like that. As far as my reading goes, it's: Choice 1 -> Amendment A Choice 2 -> Main Resolution Choice 3 -> Amendment B This is very unfortunate, because it's not at all clear. Too confusing, unless you've followed each and every mail regarding this vote. Neil, please, do include the options' titles in the webpage, so that it's really clear which is which. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DAM decisions
Hi! > | Option: Ask the DAM to postpone the changes > | > | The Debian Project, by way of a general resolution of its developers, asks > | the Debian Account Managers to postpone the implementation of the changes > | described on the debian-devel-announce mailing list (Message-id: > | <[EMAIL PROTECTED]>) about "Developer Status", until there > | is consensus on a proposal, or a vote to define the proposal that should > | be implemented. > > and: > > | Option: Ask the DAM to implement the changes > | > | The Debian Project, by way of a general resolution of its developers, asks > | the Debian Account Managers to start the implementation of the changes > | described on the debian-devel-announce mailing list (Message-id: > | <[EMAIL PROTECTED]>) about "Developer Status". I second these two options as alternatives to the option proposed by Peter Palfrader. Rationale: I like Peter's option, but I think that not having these other two makes the meaning of "Further Discussion" unclear. -- Besos, Marga signature.asc Description: Digital signature
Re: Another one?
On Fri, Oct 31, 2008 at 8:09 AM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > Actually, the more I think about it, the more I think that your > formulation for the now-only option in this GR is too complex. > It mixes many different questions: > - do you want to thank Joerg Jaspert for raising this topic now? > - should the proposal be considered finalized? do you support it? > - is it OK if the DAM just decides to change membership management in > the project by himself, without waiting for consensus? > > What if I don't want to thank Ganneff, because it was clearly bad > timing, but I support the ideas in his proposal, but I don't want DAM to > decide without consensus, because I believe that it's too important? > I'm considering re-proposing Charles' initial proposal to provide a > clear option for (A), and maybe also providing an option for (B). I think that the main problem with Charles proposal was that it was too aggressive. If you can provide options that are not aggressive but still convey the meaning you want, I guess you'll get the needed seconds easily I do agree that we need something extra, otherwise the meaning of "Further Discussion" is really obscure. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for Gustavo and Sam: bringing back the fun
On 3/15/07, Sam Hocevar <[EMAIL PROTECTED]> wrote: My main approach to make it fun again to work on Debian is to reduce the frustration. You cannot have fun doing something if your contributions are ignored, if you cannot access the resources you need to do the work, if your administrative requests are postponed because there are more urgent matters, and if you do not know what is going on and why. Agreed, you can't. But even if all of these were fixed (and none are easy to fix, anyway), that does not guarantee that everyone will start having fun. From my own point of view, there are several things that currently make things not fun, which are not listed in your platform: 1) flamewars: the constant bickering on mailing list is depressing, it takes away a lot of time, and it gives the whole project a bad reputation. 2) bad maintainers "owning" packages (i.e. not being able to help out packages that are bad shape, because only RC or important bugs should be NMUed). Thus, we see patches for "normal" bugs rotten in the BTS for years. This is depressing too. 3) reluctancy to change how we do things. There are a lot of DDs that have a "We are the best distribution ever, we shouldn't change anything" attitude. We are being left behind. All the other distros are improving, renewing, adding extra stuff, and we are still doing the same things. 4) jealousy, bitterness, envy, and other feelings like that among DDs. If we just stopped the personal attacks and started concentrating on what we like (free software, I assume we all like that), then we could have much more fun. 5) (this should taken with a grain of salt) length of releases. About this last point, I'm all for stable and good releases, but I'd like to quote some parts of Ian Murdock's "founding" message [0] (...) 1) Debian will be sleeker and slimmer. 2) Debian will contain the most up-to-date of everything. 3) Debian will contain a installation procedure that doesn't need to be babysat; (...) That, along the other points included in that mail, was the outline of a distribution that would be "fun". He proposed a distribution that was good technically, that was up-to-date, that was easy to use, and was nicer. I don't have any magical solution, but I do feel that as we went for the "Debian will be stable and robust and secure" goal, we left behind a lot of the other goals. Can we be stable, robust and secure, and still be sleeker, easy to use and up-to-date ? I think that would be a great help into making Debian more fun (at least for me). [0]: http://groups.google.com/group/comp.os.linux.development/msg/a32d4e2ef3bcdcc6?output=gplain -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question for Gustavo and Sam: bringing back the fun
Hi! This is for Gustavo and Sam, who have both stated in their campaigns that they want to bring back the fun to Debian. Now, I'm all for Debian being more fun, but I wonder: How do you plan to bring back the fun? What are the specific steps required to achieve such a goal? -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question for Andreas Schuldei: Debconf vs DPL
Andreas, It is well known that you are the Debconf magician, and that without your work, Debconfs would either not happen or be a complete fiasco compared to the Debconfs we are used to by now. So, if you are elected as DPL, will you stop doing that work? If you don't, then how will you manage to organize Debconf, be the DPL and still survive? -- Love, Marga
Ballot option should include DFSG text modification
Anton's ammendment is considered by Manoj to be "implicitly" modifying the DFSG, since the DSFG say that a license must "allow modifications", and with Anton's reading this would be "allow modifications". There's no way to "implicitly" modify the DFSG. So, to be clear, please include the diff of the text, so that everybody knows what he or she is voting for. This means the ballot needs to be re-written, I know. But modifying the DFSG without knowing what the text will be is not acceptable (From my point of view). -- Besos, Marga
Re: Anton's amendment
On 2/1/06, Yavor Doganov <[EMAIL PROTECTED]> wrote: > It is not an unbelievable conclusion. If I include your personal > position about, let's say, software freedom in my documentation under > GFDL, I have to put it in an Invariant section, otherwise people would > be able to change/twist your words and turn it into something > completely different. That is the whole purpose of these sections, if > they were not invariant, it wouldn't make sense at all. Ok, but by being invariant they are turning the documentation into non-free documentation. As you say, people won't be able to change it, therefore, it's a non-free text. You are free to license the documentation you write with whatever license you like. If you want to have a piece that is modifiable and a piece that it's not, it's your decision. But by having invariant sections you turn your documentation into non-free. I think that we agree that for a piece of software to be free, you have to be allowed to do modifications. And even if we don't go all the way to clarify "modifications to the whole program", it's implied in what we say: you are supposed to be able to modify anything you like, not just the particular part that the author of the program didn't mind being modified. With documentation it's the same thing, if you cannot modify the whole text, it's non-free. > As explained on http://www.gnu.org/licenses/fdl-howto.html, the > Invariant sections serve a special purpose, which is the case of the > GNU Manifesto. Many users, including myself, consider it a more > important part than the GNU Emacs Manual itself. How removing the > document, that inspired thousands to join the efforts, will make > Debian more free, I cannot tell... As it has been discussed here, having the Manifesto attached as invariant is not only non-free, but also quite problematic when you are trying to produce a derivative work that is either a) a compilation of many documents b) a reduced version of the document (as in a cheat-sheet or similar) c) printed on some non-paper medium (for example, a cup) d) you want to give out copies to students and want to minimize cost. All this is to say, no matter how much we agree or don't agree with the GNU Manifesto, having it as an invariant section might not be such a good idea (and, by not allowing to remove it, you've turned a perfectly fine manual into a non-free piece of documentation). -- Besos, Marga
Re: Anton's amendment
On 2/1/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > Could some one tell me why including the invariant sections of > a GFDL licensed work in main would not require us to modify the DFSG > or the social contract? > > Specifically, I am looking at the SC: > >> 1. Debian will remain 100% free > > And the DFSG: > >> The license must allow modifications and derived works, and must > >> allow them to be distributed under the same terms as the license > >> of the original software. Even though I strongly disagree with Anton's position and reading of the DFSG, I think that the point is that the text says "allow modifications" and not "allow for the whole source to be modified". Of course, the "spirit" of the DFSG is that of allowing to modify the whole text, but it's not explicitly stated, and thus allows for unbeliavable conclusions like "Invariant Sections are free". It would be nice to ammend that part of the DFSG to clearly state what we mean when we say that we want to be able to modify the work. But, until then, misreadings of the text can't be prevented. -- Besos, Marga
Re: GR proposal: GFDL with no Invariant Sections is free
On 1/25/06, Fabian Fagerholm <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 13:04 -0300, Margarita Manterola wrote: > > What would be the point of your proposal? I mean, if this proposal > > won, it would be exactly the same as if the "no GFDL in main at all" > > proposal won. So, why have yet another option? > My proposal was for the "two separate GRs" setup. > If there is not enough support for the "two separate GRs" setup, then I > will consider modifying my proposal to fit into the "one big GR" setup. > But I first want to see if there is any support. That's ok, I was asking about Nathanael's option, not yours. I understand yours, although I prefer to vote only once (thus, I prefere the 1 GR approach). -- Besos, Marga
Re: GR proposal: GFDL with no Invariant Sections is free
On 1/24/06, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > (2) all copyright holders state that the requirement "You may not use > technical measures to obstruct or control the reading or further copying of > the copies you make or distribute" in section 2 is waived with respect to > copies you make and do not distribute, > (3) all copyright holders state that the requirements of paragraph 3 of > section 3 (regarding transparent and opaque copies) are waived, > and > (4) all copyright holders state that the requirements of section 4.I > (requiring preservation of an entirely arbitrary History section) are waived. As I understood it, Adeodato's and Fabian's proposals were there to allow in main certain pieces of documentation (e.g GNOME's and KDE's) which don't have Invariant Sections, and cannot otherwise be relicensed (due to the death of some copyright holders). What would be the point of your proposal? I mean, if this proposal won, it would be exactly the same as if the "no GFDL in main at all" proposal won. So, why have yet another option? -- Besos, Marga
Re: For those who care about the GR
On 1/21/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > So, I am seeking arguments and guidance from the developer > body whether issue 1 can, and should, be decidable by a general > resolution, or whether the freeness of the GFDL licensed works > without invariant clauses is incontrovertibly non-free, as the > license is currently written. Although I haven't yet made up my mind about the issue itself (i.e if the GFDL without invariant sections is free or not), I consider that it is a matter of interpretation, and not a matter of fact, and therefore it can be decided by a GR. -- Besos, Marga
Re: GR Proposal 2: Declassification of -private
On 11/21/05, Eduard Bloch <[EMAIL PROTECTED]> wrote: > I do not see any reason for this GR since I cannot remember any serious > request to make -private mails public where this action would really > have been beneficial for the outside world. The reasons were stated in one of the first emails of this thread. There is important historical information hidden in the debian-private archives. Like the reasons why the social contract and the DFSG are the way they are. Many people that might not be interested in becoming Debian Developers (like someone who's studying Debian academically) might be REALLY interested in knowing the roots that made Debian become what it is. Also, people in the NM queue that have to agree to the Social Contract and the DFSG, might be interested in knowing why these documents have the shape they have before actually agreeing to them. I understand that the idea of this GR is not to reveal confidential information that people are not willing to disclose, but to reveal the information that might help non-DDs understand the history of the project. -- Besos, Marga
