[all candidates] on distribution-wide changes and scalability

Folklore goes that performing distribution-wide changes in Debian is
hard and time-consuming, due to a couple of reasons: (1) the time needed
to make a decision that affects the whole archive (this is related to
our flat structure, which has many benefits, but surely not that of
providing a clear decision structure for cross-cutting concerns), and
(2) the time needed to deploy the needed technical changes in all
affected packages.

This "inertia" folklore is surely supported by past history of the time
it took us to deploy specific changes in large sets of packages.  But on
the other hand, in the last 5 to 10 years we have massively improved our
ability to decide and deploy large changes by the means of: (a) large
maintenance teams who are able to decide on "their" packages and deploy
changes using shared-access VCS, and (b) a more liberal use of NMUs than
in the past.

Questions for the candidates:

- on the judgement spectrum between "there is no inertia in Debian and
  that's good" and "there is a lot of inertia in Debian and that's bad",
  where would you put yourself?

- if you don't think that we're at our best on this front, what do you
  propose we change to improve?

------------------------------------------------------------------------

As mere thought experiments, feel free to consider the following
possible "changes" as part of your answers:

- Debian should use the Technical Committee more proactively than we
  presently do, to decide on "any technical matter where Developers'
  jurisdictions overlap"; not only to solve conflicts (as we already
  do), but also to *design* forthcoming changes in an authoritative
  manner.  [ Many large FOSS projects out there have technical boards
  that work that way. ]

- Debian should decide to use a single VCS (say, Git), for all packages,
  uniform repository structure and work-flow, and give by default
  read/write access to all DDs. This would allow push-button changes to
  all packages in the archive.  We often speak about "reducing package
  ownership" during DPL campaigns, well, this is the ultimate step of
  it.  [ Ditto: I know no other large FOSS project out there allowing
  the extreme diversity in VCS, work-flow, and ACLs that we have in
  Debian at present. ]

- Debian should seek more direct involvement from companies whose
  businesses depend on Debian, so that their employees can help
  volunteers in pushing archive-wide changes (once they're decided).
  [ If you allow gatekeepers this would become, essentially, the Linux
  kernel development model. ]

Bonus point: if you think any of the above is good, how do you think we
can decide to go for it? (chicken and egg FTW)

Zack, provoker of the day, again,
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »