Re: [all candidates] on distribution-wide changes and scalability
On 14/03/13 at 17:55 +0100, Stefano Zacchiroli wrote:
> 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?
There is some inertia. Some of it is unavoidable due to the complexity
of what we do, some of it could be optimized away.
> - if you don't think that we're at our best on this front, what do you
> propose we change to improve?
(see below)
> ------------------------------------------------------------------------
>
> 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. ]
I don't think that the TC should be be a place where changes are
*designed*. However, it could be used on rare occasions as a way to
decide on changes more effectively. But generally, I don't think we
have a problem with design.
> - 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.
We already have a single VCS: the Debian archive. Standardizing on Git
and on a Git workflow[1] would bring some benefits (easier to move
between teams, less documentation for each team), but I don't think that
the VCS in use is really that important. Standardizing on packaging
tools sounds a lot more useful.
[1] I started some work in that direction as mentioned in my platform,
see http://wiki.debian.org/GitPackagingWorkflow
However, about Git, I wonder if the "one repository per package"
practice is really a good idea. Of course, we have 'mr' to manage several
repositories, but it would be much more convenient if we had all
packages in the same repository (or at least all packages of a team). I
think that one of the big source of (useless) inertia, at least in teams
dealing with lots of small packages, is the fact that each package is
generally considered a separate project.
Regarding transitions, I generated a custom graph based on those on
http://www.lucas-nussbaum.net/blog/?p=751 to compare the "transition
speed" of 3.0 (quilt), dh, and git: http://blop.info/pub/adoption.png
I have the impression that the faster transitions are also the easier
transitions.
> [ 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. ]
On the other hand, Debian is about addressing diversity between other
free software projects. It's not too surprising that we have problems
suppressing some of that diversity.
> - 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. ]
I'm not sure if you are trying to troll here, but we already welcome some
archive-wide changes (l10n, porting, etc.).
> 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)
The Debian way, I would say. Incrementally. Using graphs to track
progress. When the to-be standard starts to become a de-facto standard,
add a lintian warning, then reprecate alternatives, then add as a
release goal, etc.
Lucas
Reply to: