Stefano Zacchiroli <z...@debian.org> writes:
> 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.
It is, indeed hard and time consuming. I do not neccessarily see that as
a problem, but see below.
> 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?
On both sides, of course, and sometimes somewhere inbetween. We've seen
cases where we had inertia, and turned out it was useful. We've seen
others where it turned out to be a bad thing. So it really depends on
the context.
> - if you don't think that we're at our best on this front, what do you
> propose we change to improve?
(See below, but keep the above statement in mind.)
> 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. ]
Involving the tech-ctte earlier may be a good idea, but pushing the task
of designing forthcoming changes onto them, even if done in cooperation
with the other parties involved, is not something I'd push for. I see
the tech-ctte more as a decision making body, or a technical mediator,
than an entity that designs change.
Getting the tech-ctte involved more often, not only as a last resort can
have benefits, but then we need to make clear that we expect help, and
not neccessarily a solid decision.
(FWIW, Constitution 6.1.5 already grants the tech-ctte to offer advice,
we should exploit this power more often, and more pro-actively.)
> - 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. ]
No. Most definitely no. There is *no* structure, nor workflow that fits
all packages and all packagers, trying to force one down our throat
would be counter productive. While this would certainly have advantages,
I find the costs too high:
- Adapting to a single repository structure can be needlessly painful
(esp. when you need to adapt the upstream structure too)
- Settling on a single VCS is not going to happen, ever.
- Sometimes it is more convenient / straightforward to use the same
VCS upstream uses (which may or may not be git).
(Especially when one is upstream)
- Sometimes one is maintaining the same package for not only Debian,
but derived distributions aswell, which use or prefer another
VCS. Trying to force the hand of our downstreams this way is not
productive, in my opinion.
- There is no workflow that fits all scenarios. Trying to shoehorn
everything into a simplified view is just going to hurt in the long
run.
- People are people, they're hard to change, and in a purely volunteer
based project, that has a long history of giving pretty much free
hand to the maintainers as long as they comply with policy and some
amount of common sense, moving towards a more controlled environment
by force is bound to cause quite an uproar.
(I've worked with BSD ports/pkgsrc for quite a while, where there is a
single VCS, a uniform repository structure, and pretty much one
canonical workflow. It was horrible. So very inflexible, it was a pain
to adapt things that weren't designed with that particular layout &
workflow in mind.)
I'm all for encouraging putting packages under collab-maint or team
maintainance, but encouraging it is where it has to stop, reducing
package ownership or not. Not at this time yet, anyway.
Less variation certainly helps, but there will always be some, I see no
way around that. We should encourage using common tools, workflows and
repository structures, and we should document all these properly in
debian/README.source files. Then, in a few years time, we can revisit
whether it makes more sense to push for a more centralised model
(likely, it will not make sense then, either).
One of the beauties of Debian is its diversity. Sadly, this is also one
of its problems. We'll just have to learn to live with it, and try to
converge towards a common goal, even if we never reach it.
> - 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. ]
This, on the other hand, is an idea I find worth pursuing. I wouldn't
restrict it to companies that depend on Debian, though. Any company or
businesses that benefit from Debian one way or the other, and employ
people who can push the changes forward, would be welcome to support
these people in their task.
It'd be great to show these companies that allowing their employees to
work on Debian stuff from time to time does have benefits. That largely
depends on the company too, of course. Some directly benefit from it,
some would value the PR value, others don't care about Debian at all,
but want to keep their valued employees happy. There's many ways a
company can benefit from not only letting their people work on Debian
projects, but actively supporting them in doing so.
I believe encouraging these would benefit Debian greatly, without
sacrificing our independence.
> 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)
Does "Just do it!" count? :)
In all seriousness, though, the first decision would be the easiest,
because they (the tech-ctte) are already entitled to offer advice. We
merely need to exploit this more often.
The last one, seeking direct involvement from companies, that's a
tougher cookie to crack. I would first seek input from the wider
project, possibly have a little flame war to vent any heavy
disagreements, then review the results, and proceed from there. If
there's no good reasons against it, then it'd be time to draft a plan,
and start approaching companies. (Heavily involving DDs working there,
of course.) In this case, I do not see any chiken and egg problem.
--
|8]
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nfy81lz....@galadriel.madhouse-project.org
