Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Manoj Srivastava wrote: This is great!! perhaps we can get rid of the abomination that is vi and get everyone to use the one true editor all at once. I suggest you change your tone. You have the right to not share my point of view, but there's no need to be sarcastic. What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. 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/20100330091601.gh28...@rivendell
Re: Standardization, large scale changes, innovations
On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Manoj Srivastava wrote: What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. Is making things easy for newcomers or casual helpers really so important that we should risk scaring already active people away because they have to adapt their optimized workflow for newcomers? I can understand Manoj perfectly and would myself probably reduce my time spent on Debian even more if I were forced to do things more complicated (or even just different) because of some new policy. This is a first-class motivation killer for the people who are already there. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100330130233.ga19...@torres.zugschlus.de
Re: Question for all candidates: Care of Core infrastructure
Hi all, the question of the core infrastructures is difficult and very important. Le Mon, Mar 15, 2010 at 11:30:39AM +0100, Marc Haber a écrit : 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? Le Mon, Mar 15, 2010 at 12:52:44PM +0100, Frans Pop a écrit : Marc Haber wrote: In the last years I have seen a really disturbing development in Debian: New developers are very interested in bringing new packages into Debian, but care for our core infrastructure (dpkg, apt) has a little bit diminished. Good question and quite true. IMO it's worth adding to that: - Debian Installer development - Porting: several ports are struggling - Documentation maintenance: - website - Release Notes - various other guides Le Mon, Mar 15, 2010 at 01:36:28PM +0100, Alexander Reichle-Schmehl a écrit : ftp-team and more or less everything PR related. Le Mon, Mar 15, 2010 at 02:28:15PM +0100, Josselin Mouette a écrit : Core packages: glibc, kernel, X.org, Mozilla, KDE, GNOME… Le Tue, Mar 23, 2010 at 11:25:39PM +0100, Kurt Roeckx a écrit : 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. What are your ideas to make sure those teams keep running? I see this as a symptom of the ‘growth crisis’ that I mention in my platform. Debian is now big enough to attract contributors who – like me – have their field of interest largely at the periphery of the system. As an enthousiastic member of a ‘Debian Pure Blend’ project, I think that it is a good thing for Debian to have this peripheral work done internally, so let's see how to help to keep an equilibrated growth, which eases contribution of all DDs to the core infrastructures. I particularly like the quote attributed to Roland, “Home is where you have to wash the dishes.”, because there is need to know to how cook to help wash dishes after the meal. And it feels good to be home. Everybody can find his own way and vary involvement according to one's own plans, but I think that we really should encourage all DDs to devote some times to common tasks. There needs to keep a good balance to be stimulating and not stigmatizing, but I think that a DPL (or other DDs) could send a general announcement asking to the other DDs what they are doing for the project and encourage them to describe their role on a personal page (like wiki.debian.org's DD portfolios). One indirect instrument to help contributors to help the core teams is a milestone-based release process like the one that was implemented for Lenny. There were regular and clear messages in the form of achieved release goals and a progressive freeze, that I found very helpful to provide a time frame in which I balanced my favorite activities with contributions of general interest, increasing the quantity general tasks as the release was getting closer. There is also a nice effort of listing teams on our wiki. In parallel to this, I would like to list and describe the DPL delegations on our website. Many core teams are structured around a DPL delegation and this list could link to pages where the teams can describe what kind of help they need (in the most simple case, the wiki team's page). Sadly, there are also teams that refuse help. In my personal experience, I proposed to help process the NEW queue or with the answer to the SPI lawyers about copyrights, and never got an answer. I will make clear on the written delegations that proposals for help must not be left unanswered, and that refusals must be justified. In my platform, I also mention that there are too many restricted operations. Checking other developers work is a very time-consuming task, and being a bottleneck is a stressful situation that leads to burnout and arguments. We need an infrastructure that is more resilient on errors, and more open access and peer review. Of course, repeated ingorance of warnings is harmful to the Project, and in the most extreme cases, a developer who does not have a responsible behaviour could be asked to refrain using some parts of our infrastructure, or quit. There are many other ways to help the core teams, with some events like the recent GNOME day, for instance. I think that they are very refreshing as they break the routine and give an extra motivation to help others. The DPL can help to establish such events if they need to be supported by some spendings (but if it becomes regular events, it would be necessary to find a sponsor). I have not answered to an important aspect of the
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Marc Haber wrote: On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Manoj Srivastava wrote: What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. I am not sure that follows. How has my not using debhelper made it harder for newcomers? How many newcomers learn my build system? Or my git work-flow where I use submodules? There is a logical flaw in the assumption that not limiting the choices people have for packaging makes it a harder row to hoe for newbies. Is making things easy for newcomers or casual helpers really so important that we should risk scaring already active people away because they have to adapt their optimized workflow for newcomers? I can understand Manoj perfectly and would myself probably reduce my time spent on Debian even more if I were forced to do things more complicated (or even just different) because of some new policy. This is a first-class motivation killer for the people who are already there. I have a new job. It is sucking up more time from me, as I learn the ins and outs of how work gets done here. I also have a work-flow that is mostly automated, allowing me to concentrate on fixing bugs and integration issues. Any new complications added into the mix would be a major monkey wrench thrown into the cogs. I am not sure I would be able to give the packages the attention they deserve; I am already at the border line of what I consider adequate maintainership. So yes, busy work for a flawed and needless conformity would impact my contributions to Debian. I am not sure that the benefits of such conformity have been adequately demonstrated. manoj -- Humans are communications junkies. We just can't get enough. Alan Kay Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87y6h928qh@anzu.internal.golden-gryphon.com
Re: Questions for all candidates: decentralization of power
On Mon, Mar 29, 2010 at 04:42:22PM -0300, Margarita Manterola wrote: 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's probably fine. ftpmaster did not want Joerg to be promoted, and when he was, without approval of the team, Anthony Towns quit. I think that the common feeling is that this is an improvement. Joerg does more and better work than Anthony did. Was there a better way of handling the situation that would have been less traumatic for everyone involved? Possibly. Would it have been better to stick with the status quo for fear of attrition or bad feelings? I really don't think so. 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? Well, I am not running for DPL so I have not spent time planning changes that I will not be able to make. I imagine that I would not do very much on day one. The idea of formally re-delegating when the DPL role changes hands appeals to me a bit, but if I were going to only renew all existing delegations for the sake of setting precedent, I am unsure whether that is valuable. In general, I would try to move things in a few directions at once: more people on core teams, less power for core teams, more cooperative atmosphere, more empowerment for the lowly DD. If I thought that someone would be an asset on a core team, or if someone suggested to me that someone else would be an asset on a core team, I would likely explore that option. I would not try to make surprise delegations; the episode with debian-policy tells me that that would not work out well. Depending on the situation, I might ask the target team for feedback, but I would not ask their permission. I absolutely would not allow core teams to invite people, whether they had personal relationships with those people or not. In addition, I think I would probably delegate all DDs to be able to edit the website. It seems clear that I have not convinced anyone who did not already agree with me that making people ask for that access is a bad thing or even significant, but is. It is a bad thing, and it matters. Hopefully this would prove a point. -- 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/20100330152055.ga23...@scru.org
Re: Standardization, large scale changes, innovations
Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. And that in itself should be considered a bug. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Standardization, large scale changes, innovations
Josselin Mouette j...@debian.org writes: Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. I am an existence proof that the absoluteness of this statement is incorrect. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6h9k36j@windlord.stanford.edu
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Russ Allbery wrote: Josselin Mouette j...@debian.org writes: Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. I am an existence proof that the absoluteness of this statement is incorrect. I might agree that maintenance of my packages might raise a competence bar for the would-be-maintainer, and some people might fail to meet that bar. At this point I am uncertain that I am not happy at the prospect, as long as I am the maintainer and have signed up to clean up the mess. manoj -- Feeling amorous, she looked under the sheets and cried, Oh, no, it's Microsoft! Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874ojx1lec@anzu.internal.golden-gryphon.com
Re: Question to all Candidates: Who would you vote for?
Le Wed, Mar 24, 2010 at 09:09:43AM +0100, Alexander Reichle-Schmehl a écrit : Suppose that you would not run for DPL: Who would you vote and why? Hi Alexander, I would vote for Stefano, because the impressive determination he puts in his RC-bug of the day marathon suggest that he would do a lot of work as a DPL. In second, I would vote for Margarita, because I would be pleased to be proven wrong by her approach that favors inspirational over institutional actions. In third, I would vote for Wouter. Have a nice day, -- Charles -- 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/20100330235940.ga13...@kunpuu.plessy.org
