== gobby link == gobby.debian.org:minidebconf-hamburg/2023/collective-maintenance == Introduction == Over the years, there has been lots of friction in the Debian project when trying to effect system-wide changes affecting core components of the operating system. We believe that a lot of this tension, that has accumulated over the years, has some of its roots in the separate strong maintenance of the packages constituting the core Debian system (what "core" means is TBD). Many community Free Software projects have some form of developer body, elected or otherwise, which steers the direction of the project and gets buy-in from the community of maintainers of the base system; For instance: - Fedora has an[Engineering Steering Committee (FESCo)](https://docs.fedoraproject.org/en-US/fesco/), - Ubuntu has a [Foundations team](https://wiki.ubuntu.com/FoundationsTeam), - the Python project has a [Steering council](https://peps.python.org/pep-0013/) - PHP uses a process based on RFCs and voting with 20-50 voters (https://lwn.net/Articles/821821/), etc. We would like to explore the ways Debian could draw from these ideas and move towards more collaborative direction-setting and maintenance for its base system components. The aim of this session is to get more points of view on the topic, and maybe gather some more volunteers to prepare a project-wide discussion to be started once the bookworm release is out of the door. == Timeline == - After June 10: bring this discussion forward to debian-devel (or vote?) == Questions and Answers during BoF == Feel free to add some questions here, and document questions asked during BoF. - policy is maintained by a delegated team. The technical committee also has some responsibility that may overlap. How do we resolve this conflict? Should their power be moved to a new team? Policy is often about documenting current practice. This new team is about defining changes in current practice. - how do these teams make decisions, and get acceptance from the rest of their volunteer maintainer community * other project only give vision and direction * CTTE is a reactive body. Managing difficult decision via the CTTE makes Debian slow to adopt change. - Should we reinstate the release goals (somehow)? Having a dedicated body can reduce the perception that individuals having an agenda decide The CTTE is a self-electing body. Changing that may be good. The role of technical leadership is missing (the CTE has a different role). The question of "who does the work" to implement the technical direction that would be set by this newly formed body stays open. One proposal is to actually empower the team to implement the decision. It is a very large change in culture in the project. What are some concrete examples of changes that would fall within this discussion? - implementation of LTO? - proactive hardening changes? - ...? - switching default init systems (and implementing support for the features of such) Counter example: the reproducible builds project has just created > 3000 patches where > 2700 were just applied (and the rest will be NMU-ed). Ending up as the sole maintainer of a "core" component of the OS is certainly not a great position to be in, and it makes sense that people in this position take more conservative approaches. How do we move to a situation where this does not happen anymore? Switch strong ownership by default to opt-in? Strong maintainership can only work if you do care about the package. What happens when a maintainer doesn't care anymore, patches can linger and others get demotivated. reminder that the salsa.debian.org/debian/ namespace is dedicated to collaborative maintenance: anyone should be able to commit to, & eventually co-maintain packages there ITS more! and embrace more the collaborative maintainance -- debian group on salsa -- everyone can work on those packages, but sometimes this is not widely known. Projects like the janitor, and doing more mass-changes in an automatic way, allows people to focus on the more important stuff. Strong maintainership can also be a problem even when the maintainer is active and cares about their package, but who has so much to do that the problem becomes lack of alignment with the rest of the project. In general strong maintainership is problematic for debian native packages. Maintainers as facilitators rather than gatekeepers? Undocumented knowledge about the package and it's relation to the rest of the ecosystem might lead to problems if "random" people try to take care. Why only core, and not for everything? If a group has power to override maintainers, it should probably be elected. The current way people effect large-scale changes in the project is: - start by implementing it as a very optional add-on - increase the "mandatoriness" of the add-on gradually - ??? - It makes us very slow to adopt changes. Which is painful to some, but a feature to others ("Debian releases too often"). Basically we are trying to unlock issues when work affects many packages, we already have the DEP process to try to come to a consensus. What we lack is a way to go forward when we can't reach a consensus, we should have the possibility to have a body to validate such a DEP anyway. Or pick one choice between a few competing DEP. That also solves the who does the work, those pushing forward the DEP are likely willing to implement the work too. What happens if we take DEPs and do GRs on them? That'd be a bit annoying. How about building a smaller team that votes on DEPs, but then have the proposers of the DEP empowered to implement the decision. Why not make GRs more often? Doing something painful more often may make it less so.