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 question: how to recruit core members of the core team? First of all, development decisions should be open. I think that the principle of do-ocracy is that we will not nitpick or micromanage the way an infrastructure is managed when there is agreement on the general direction. But spending time and effort without concertation is a waste, and we can not compensate the developer by accepting unwanted developments. The way the membership process reform has been rejected or the dpkg source v 3.0 format is being negociated in pain and flames are an example of this. One way to better coordinate with the Project, and in return increase opportunities to recruit more volunteers is to standardise on interfaces in documents external to the teams, not on the team's implementations, because this reduces the sense of ownership from the current persons in charge. To change an interface that is described elsewhere one has to coordinate with others, and sometimes negociate and make concessions. In that sense, I think that we are too shy to have our Policy lagging behind our core tools, rather than being the place where major changes are discussed in the first place. 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/20100330132038.gg8...@kunpuu.plessy.org
