On Thu, 2016-12-01 at 19:20:36 +0100, Stefano Zacchiroli wrote: > On Thu, Dec 01, 2016 at 03:46:05PM +0000, 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 their own merits and their own drawbacks. Stating otherwise seems like an overly simplistic and naive view of how projects of this size and how human interaction works, TBH. If people want to go for any of them, they should! For maintainerless we already have QA maintained packages, if that's not good enough just create a new address or whatever and put it in the Maintainer field. But the continuous messages that get through on the mailing lists that seem to keep demonizing contributors that do not participate in team-maintainer efforts are a bit tiresome and disrespectful. Because, didn't we have a vote on diversity or something…? Regards, Guillem
