On Thu, 2016-12-01 at 19:20:36 +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
>
> This is the obviously right solution.
It is not only not obviously right to me, instead it seems obvious
it carries a set of different problems with it. I feel this carries
so many assumptions of how the proposers feel about how *they* work
or might like to work and ignores how *others* do that. :/
If Debian was operated by a hive-mind, this would be the obvious
solution. But Debian is not (and it should not become a hive-mind IMO),
instead its distributed, independent and diverse nature is one of its
greatest strengths. In addition Debian is in great part a volunteer
based project. The dynamics on a volunteer vs a paid environment can
be entirely different (they are for me, there are things I'm willing
to do or scenarios I'm willing to accept/tolerate on paid-basis, I'd
never do on a volunteer one).
Few problems that come to mind on a fully maintainerless project:
* Encourages one-off upload-and-forget for dependencies of stuff one
might want to package.
* More difficult to track (in and outside of Debian) if there is
supposedly someone taking care of those package (would require
accessing subscribers from the PTS or tracker or similar?). Is
someone supposedly taking care of orphaned packages? Well perhaps,
no one know until there's an upload. Is someone maintaining a
maintained packages, in the normal case, yes.
* No one will have a "vision" of where each of those packages is or
should go? Will this vision need to be agreed by the whole project?
For each package!?
* Assumes stable and interpersonal relationships with upstreams are
perhaps not important? Everytime someone different might contact
upstream with a different style, etc?
* Assumes that everyone enjoys working with the same tools, with the
same workflows: what about cdbs vs dh vs dehelper, git vs the rest,
VCS layouts (debian-only, full-upstream, pristine-tar), source format
1.0 vs 3.0, etc, etc. (f.ex. there are several VCSs, source layouts,
helpers, etc. I'm so uncomfortable working with, to the point I just
don't feel like co-maintaining packages using those, or join teams
that have those as their team policy).
* Assumes everyone is pulling Debian in the same direction, and that
there are never potentially opposite goals (at least initially).
* Assumes everyone can work with everyone else on a close and personal
level (f.ex. I'll accept technical contributions from anyone based
on the merits of those contributions, but there are people I'd rather
not have to work with closely).
* Assumes an extrovert worldview. Sole-maintainership is not necessarily
about control, authority and power (inbalanace!?) it can also be a
sanctuary of tranquility, having to coordinate with a team or the whole
project can imply an additional overhead and energy toll for introverts,
in addition to the required coordination and interactions we are
supposed to carry on as normal duty towards others and the project.
Or it can be a space of freedom where one can do (within the
distro-wide technical and socual rules and policies) anything one
can imagine.
* Assumes everyone has the same personal packaging policies and
commitment of effort. For example whether to strive for 0-divergence
against upstream, or whether to patch upstream with no remorse
whenever it seems needed. (I'm on the latter camp, but I'd never
impose that vision on people on the first camp, because that would
imply I'm deciding on a work committment for them).
* Assumes everyone perceives and feels their time and effort involvement
on tasks in the same way. While the motivations and rewards are so
subtle and diverse, probably as the number of people we have involved.
* With less and less people checking central development communication
channels, many global distribution-wide changes have no way to be
considered by the majority of affected people. While being able to
do distro-wide changes, in say, a mass upload, might be very
convenient, having independent maintainers that *know* the details
of the packages they maintain means there are more sanity checks in
place, and that you need to convince people your ideas are correct.
* Could discourage experimentation, using new tools, helpers, techniques,
workflows, because it might interfere with others wanting to work
also on those packages (it would go against the hive-mind!).
I've worked on teams or group efforts that are great, with great peers
that I resonate with on an interpersonal level, where I might or might
not agree on the technical level, but technical discussions are still
very much enjoyable. I've also worked on teams that were such an
energy drain that they were very unpleasant to work in.
I think all of sole-maintainership, team maintainership, and even
maintainerless packages have
