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 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
Reply to: