Re: Q for all candidates: license and copyright requirements
On Wed, Mar 24, 2010 at 10:45:46PM +0100, Marc Haber wrote: On Wed, Mar 24, 2010 at 02:10:23PM +0100, Mike Hommey wrote: At the risk of repeating myself (I already said it in an answer to Charles' GR proposal), these core values are also what all DDs agreed to abide by. If Charles doesn't like Debian's core values, maybe he should resign. The last thing that Debian needs right now is losing even more personpower. Absolutely. And I consider that if our core values are erroded, then there would be a large loss of manpower. Neil -- Erik_J good day! i hear this might be a good place to get some technical advice when one is debian eliterate :) -- 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/20100325090156.gs28...@halon.org.uk
Re: Question to all Candidates: Who would you vote for?
On Wed, Mar 24, 2010 at 07:19:43PM +, Kalle Kivimaa wrote:
Stefano Zacchiroli z...@debian.org writes:
So, I apologize, but I'm not going to disclose my leader vote in public.
I think the better phrasing for the original question would be:
List reasons why the other candidates would make a good DPL.
This question does not ask you to divulge your potential vote - unless
you can find good reasons for only one candidate :)
Indeed, this version of the question is fair because, in essence, it
asks what do we think of other candidates _proposals_ rather then what
do we think personally of them. *But* :-) , I believe that I've already
addressed this in my rebuttals where, for each candidate, I've not only
mentioned my objections to their proposals, but also which among their
proposals I do like. I do not claim to have reviewed all proposals of
all other candidates, but I've surely mentioned the one I considered
most peculiar in the other platforms.
If someone seeks a specific comment of mine on some specific proposals
of the other candidates, which I haven't addressed in my rebuttals, I'll
be more than happy to post such a comment, but please be specific.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Standardization, large scale changes, innovations
Hello, those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). 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) 2/ If yes, what would be the next thing that it would be good to try to standardize/uniformize? 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.)? 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: - it might require advance preparation and planning, and you will not get enough review to have something final until the thing is available for use in unstable (so the initial design/planning might be wrong wich makes the whole process at risk) - you always have people that do not like the new thing and will try to make you feel miserable - you have lots of people not caring (for various reasons, not reading d-d-a or forgetting quickly, not willing to change something that works unless they are prodded, etc.) - you have to dedicate lots of time over a long period of time (in my case 2 Debian releases) - you have to convince separately a lot of people (for new source formats: ftpmaster, release managers, lintian maintainers, individual package maintainers) and there's always a risk that someone in power might block/stall the change (example: backports.org maintainer doesn't want to update dak to cope with new source formats) How can we change our processes so that doing/organizing such changes is less of a burden? 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? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325102236.ga30...@rivendell
Re: Question about membership.
Hi Charles, On Donnerstag, 25. März 2010, Charles Plessy wrote: [...] 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 [...] What do you mean by shortlisting? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Standardization, large scale changes, innovations
Le Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog a écrit : those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). Bonjour Raphaël, first of all, I would like to apologise in public for the the unkind comment I made about your work on debian-devel. I should have sticked to the facts instead of making a bad taste analogy. This said, I think that you guess the answer I will make to your question… I think that we should not standardise on tools, but on interfaces. To take the patch management systems as an example, there is a convergence on storing patches in debian/patch, and applying them through the ‘patch’ and ‘unpatch’ targets of debian/rules. I think that it is a good situation, and I recommend against making a particular implementation the standard. The debian/rules patching and unpatching targets were not unified at the beginning, so I think that it is a nice example of that such a convergence can be achieved in Debian. I would prefer that interfaces become codified when they attract independant implementations by their popularity. Let's take the git-core package for example. It uses files like debian/git-core.docs that have a similar function and mechanism that their similar counterparts in packages using Debhelper, but they are implemented via makefiles. If listing the files to be installed in /usr/share/doc/package/ in a debian/package.docs file is for instance getting standard by its popularity, then there will be an advantage to little by little make it more formal. I think that this example can be generalised. I maintain a lot of packages that are quite trivial, so I make a heavy use of helper tools. I find that one of CDBS and Debhelper (with or without dh) is often more useful than the other in a case-by-case basis, and would be quite annoyed if one of them were removed from my toolbox. I strongly share your feeling about innovation. Trust me, when I started to oppose the way you tie your patch system to the rest of the 3.0 source package implementation, I really balanced this with the fact that going for 3.0 (quilt) is anyway better than immobilism. I decided to confront your choices because what I am asking is not to withdraw your patch system, but to make it optional. This does not close the door, it just asks the people to make the step by themselves. You also described well the difficulty of introducing changes in our core package management system. I think that we can modify our release strategy in a way that would allow point updates to that part of our stable systems. A reorganisation of package priorities and sections would help to put a frame around this, and would allow other changes that I propose in my platform. To document and standardise interfaces is a good way to ease experimentation, and therefore innovation. Also, it would help to introduce changes in a way that is backward-compatible, and give more independance between developments on interacting tools, like dpkg and dak for instance. But there will always be situations in which people need to talk together and negociate reciprocal concessions. If I am elected DPL, I will ask the delegates to make sure that requests for coordination are not ignored, and that decisions are motivated. Not answering is the worse way to say no. Conversely, it may make sense to formalise the role of the maintainers of core tools like apt and dpkg by a DPL delegation. But this particular point is not listed in my platform, and I would not make it a priority. Of course, if maintainers sponaneously request to become delegates, I will consider their proposition very seriously :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100325134143.ga16...@kunpuu.plessy.org
Re: Standardization, large scale changes, innovations
Raphael Hertzog, 2010-03-25 11:22:36 +0100 : [...] 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) Please define “standardize” here. For the benefit of the candidates, let me say that if the meaning is “be allowed to shout at dissidents”, then in this case I don't believe it is a good move. [...] 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: [...] - you always have people that do not like the new thing and will try to make you feel miserable Fair's fair, you are also making them feel miserable. - you have lots of people not caring (for various reasons, not reading d-d-a or forgetting quickly, not willing to change something that works unless they are prodded, etc.) Unless there is a real benefit. Standardization for its own sake is *not* a real benefit. Please accept that there are cases where the v3 format brings absolutely nothing. Not to the packaging, not to the maintainer, and not to potential helpers because there are none. Case in point: the sourceforge/gforge/fusionforge package is coming close to nine years of existence, with zero NMU in the meantime, zero people working on the package on the Ubuntu side, and zero people complaining that adding a patch to their private copy is too hard. Where would be the advantage of switching to v3? Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- 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/87r5n8ears@mirexpress.internal.placard.fr.eu.org
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog wrote: Hello, those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). 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) It has advantages and disadvantages. The major advantage of standardized tools is that anyone can look at a source package and immediately start working on it. The major disadvantage of standardized tools is that if someone's workflow, or their packages' upstream's way of distributing things, does not agree with a particular standardized toolset, they would have a harder time working on their packages; or they could disregard the standards and (eventually) be frowned upon. Since I got fed up with undocumented non-standardized tools a few years ago, I filed a bug against policy which eventually, after a lot of discussion, resulted in the README.source bit in policy. I think that 'documenting' can be a great help in alleviating the disadvantages of the absense of standardized tools, without imposing any workflow on anyone. So no, I don't think we should standardize too much. There are cases where it makes sense (e.g., I don't think anyone would suggest allowing uploads of RPM packages to the archive), but we shouldn't overdo it; people should have the freedom to work in whatever way works best for them. 2/ If yes, what would be the next thing that it would be good to try to standardize/uniformize? I don't, so nothing :-) 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. 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: Indeed. This is another reason why we should't overdo it; unless there is a substantial benefit that cannot be gotten at in other ways, I think the downsides of trying to move the whole of the archive to something new can far outweigh the benefits. [...] How can we change our processes so that doing/organizing such changes is less of a burden? They are not. Consider how debhelper became a standard within Debian. Nobody ever started filing bugs, asking people to use debhelper; rather, someone (Joey Hess) wrote something, and uploaded that something to the archive. People liked it, and started using it. Some filed bugs, or patches, and debhelper improved as a result. So more people started using it, and more bugs/patches got filed. Etcetera. Note that when debhelper was first written, it was by far not the only thing available to build packages; e.g., there was debmake, yada, and a bunch of other things. These aren't used anymore, because debhelper eclipsed them all -- not because anyone told anyone not to use them. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I also think that dpkg's current nagging about the 3.0 dpkg formats are a mistake, for precisely that reason. People who don't like the 3.0 formats will ignore the nagging, and get annoyed; people who do not dislike it don't need nagging to eventually migrate, anyway. 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? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Question about membership.
On Thu, Mar 25, 2010 at 09:17:44AM +0900, Charles Plessy wrote: Dear all, 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 don't think this will help, at all. The DM procedure allows people to upload packages after just one Debian Developer has advocated them. This is a good way for people without full developer status to cooperate on Debian. Giving people full developer status should not be something we go over lightly. I happen to know that frontdesk and the DAM do not mind a 'lightweight' TS part of the NM procedure for those people who have shown exceptional skill. However, I don't think we should reduce on the PP part of NM. We do not wish people to join the project who do not understand what 'free software' means. [...] -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 7:22 AM, Raphael Hertzog hert...@debian.org 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 for the other candidates: supermajority.
On Wed, Mar 24, 2010 at 09:24:45AM +0900, 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?
I don't plan to work on that if elected DPL. I agree that that GR was
painful, but it has been so for a mixture of factors, including some
honest mistakes acknowledged by the past secretary which contributed to
his decision of resigning from the position (unfortunately for
everybody, a bit too bitterly).
During the discussions that started after the GR, I suggested that the GR
proposer should have more control about the options put to the vote. In
particular, it would be useful if he can refuse an option that would
disequilibrate the voting system. That would make him responsible for the
success of the GR: discarding a popular option is taking the risk that the
I don't like the underlying intuition that this entails, namely that the
GR proposer is somehow different from the other people which
contribute to the ballot preparation (e.g. seconders and proposers of
the initial and subsequent amendments). With the current way of
preparing ballots, all such contributors are equal. In fact, such
equality is also reflected by the fact that some people also second
amendments they won't vote for. This is quite nice as it highlights the
principle that GRs are a way to take decisions---used when everything
else fail---rather than an instrument to win in a specific battle.
(I'm not claiming you see GRs that way, I'm just explaining my bad
feeling about this idea.)
The only participant in a GR preparation which is more equal than
others is the secretary, which is already ultimately responsible for the
form that the various ballot entries take. Being the secretary means
having the trust of the project in how the constitution is interpreted
and ballots are prepared, that is IMO enough of a guarantee that shit
will not happen in ballot preparations (in that respect, the Lenny GR
only shows that we are all humans and that we can make mistakes).
For the supermajority, I think that it should be used only when
modifying directly foundation documents.
I fear this quite a bit. Going that way might open the flank to tricks
like leaving untouched the foundation documents, but actually subverting
them completely via some external procedure which is incompatible with
the *spirit* of those documents. (Yes, this is being a bit paranoid, but
constitutional rules, in any constitution, have some degree of paranoia
in order to be as much future-proof as possible.)
For instance, I believe that even if your GR proposal on copyright
(point (2)) does not affect the foundation *documents*, it is evident
from the related threads that more than a few DDs think it is in
contradiction with our foundation *principles*. I think we should have
the ability to interpret the constitution and declare 3:1 requirements
accordingly. I also think we should trust the project secretary in
judging that.
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 find this quite pointless. In Debian, as we are all volunteers, we
should always consider that decision making processes drain time away
from other, generally more pleasant, hacking activities. Now, it is
absolutely fair to go through them when there is something important at
stake. Nevertheless, having a full GR from start to end, with the risk
that only at the end it will be declared unconstitutional, is
something that smells of huge time wasting.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Question to all candidates: How would you enforce Debian Community Guidelines?
Hello, First of all congrats to all candidates and thanks for stepping up for doing this task. 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) Kind regards and good luck ! :-) [1] http://people.debian.org/~enrico/dcg/ -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- 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/dd0a3d701003250955r1a9f0a00oe5c39259845c6...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Wouter Verhelst wrote: How can we change our processes so that doing/organizing such changes is less of a burden? They are not. I can't accept the premise that we can't do better at this level. I managed to get my own project through the end (it's deployed, people can use the new source formats) but other worthwhile projects have not (or not yet) and I believe we should enhance our processes so that we can more effectively work _together_ on common goals (think of ddebs for example). Such projects are very difficult to do as one-man show in particular when you have no idea whether your work is going to used/deployed or not. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I try to convince through technology, I advertise the result through arguments. And I keep improving the formats based on the feedback that I explicitly request. 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? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. Please don't relate that question to the standardization question, it was not meant to. You answer is rather limited, I hope you can elaborate. We all have the freedom to experiment, we have all the sources, so why aren't we any longer innovating? And innovations only counts if it reaches a released product, otherwise it's only research. How can we go from successful experimentation to real innovations in our releases? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325170719.ga5...@rivendell
Re: Question for the other candidates: supermajority.
On Thu Mar 25 17:38, Stefano Zacchiroli wrote: I don't like the underlying intuition that this entails, namely that the GR proposer is somehow different from the other people which contribute to the ballot preparation (e.g. seconders and proposers of the initial and subsequent amendments). With the current way of preparing ballots, all such contributors are equal. In fact, such equality is also reflected by the fact that some people also second amendments they won't vote for. This is quite nice as it highlights the principle that GRs are a way to take decisions---used when everything else fail---rather than an instrument to win in a specific battle. (I'm not claiming you see GRs that way, I'm just explaining my bad feeling about this idea.) That not withstanding, there is still a legitimate point here. What happens when an amendment is proposed which has different majority requirements to the others? What happens when the secretary and the proposer disagree about the majority requirements? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Margarita Manterola wrote: 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. 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. 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. As I said to Wouter, the standardization question and this one are unrelated. 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? In any case, I think this question deserves its own thread. Agreed but too late. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325171741.gb5...@rivendell
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 2:17 PM, Raphael Hertzog hert...@debian.org 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 06:07:19PM +0100, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Wouter Verhelst wrote: How can we change our processes so that doing/organizing such changes is less of a burden? They are not. I can't accept the premise that we can't do better at this level. I managed to get my own project through the end (it's deployed, people can use the new source formats) but other worthwhile projects have not (or not yet) and I believe we should enhance our processes so that we can more effectively work _together_ on common goals (think of ddebs for example). To be honest, I'm not sure I understand what the problem you're discussing here, is. Within Debian, and within the larger free/open source community, the most popular way to convince people that some code is a good idea, has always been to let the code speak for itself. If you want people to send patches your way, then write the nice and innovative ideas first; the grunt work will follow. If you want people to accept that something is a good idea, the best way to do that is to make sure it actually *is* a good idea. If enough people agree with you on that, the rest will go automatically. A very good example of that is debhelper; nobody ever told anyone to use it, yet most of our packages do, directly or otherwise. Common goals will be worked on by many people if they are, indeed, common goals. If someone does not believe ddebs are a worthy goal, it will be very hard to make him work on that. I believe that's a good thing, because it means that only those things which actually are found to be good ideas by most people will actually be worked on. Such projects are very difficult to do as one-man show in particular when you have no idea whether your work is going to used/deployed or not. That's normal in Free Software, and it's something we all have to live with. I've started working on ipcfg with the hope that someone would eventually use it, but I've so far not convinced many people yet. I can only assume this is because it's Not There Yet, and will have to continue working on it. Sure, that can be demotivating, but that doesn't mean I'm doing a bad job. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I try to convince through technology, I advertise the result through arguments. And I keep improving the formats based on the feedback that I explicitly request. I don't think there's any better procedure than that in convincing people to use your technology. 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? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. Please don't relate that question to the standardization question, it was not meant to. Okay; that wasn't clear. You answer is rather limited, I hope you can elaborate. Not sure I can. We all have the freedom to experiment, we have all the sources, so why aren't we any longer innovating? I'm afraid I don't have an answer to that one. Perhaps it's because there isn't much new that can be done anymore which lies strictly within the realm of what a distribution does? Or perhaps it's because we just don't attract the kind of people who would do innovative new ideas? I'm not sure either way. What I am sure of, however, is that the lack of current innovations don't necessarily mean that nothing is happening. After all, whether something is a good idea only becomes clear once several people have actually tried to use it, and were convinced. So that means that it takes a while before a new innovation is well-known within the community. And innovations only counts if it reaches a released product, otherwise it's only research. How can we go from successful experimentation to real innovations in our releases? Upload And Blog About It(TM). If it's a good idea, people will use it. If it's not a good idea, it will rot. Such is life. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
* Raphael Hertzog (hert...@debian.org) [100325 18:18]: On Thu, 25 Mar 2010, Margarita Manterola wrote: 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. You got me wrong. I don't want to change our processes to force people to adopt new tools. Reading how you annoy people who don't use your new toy, this sounds different. Andi -- 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/20100325180225.gw19...@mails.so.argh.org
Re: Question for the other candidates: supermajority.
On Thu, Mar 25, 2010 at 05:16:33PM +, Matthew Johnson wrote: That not withstanding, there is still a legitimate point here. What happens when an amendment is proposed which has different majority requirements to the others? What happens when the secretary and the proposer disagree about the majority requirements? This has happened before. The secretary adjudicates any disputes about interpretation of the constitution. I would suggest that in future, it doesn't get this far by a proposer asking the secretary for their probable view *first* if they're proposing anything which may require a supermajority. Or anyone could simply ask the secretary for advice about any GR, and I'm sure they'd receive a comment about phrasing/legitamacy/quorate etc. Neil -- weasel dpkg: shut up dpkg No, I won't, and you can't make me. :P weasel hah. _I_ can -- 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/20100325183727.gt28...@halon.org.uk
Re: Q for the Candidates: How many users?
So at the start of the week, I asked: On Mon, Mar 22, 2010 at 05:19:20PM +1000, Anthony Towns wrote: Bearing in mind: * www.debian.org/social_contract says Debian's priorities are our users and free software, * popcon.debian.org currently reports 91,523 submissions, * popcon.ubuntu.com currently reports 1,493,440 submissions, and * that this is something of a trick question, What's your estimate of the current number of Debian users? (I haven't seen a reply from Charles Plessy, but it's been a few days, so moving on seems fair...) For me, the trick part of the question is whether or not the machines reporting to popcon.ubuntu.com should be counted as Debian users, both Stefano and Marga picked up on that, without actually stating an opinion either way: On Mon, Mar 22, 2010 at 09:49:47PM +0100, Stefano Zacchiroli wrote: I've already reported in a previous thread on -vote [1] about the study by Gaudenz Steinlin showing that our user base has been decreasing steadily since the first release of Ubuntu (whose users you might want to consider as Debian users or not). [1] http://lists.debian.org/debian-vote/2010/03/msg00143.html On Wed, Mar 24, 2010 at 03:08:29PM -0300, Margarita Manterola wrote: Do Debian users include Debian derivatives users? :) There's a bunch of people who use Ubuntu as their main systems these days who've said things like yeah, I know, I'll install Debian on it some time, but this was just easy for now. For me, I tend to consider them to already be using Debian systems -- I mean, they're already using all the Debian-specific programs I've written or worked on for Debian, so what difference does it /really/ make if it's all coloured brown or purple instead of swirly and red? I don't see a difference, so I count them as Debian users personally. YMMV (if it does, I'd be interested to hear what important differences you see) If Ubuntu systems count as Debian systems, who, in that case, counts as Debian users as far as the social contract's concerned? The actual people who install it, even if they've never heard of Debian? Maybe the Ubuntu devs who are pulling source from Debian? Debian developers nominally promise to put our users first in our priorities, right up there with free software itself. Based on the popcon numbers it's possible almost 95% of Debian's userbase get at Debian through Ubuntu. Using Google trends or distrowatch or others would probably give you different percentages, but it still seems pretty significant, and maybe warrants more attention. Stefano and Marga both wondered explicitly what the point is: On Mon, Mar 22, 2010 at 09:49:47PM +0100, Stefano Zacchiroli wrote: I'm not going to give an actual estimate because I lack a significant amount of needed data and, frankly speaking, I don't see why the exercise of actually arriving at a number might be interesting as campaigning material (if I'm missing something fundamental about why it is so, please explain). On Wed, Mar 24, 2010 at 03:08:29PM -0300, Margarita Manterola wrote: 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 haven't picked who I'm voting for yet, so it can't actually change my vote... That aside, I think it lets the candidates demonstrate how they approach a problem, which can be interesting. * do they actually answer the question or avoid it? - Wouter gave a guess based on a multiplier for the popcon data - Stefano declined to give an answer, but suggested augmenting the popcon data with download counts from mirrors and security.d.o, along with a reference to some related research - Marga declined to give an answer beyond a very conservative many more than [the] 90k [from popcon] - Charles hasn't answered yet * how do they react to the Ubuntu reference? - Wouter mostly ignored it, and said I don't think it holds any relevance to what we do in relation to whether popcon should be opt-in or opt-out - Stefano noted our user base has been decreasing steadily since the first release of Ubuntu and was concerned about it - Marga didn't mention it, except to ask if users of derivatives count as users of Debian * when asked a pretty straightforward question, do they have any new/deep insights? do they do any interesting analysis to come to a more useful conclusion than others are able to? - For me, those are pretty much killer features in a candidate for just about anything. YMMV :) * do they build on other people's estimates, or change their own based on new ideas by other people? - It's free software, collaboration is important. It's an election, collaboration is Just Not Done. The other aspect is, how can you say we're listening to our users? if we don't even have any idea how many of them there are? And
Re: Standardization, large scale changes, innovations
Wouter Verhelst wrote: A very good example of that is debhelper; nobody ever told anyone to use it, yet most of our packages do, directly or otherwise. Parts of Debian encourage experimentation, innovation, and evolution of better solutions: parts don't. That debian/rules is a flexible, standard interface, and the lack of any obstacles to providing code that hooks into it has allowed many approaches to be tried. Compare adding a new suite like testing. The barriers to innovation there are high, including needing set up a copy of the archive (or being one of the few trusted to work on the real one), but also one has to overcome collective innertia and convince everyone they should care about the new suite. I don't know if Debian has become more resistent to innovation. Could be that the easy areas are increasingly tapped out. The exciting potential of dpkg source v3 to me is that it potentially opens an area that had stifled most innopvation, by allowing subtypes of the source format to be developed. But this area is still relatively closed to innovation; dpkg's maintainers still need to sign off on new formats, and the v3 source handling in dak is AIUI unneccessarily limited/hardcoded to only supporting certian subtypes. -- see shy jo -- 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/20100325195143.ga4...@kitenet.net
Re: To all candidates: personal mentoring
On Thu, Mar 25, 2010 at 12:15:45AM +0100, 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).
I do realise that personal mentorship takes time; that's a reason to set
criteria [1] and thresholds on who gets to have a mentor [2], instead of not
considering the idea all together.
In my AM experience (still limited, about 6 months now), what has
surprised me most is the room that there is for mentoring the applicant,
instead of simply having him/her just going through the various steps of
NM which are supervised by the AM. This is probably something that all
AM have experienced, but I confess that it wasn't that clear to me and
it is probably similarly unclear for perspective applicants. That is to
say that we do already have some form of personal mentoring, during NM.
Still, in your question you're hinting at some earlier mentoring, and I
believe that should happen in teams. In a sane team-based working
distribution, which is de facto already the case for most areas of
Debian, new contributors approach a team because they want to contribute
there, and it is in the team that they start getting a feeling of the
project. That kind of team-mentoring already works quite well: if you
look at the -newmaint archives you will notice that most advocacy mails
for both NM and DM come from co-team members which have worked with the
new contributor (and most likely taught him/her things about the
project, ... and yes, they will notice if the contributor gets ran down
by a bus).
That is why I like the http://www.debian.org/Teams/ page. Ideally, that
can become the welcome place for new contributors which will first look
around what they like to do and then approach the corresponding team on
the suggested media.
In principle, we can additionally establish within team some form of
personal mentoring with the goal of bringing accompanying the newbie to
the advocacy mail. In practice I doubt it would change much the status
quo, but I agree it might be nice from the newbie POV (e.g. he/she will
have someone to mail when feeling unsure about some course of action).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question about membership.
On Thu, Mar 25, 2010 at 09:17:44AM +0900, Charles Plessy wrote:
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.
The reason to be somehow strict before accepting someone as a DD is
essentially trust. A DD will be able to upload any package to our
distribution, so we should trust his/her judgement in when to (not) use
such a privilege.
Of course it is difficult to come up with a metric for trustworthiness.
Nevertheless, a metric that works surprisingly well in practice (at
least in our volunteer-based FOSS world) is to look at what and how the
applicant has done in the past [1]. This metric is actively used in the
NM process where it is paired with questions on our principles.
The problem I see with what you propose is that the time they have
already spent in the project is, for once, not well defined (when do
you start counting?). Additionally, it tells you: nothing about the
abilities of the applicant, nothing about his/her interactions with
other, nothing about how much he/she share our principles. So if, as you
observe, there is resistance to nominations, I doubt that adding time
would do any better.
[1] note that the implicit stuff done that I intend here is more
general than packaging, it also includes stuff like interaction
with others
I have put membership issues as a first priority in my
platform. Partly because
Yes, but as I've observed in my rebuttals I haven't really got what you
are _actually_ proposing.
So my question to other candidates is simple: what is your opinion and
program about membership?
I've discussed this quite extensively in my platform already.
To recap:
- The addition of DMs have been very good for our project.
I like the existence of such a status, but I believe we should
reward DMs more, in terms of visibility. On one hand, we currently
have quite a mess of terminology which we might want to fix, even if
it is hard to do that at this point. On the other hand, we should give
out some symbolic gift, like a @debian.org email address (just an
example, we can find another sub-domain or something): it might seem
silly to all of us, but it can be important for newbies!
- I would like to see a proper vote---no matter its result---on the
establishment of a new project member status (i.e. with voting rights)
for non-packaging contributors.
The GR we had on DAM proposal [2] has been only on the procedure which
led to the d-d-a mail. In fact, the outcome of the GR asks for
discussion+consensus (or vote), but we've never dwelled into that
afterwords.
Cheers.
[2] http://www.debian.org/vote/2008/vote_002
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Q for all candidates: license and copyright requirements
On Wed, 24 Mar 2010 08:27:43 +0900, Charles Plessy wrote: Salut Charles, Our users, if they want to modify, study, redistribute or use after rebuild our ^^ system, need the source. At no moment these operations involve modifying a RFC ^^ ^ The marked spots above seem to be a contradiction to me. or a binary program that is aimed at run on a Windows system. I conclude that that kind of file, although present in our source packages, are not part of the source of our operating system. JFTR: Like some others I disagree on this point of view. IMO Debian, the distribution consists equally of binary and source packages, so if a package wants to be considered free as defined by the DFSG there must not be any non-free parts neither in the binary nor in the source package. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Peter Ratzenbeck: Recycling Rag signature.asc Description: Digital signature
Re: To all candidates: personal mentoring
On Thu, 25 Mar 2010 20:08:00 +0100, Stefano Zacchiroli wrote: Still, in your question you're hinting at some earlier mentoring, and I believe that should happen in teams. [..] That is why I like the http://www.debian.org/Teams/ page. Ideally, that can become the welcome place for new contributors which will first look around what they like to do and then approach the corresponding team on the suggested media. /me agrees twice. In principle, we can additionally establish within team some form of personal mentoring with the goal of bringing accompanying the newbie to the advocacy mail. In practice I doubt it would change much the status quo, but I agree it might be nice from the newbie POV (e.g. he/she will have someone to mail when feeling unsure about some course of action). JFTR: There was a BOF around these questions during the last DebConf; the summary and some resources are linked from http://wiki.debian.org/Teams/Resources Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Tom Waits: Day After Tomorrow signature.asc Description: Digital signature
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
Hi Héctor!
On Thu, Mar 25, 2010 at 05:55:35PM +0100, Hector Oron wrote:
First of all congrats to all candidates and thanks for stepping up
for doing this task.
Thanks! :-)
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)
[1] http://people.debian.org/~enrico/dcg/
Some of us have already discussed briefly Enrico's Debian Community
Guidelines in the heated discussions thread [1]. My main comment on
that [2] is as follows:
[...] As an AM I've noticed that there is quite some margin of
coaching in the NM process [...]
That is a point where we might benefit from introducing some good
lectures such as the Debian Community Guidelines (drafter by Enrico
Zini), which we've really never tried. Having applicants read them,
discuss them with their AM, and possibly sign them, will be a small
step which we might start benefiting from a few years from now.
I've then observed in a different thread that I don't think community
guidelines should be enforced any further. I don't believe guidelines
should be used as sticks to beat others: they shape the project culture
and are most effective when peer pressure among the involved peers
refers to them.
Thanks for your question!
Cheers.
[1] http://lists.debian.org/debian-vote/2010/03/msg00058.html
[2] http://lists.debian.org/debian-vote/2010/03/msg00072.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question about membership.
Charles Plessy ple...@debian.org writes: 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 don't see why someone who joined the project a few months ago should be trusted less than someone that got in, for example, before we had any formal checking of new members. This idea just doesn't work. Marc -- BOFH #198: Post-it Note Sludge leaked into the monitor. pgp9Xipk3outH.pgp Description: PGP signature
Re: Question for the other candidates: supermajority.
On Thu Mar 25 18:37, Neil McGovern wrote: On Thu, Mar 25, 2010 at 05:16:33PM +, Matthew Johnson wrote: That not withstanding, there is still a legitimate point here. What happens when an amendment is proposed which has different majority requirements to the others? What happens when the secretary and the proposer disagree about the majority requirements? This has happened before. The secretary adjudicates any disputes about interpretation of the constitution. I would suggest that in future, it doesn't get this far by a proposer asking the secretary for their probable view *first* if they're proposing anything which may require a supermajority. Or anyone could simply ask the secretary for advice about any GR, and I'm sure they'd receive a comment about phrasing/legitamacy/quorate etc. Indeed, however, where there is a clear disagreement it would be nice to have a policy of whether we a. don't run the vote until everyone agrees and is happy, b. don't run a vote with mixed majority options, c. run whatever vote is proposed with whatever majority options the secretary thinks is correct (which is I believe the current situation which lead to the arguments mentioned in the OP) d. all / none of the above. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Question about membership.
On Thu Mar 25 21:19, Stefano Zacchiroli wrote: The GR we had on DAM proposal [2] has been only on the procedure which led to the d-d-a mail. In fact, the outcome of the GR asks for discussion+consensus (or vote), but we've never dwelled into that afterwords. I did try quite hard, but it never got anywhere Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
On Thu, Mar 25, 2010 at 1:55 PM, Hector Oron zu...@debian.org 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
Rebuttals.
Hi, All the rebuttals have been added to the platforms now, but they're not yet available on all the mirrors. Kurt -- 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/20100326000939.ga31...@roeckx.be
Re: Question to all candidates: How would you enforce Debian Community Guidelines?
Le Thu, Mar 25, 2010 at 05:55:35PM +0100, Hector Oron a écrit : Hello, First of all congrats to all candidates and thanks for stepping up for doing this task. 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) Kind regards and good luck ! :-) [1] http://people.debian.org/~enrico/dcg/ Dear Hector, this is a very interesting reading that I overlooked. I see it more like a turorial than a document to refer to when commenting about other person's behaviour. My main worry is that, the more complex the guidelines are, the more meta-discussion they generate if they are used as rules. Just see the quantity of traffic dedicated to complain about email carbon copies, for instance… (In theory, this particular problem has been solved smartly by Raphaël, but in pactice this update of our mailing lists's code of conduct is often ignored.) If I would have the time to propose a an additional section to Enrico's guidelines, it would be to warn against topical isolation. It is more fun, and we are stronger, when we collaborate in building interdependant works. When I started to involve myself in Debian, I wanted to create a ‘Debian-Biology’ effort but Andreas Tille convinced me to join Debian Med instead. I never regreted it. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326004144.ga19...@kunpuu.plessy.org
Re: Q for the Candidates: How many users?
Dear Anthony, sorry for not keeping up with the answers, this campaign is very intensive ! It is interesting that your question was a kind of mini-experiment. As a molecular biologist, I like experiments a lot. Below is the draft that I never sent because I did not find time to add some flesh to it. Please take it as somehing that I thought is not ready to be sent, but that reveals bits about my state of mind before you announce the result of youre experiment. Have a nice day, -- Charles Le Mon, Mar 22, 2010 at 05:19:20PM +1000, Anthony Towns a écrit : What's your estimate of the current number of Debian users? Le Mon, Mar 22, 2010 at 02:27:23PM +0100, Bernd Zeimetz a écrit : That results in a different question for me: Does Ubuntu enforce the usage of pocon, and should Debian do so, too? Hi Anthony, Bernd, everybody, I do not know if Ubuntu has Popcon switched on by default. But on the upstream mailing lists where I am subscribed, I think that I see more Ubuntu users than Debian users. Since it is lists about scientific software, this worries me. What is Ubuntu giving them that Debian does not have? We do not play 3D games at work, and use LAN cables more often than wireless. Not to mention that Debian also provides non-free drivers for the users who need them.. -- 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/20100326010250.gb19...@kunpuu.plessy.org
