On Tue, Mar 13, 2012 at 09:51:08AM +0000, Anthony Towns wrote:
> I wonder if anyone can name three "big" controversies over the past few
> years that have gotten resolved within Debian?
To the examples provided by Russ, I'd like to add time-based freezes,
which we are doing for Wheezy. I think it fits your "not winner vs
loser" category, although it has been a quite sensitive controversy.
> The biggest controversies in free software that I've seen just aren't
> happening within Debian from what I've seen: Unity vs Gnome3 is an
> Ubuntu/Gnome thing; upstart vs systemd is an Ubuntu/Fedora thing; funding
> open source development is a Red Hat/Google/Intel/IBM/HP/Oracle/buxy
> thing...
Right, but all this are mostly upstream controversies. Some of them are
reified at the distribution level (e.g. Unity vs GNOME 3), but it is so
because Canonical is playing both in the upstream and distribution camp,
with a high level of interdependencies among the two. As of now, Debian
is not. We do have Debian Developers who are upstreams for popular
pieces of software, but they clearly distinguish their roles as upstream
and as packagers.
All this is not to say that we are necessarily good at resolving
technical conflicts. We are fairly good at doing so only when they are
clearly denotated as technical conflicts, via consensus or the Technical
Committee. But we are not particularly good at picking distribution wide
defaults (what is the default init system? what is the default desktop
experience? etc). This is, I believe, by construction of our decisions
mechanisms which are made to solve conflicts and not imposing a
technical lead to the project.
According to the constitution we can ask the Technical Committee to make
such decisions. But we don't have the habit of doing so and I don't
think the committee would scale if we would start doing so. The Release
Team play in a similar playground for picking some defaults, but we
similarly have the habit of not asking them to do it "too much" either.
If you look at other projects, younger than Debian, who have probably
chosen to do differently in the above matters "learning" from us, you'll
notice that they have some sort of Technical Board. Those boards have
periodical meetings and make pro-active, project-wide technical
decisions on behalf of their projects.
*If* we want to tackle the "default picking" and similar choices
properly, technical board is likely the way to go. But that would be a
fundamental change in how we do things and it will have some negative
effects. Whether we want to go there or not is something I've been
asking myself since quite a while, without a clearly winning answer (yet
:-)).
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature