[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are there problematic infrastructure or processes in Debian?

On 2013-03-12 22:17, Raphael Hertzog wrote:
Debian's infrastructure and processes have grown organically over the
years, with all the strengths and weaknesses that it implies. Sometimes
it's a good idea to step back and look whether some of those need
to be amended/replaced/dropped/etc.
Based on your own experience, which infrastructure(s) or process(es) would
benefit from significant changes?
Are there infrastructures or processes that we're (still) lacking and that could make a significant difference in the work of Debian's contributors?


I should say first that our core infrastructure such as the Debian packaging and build system, and, for example, the feature set of the Bug Tracking System, are already extremely high-quality.

Of course, there are some extensions to our overall infrastructure that would be nice to have, in line with list discussions that you know about, but if elected DPL I would not currently see a strong reason to try to intervene in this area.

I agree that we shouldn't leave our infrastructure frozen, but continue to develop it, but I think that's already happening, with new tools like UDD appearing fairly frequently.

One aspect that is both a strength and weakness of our infrastructure is the lack of an integrating web UI. While I am happy that I can do my Debian work from the command line and through email, and without the need to be online, we have a rapidly increasing number of sources of information that aren't well integrated, and which makes it easy for new contributors to be unaware of useful services:
I am sure that Debian teams could provide a better web UI without requiring its use, but I know that it is not a priority for most of us. It might make sense for the relevant teams to recruit some new volunteers interested in working in this area.

Part of the reason for the lack of integration between our services is simply that we make it much easier to set up a new service than to extend an existing one. Despite the additional work needed on both sides (existing team and new contributor), it might be more sustainable if we made more effort to re-engineer proofs of concept into extensions of existing services when they are seen to be successful.


The main sections of my platform are effectively about improving our processes: "Delegations and teams", "Coordination/mediation", "Internal communications", "External communications", "Local communications", "Fundraising and spending", "Merging from the DebConf branch".

In the "Specific ideas" section of my platform I gave a few other examples that I would like to see:

- a better process to spot abandoned-but-not-yet-orphaned packages
- agreement on better/quicker processes for distribution-wide changes
- encouraging more teams to actively recruit and train new contributors
- a better process to match new volunteers to project needs.


Reply to: