Re: [all candidates] discussions in -devel
On 2013-03-19 17:00, Serafeim Zanikolas wrote: Our usual approach of darwinism (whereby a single hacker's solution gets gradually adopted) does not work here because any attempted solution (social, technical or both) requires some kind of upfront policy change (and, for technical measures, some kind of infra change). How do you propose that we go about dealing with this issue, keeping in mind that it's imposs^Wchallenging to get to consensus about non-technical and potentially controversial policy (moderation) changes? I've already made some comments related to this, see the previous thread starting at http://lists.debian.org/debian-vote/2013/03/msg00116.html More generally on unproductive -devel threads: I think problems usually arise from the style of a thread, beyond just one or two loud people. Enrico's Debian Community Guidelines contain some good material related to your question, see in particular http://people.debian.org/~enrico/dcg/ch02s05.html#comm-howto-longthreads A few points that I think people too often forget: - Make it clear why you're replying, and what course of action you are advocating with respect to the overall problem under discussion. While "me too" replies aren't generally useful, if you're replying at all it's good to point out things that you agree with, not only state disagreements. - Try to separate discussion of goals from discussion about actions. If you are replying to disagree, be clear if you are disagreeing about the proposed goal or about the proposed actions to reach it. If you are starting a discussion, be aware that it may be easier to agree on a set of goals first before discussing the best technical path to get there. - If you disagree with the proposed goal, be clear whether you want to keep the status quo, or are advocating some other outcome. - People should try to make their contributions to a thread build on what has gone before, not just steer discussion towards a minor point. If the bigger picture is being lost in a subthread, try to help things by summarising what had been said so far, and the main points of discussion, before offering your own view. - Consider that not all readers will be as familiar with the issues as you are. Don't be patronising, but try to help anyone in this position by stating things clearly. Perhaps someone who disagrees with you is just missing some important information. Don't treat them as malicious, but explain your own reasoning and see if it changes their mind. But remember that it might occasionally be you who is missing important information. - Realise that other people may assign different weights to the arguments in favour of each option. Perhaps they know the same facts as you, but have different priorities from you -- if so, try to understand why this is. - If someone seems to be suggesting something stupid, consider the possibility that you have interpreted the words they said in a different way from the one they intended. You should probably still seek clarification and perhaps state your opposing point of view, but avoid starting by attacking their apparent stupidity. - Changing your mind in the course of a discussion, after hearing new facts or new arguments, should be seen as a sign of wisdom, not a sign of weakness. -- Moray -- 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/d484ca770ec8fad8f91ec6d9b49fe...@www.morayallan.com
Re: [all candidates] Return to the desert island (cont.)
On 2013-03-19 16:39, Jérémy Bobbio wrote: Dear candidates, do you think that libechonest [3] should be called free software? As it requires software outside of the distribution to function, do you think it should be moved to contrib? What about s3cmd [4] then? I don't think that having the facility to fetch or process non-free data makes software non-free. It is normal for tools to be agnostic about the licensing of data they process, even in cases where it's almost certainly non-free. For example, the licensing of DVB broadcast content is very unlikely to be free, but I don't think we should move all DVB programs to contrib. However, I would agree that making our users dependent on non-free data sources is bad. This kind of problem isn't new: an old example is the track information used in CD ripping tools. In that case community efforts created free alternatives that the tools could use instead. As a general principle, we might want to discourage default installations of packages from automatically pulling in non-free data and thus encouraging users to become dependent on it. -- Moray -- 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/6adceccb48e947c36d8a21ad4610e...@www.morayallan.com
Re: [all candidates] Removing or limiting DD rights?
On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote: > On 25/03/13 at 16:22 +, Steve McIntyre wrote: > > Are we strict enough with our existing contributors? When we're trying > > to work together as best we can to make the Universal Operating System > > happen, what could/should we do with contributors who hinder our work? > > Sometimes that hindrance is inadvertent, sometimes it seems > > deliberate. At other times it looks like we have developers who are > > just not paying attention to what they're doing or who just don't care > > about the goals of the project. Thanks for this question, which I would like to extend a bit. Im my understanding you are pointing to unconstructive behaviour related to technical work. What we also see (and discuss) every now and then is behaviour that is socially questionable or clearly unacceptable (from disrespect for peers to blatant abusive language). I guess we all remember such examples, which have led to demotivation, frustration, hurt feelings, and have driven contributors away. Lucas' reponse already shows an idea that might also be used for these cases: > One small thing that we could improve on is earlier official > communication. For example, in case of seriously problematic behaviour > that could eventually lead to censure or expulsion, official warnings > could be issued to the DD, and Cced to -private@. In some cases, that > could help the DD realize that s/he needs a behaviour change, and also > limit the surprise effect if/when a final decision is taken. What other ideas do you (plural, for all candidates, in case you see the necessity to improve the handling of "social problems") see as viable? Examples that have come up in the past and might or might not be helpful: - Encourage everyone to chime in when they see potentially unacceptable behaviour? In public/private? - Should we try to establish a Code of Conduct for project members? Cf. https://openhatch.org/wiki/Project_codes_of_conduct for examples. If yes, how would we do this, and how could we make sure it gets respected? - Could the CoC for mailing lists (http://www.debian.org/MailingLists/#codeofconduct) be used as a starting point / be extended? - Or Enrico's Debian Community Guidelines? http://people.debian.org/~enrico/dcg/index.html - Another recurring topic is the Social Committee, cf. e.g. https://lwn.net/Articles/221077/ (or the ombudsman team mentioned in the article: https://lists.debian.org/debian-project/2007/01/msg00101.html ) Would such a body make sense? With which powers? Short summary: Does Debian need procedures for intervening in cases of dysfunctional social behaviour and which? Thanks to all of you for standing/running in this vote, and for taking the time to answer all these questions! Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Rod Stewart: Smile signature.asc Description: Digital signature
Re: [all candidates] on distribution-wide changes and scalability
Stefano Zacchiroli writes: > Folklore goes that performing distribution-wide changes in Debian is > hard and time-consuming, due to a couple of reasons: (1) the time needed > to make a decision that affects the whole archive (this is related to > our flat structure, which has many benefits, but surely not that of > providing a clear decision structure for cross-cutting concerns), and > (2) the time needed to deploy the needed technical changes in all > affected packages. It is, indeed hard and time consuming. I do not neccessarily see that as a problem, but see below. > This "inertia" folklore is surely supported by past history of the time > it took us to deploy specific changes in large sets of packages. But on > the other hand, in the last 5 to 10 years we have massively improved our > ability to decide and deploy large changes by the means of: (a) large > maintenance teams who are able to decide on "their" packages and deploy > changes using shared-access VCS, and (b) a more liberal use of NMUs than > in the past. > > Questions for the candidates: > > - on the judgement spectrum between "there is no inertia in Debian and > that's good" and "there is a lot of inertia in Debian and that's bad", > where would you put yourself? On both sides, of course, and sometimes somewhere inbetween. We've seen cases where we had inertia, and turned out it was useful. We've seen others where it turned out to be a bad thing. So it really depends on the context. > - if you don't think that we're at our best on this front, what do you > propose we change to improve? (See below, but keep the above statement in mind.) > As mere thought experiments, feel free to consider the following > possible "changes" as part of your answers: > > - Debian should use the Technical Committee more proactively than we > presently do, to decide on "any technical matter where Developers' > jurisdictions overlap"; not only to solve conflicts (as we already > do), but also to *design* forthcoming changes in an authoritative > manner. [ Many large FOSS projects out there have technical boards > that work that way. ] Involving the tech-ctte earlier may be a good idea, but pushing the task of designing forthcoming changes onto them, even if done in cooperation with the other parties involved, is not something I'd push for. I see the tech-ctte more as a decision making body, or a technical mediator, than an entity that designs change. Getting the tech-ctte involved more often, not only as a last resort can have benefits, but then we need to make clear that we expect help, and not neccessarily a solid decision. (FWIW, Constitution 6.1.5 already grants the tech-ctte to offer advice, we should exploit this power more often, and more pro-actively.) > - Debian should decide to use a single VCS (say, Git), for all packages, > uniform repository structure and work-flow, and give by default > read/write access to all DDs. This would allow push-button changes to > all packages in the archive. We often speak about "reducing package > ownership" during DPL campaigns, well, this is the ultimate step of > it. [ Ditto: I know no other large FOSS project out there allowing > the extreme diversity in VCS, work-flow, and ACLs that we have in > Debian at present. ] No. Most definitely no. There is *no* structure, nor workflow that fits all packages and all packagers, trying to force one down our throat would be counter productive. While this would certainly have advantages, I find the costs too high: - Adapting to a single repository structure can be needlessly painful (esp. when you need to adapt the upstream structure too) - Settling on a single VCS is not going to happen, ever. - Sometimes it is more convenient / straightforward to use the same VCS upstream uses (which may or may not be git). (Especially when one is upstream) - Sometimes one is maintaining the same package for not only Debian, but derived distributions aswell, which use or prefer another VCS. Trying to force the hand of our downstreams this way is not productive, in my opinion. - There is no workflow that fits all scenarios. Trying to shoehorn everything into a simplified view is just going to hurt in the long run. - People are people, they're hard to change, and in a purely volunteer based project, that has a long history of giving pretty much free hand to the maintainers as long as they comply with policy and some amount of common sense, moving towards a more controlled environment by force is bound to cause quite an uproar. (I've worked with BSD ports/pkgsrc for quite a while, where there is a single VCS, a uniform repository structure, and pretty much one canonical workflow. It was horrible. So very inflexible, it was a pain to adapt things that weren't designed with that particular layout & workflow in mind.) I'm all for encouraging putting packages under collab-maint or team maintai
Re: Debian for third party (read: propietary) apps/vendors
Lisandro Damián Nicanor Pérez Meyer writes: > There are third party vendors (read: propietary) that support the > installation > of their software in Debian, but mostly because selfish reasons: they need to > be present everywhere for their business model to work. A clear example of > this is Skype. Most proprietary packages exist for the same reason: there's demand for it, demand that can be turned back into money. Very few (if any at all) proprietary vendors package up their software for distributions just to be nice. > Now there is a second class of apps/vendors which do not need to be ubiquitous > for their business model to work. Most of the examples that come to my mind > are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of > propietary vendors that give support for Linux but just on Red Hat and > sometimes, Suse. And they are a PITA to make them work on Debian. This makes > IT workers need to have RH/Suse/CentOS boxes even if the rest of them run > Debian. [...] > Now my question is: without going against the Social Contract, is there > anything Debian can/should do wrt this situation? The difference between Debian, RedHat and SLES (SUSE Linux Enterprise Server) is that there's commercial support behind the latter two, there's a company where vendors can turn to if they need support. There's no such entity behind Debian. There are companies that do sell Debian support, but that's not quite the same. This status quo means that vendors rarely invest into preparing Debian packages, because only a very small percent of their users are running Debian (due to their business requiring support contracts from the vendor, which is much easier and straightforward to obtain in the RHEL/SLES cases, for example), and investing into making proper Debian packages is simply not worth it. As such, there's nothing Debian can or should directly do. On the other hand, we have downstream distros where the parent company does provide similar support guarantees that RHEL and SLES do. If third party vendors start creating packages for these distributions, that may very well make it easier to run said software on Debian too (like how the RPMs are often run on CentOS instead of RHEL). This would help Debian users who, for some reason, need to run said proprietary software. But even then, I would not wish Debian to go to great lengths to accomodate non-free software. We should not make it unnecessarily hard, either, but that's about it. If vendors don't provide Debian packages, there's nothing we - as a project - can or should do to change that. We're not the users that matter for the vendor, we're a target platform, and it's not the platform that matters, but whether there's enough users to make the effort of supporting the platform worth it. (It's not like it's hard to make debian packages. It most definitely is not. It isn't particularly hard to support Debian stable, either [my employer provides packages for one of our propriertary tools for Debian Sarge(!) too, it's not terribly hard].) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v5a899d@galadriel.madhouse-project.org
Re: [all candidates] delegation
Thomas Goirand writes: > One of the key role of the DPL is to delegate. > > What are your intention in this regard? Do you think that the current > teams and roles are well filled? Or would you like to change some of the > people currently holding a position? Why (not) changing anything? I believe that the current delegations are well deserved, if elected, I wish to reaffirm people currently holding a position (unless they wish to step down, of course). On the other hand, most of our teams are lacking manpower, which is something I would like to improve. To remedy the situation, I'd need to learn a bit more about the various teams than I was able to while peeking in from the outside. I'd like to think that we have quite a bit of manpower to spare, we just need to aim them at the right team. Or if that fails, improve our recruitment to make joining the teams lacking manpower most more appealing, and more rewarding. In some cases, likely more visible, and better defined too. I also plan to delegate more tasks, to make the DPL job sustainable in the long run. These would include representational tasks just aswell as organising things on behalf of the DPL, and so on and so forth. I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2um8f49@galadriel.madhouse-project.org
Re: [all candidates] Removing or limiting DD rights?
Steve McIntyre writes: > Are we strict enough with our existing contributors? When we're trying > to work together as best we can to make the Universal Operating System > happen, what could/should we do with contributors who hinder our work? I do not believe we're strict enough, not in general. On the other hand, I'm not a big fan neither of overruling DDs, nor of limiting them. I'll explain below. > Sometimes that hindrance is inadvertent, sometimes it seems > deliberate. At other times it looks like we have developers who are > just not paying attention to what they're doing or who just don't care > about the goals of the project. Occasionally we see direct action to > censure or even expel DDs, but these are only ever in the most blatant > of cases. By the time that happens, large amounts of damage may be > done to the project: delayed releases, lost users, loss of motivation > for other contributors. > > I'm wondering: is this something that you think is a real problem, and > if so what do you think we could do about it? The worst case (when it comes to expelling or severely limiting a DD) is fairly rare, and I certainly hope it will stay that way (and we really should not let things get that far). However, causing damage (due to negligence and/or lack of attention) is far more common, and is a real problem, one we should be dealing with much, much better. The salvaging effort was/is something that gave me great hopes, because it approached the problem from a less personal angle. The less personal an effort is, the more successful it can be in this case, as far as I see. Telling people they're harming the project is a lot different than telling them that a particular package needs more love, and then going ahead to aggressively hug said package to give it more love. I think the salvaging idea is something that we should push forward with, aggressively. While this is not a solution to every problem, it would help in quite a lot of cases. How well this works, also depends on the people involved, so great care must be taken to avoid as many bruises as possible. (But not at the expense of dropping it alltogether and doing nothing! Better some bruises and a handshake months or years later than silently holding grudges forever.) But alas, salvaging will not solve everything, and in some cases, it is likely not an option either. In those cases, we should not be afraid of overruling the maintainer, and if need be, forcibly transfer the package to someone else. Yes, this would also have consequences we'd rather avoid, there would be bruises, but if there's no better option, when all other kinds of negotiations failed, then I see no better option. Negotiation is something we should perhaps be practicing more, and earlier. In short, we have the procedures to completely revoke or severely limit DD powers, but this is a power we should exercise rarely. Instead, we should work towards discovering problems much earlier, and work more aggressively towards resolving them, before more harm's done. Among our tools to help with this quest, we have salvaging, and once a problem's discovered, earlier negotiation attempts, possibly involving the DPL as a mediator. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hajy8g4s@galadriel.madhouse-project.org