Multi-package projects
Hi, Debian does not have a good way to manage projects that require changes to large numbers of source packages to be successful. Handling projects like that currently requires buy-in from each individual package maintainer; if the project does not manage to convince sufficient numbers of maintainers, it is liable to fail. This problem is bad enough when it is a noncontroversial project, but gets worse when the project is controversial; some people will oppose the project on principle because they believe it will not improve Debian, which will result in effectively a mess of half-baked solutions that can't really be used. I've given this some thought over the past few days, and have come up with something that I believe might work, and I would like to submit it as a proposal to see what others think. I want to clarify that it was not created with a specific multi-package project in mind, although I will give some examples. Additionally, the proposal foresees a pretty big role for the release team. I haven't discussed this with them (or anyone else, for that matter), and so it might be that a new team will have to be created if the release team thinks this won't be for them; but I do think they would be the best fit (they would have to coordinate with this proposed new team at any rate, anyway), so I'll not muddle the waters by using wording like "the release team, or any other team that would take up this role". Just imagine I did though ;-) On to it: - Any team of persons who would like to propose a project that requires changes to multiple packages will make, at the beginning of the release cycle, a proposal to the release team that outlines the proposed goals and scope of the project. (e.g., "SE Linux configuration for all daemons in the archive") - The release team will make sure that interested parties are made aware of the proposed new projects, so that they can object/chime in/join/whatever. (e.g., send a d-d-a mail) - After the merits and problems of the proposed new projects are discussed, the release team decides which projects are accepted for the next release. (I specifically do not mention what rules the release team should follow in deciding which projects to accept -- I trust their judgement) - Accepted projects get the following: - A mailing list and a pseudo-package in the BTS to coordinate efforts - Relaxed NMU rules (People working on the project should *not* NMU at will; they are still expected to work with maintainers, who may request things like changes to proposed patches, short delays so that it won't conflict with other work the maintainer is doing on the package, and/or additional work, such as autopkgtests. However, in the absense of reasonable package maintainer objections, NMUs should be done at low threshold) - At the beginning of the release cycle, the release team will also set a date at which point the currently-active multi-package projects are evaluated. This date is expected to be near the end of the release cycle. - During the release cycle, the team driving the project is expected to submit patches to source packages where and as necessary, and to follow up on bug reports that are assigned to their pseudo-package. - During the release cycle, people *not* driving the project are expected to apply patches speedily, in the spirit of collaboration. They are *not* expected to work on the project (although they are of course welcome to if they want to); any bugs that are filed that are related to the changes made by the multi-package project may be promptly reassigned to the project's pseudo-package and/or set to a non-RC severity. The team driving the project may *not* reassign the bug back to the package without either a patch that fixes the bug, or an explanation of why the bug is a bug in the code that is not related to the multi-package project (with the onus of proof here lying on the project). - During the release cycle, the release team is may do things like keep an eye on the progress of the various projects and guide the teams driving them as to things they consider critical when the - When the date that was decided upon by the release team has arrived, multi-package projects will be evaluated, and each will be placed in one of the following four categories: - Succeeded: the project is complete, no further work is required for it. The pseudo-package will be closed, any bugs still assigned to it will be reassigned back to the relevant source package, and the maintainers of these packages will from now on be responsible for maintaining the required changes (this might be appropriate for a project that desires a change in how we do things, but that has no further work once the change has been done, such as, e.g., the usrmerge project could have been) - Failed: the project failed to reach its goals, and it is unlikely that it will ever d
Re: Multi-package projects
On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote: > - After the merits and problems of the proposed new projects are > discussed, the release team decides which projects are accepted for > the next release. > (I specifically do not mention what rules the release team should > follow in deciding which projects to accept -- I trust their > judgement) This sounds like you propose to create some sort of technical steering committee which probably should not be required to be identical with the release team. But as a practical example: some people have suggested packages not shipping configuration files in /etc (including, for example, init scripts in /etc/init.d). As far as I understand some people even say it is Debian's core mission to support such new configurations to give more freedom to users. How would this work and reduce conflicts with your proposal? Would it be okay for people driving this change to, for example, just drop /etc/init.d scripts? People caring about them could make software look for them in /usr/lib/init.d or such reducing various problems with removed-but-not-purged packages. Or would the people interested in shipping less configuration files have to implement this for non- standard init systems whose usage is explored as an experiment in Debian? Some people probably also want to continue to ship configuration files as Debian does now. Should we require this to be user-configurable? Who would be required to maintain maintainer scripts to support both configurations? The group wanting to keep the old configuration or the group wanting to support the new configuration? What if some people don't want this user-configurable (hmm, make user-configurability user- configurable?)? Or should be release team just decide all of this and everyone will accept this? I don't think that would work from past experience... Ansgar
Re: Multi-package projects
Hi Wouter, * Wouter Verhelst [2022-10-07 13:37]: I've given this some thought over the past few days, and have come up with something that I believe might work, and I would like to submit it as a proposal to see what others think. Great idea, thank you for your thoughts! It reminds me of the Debian Enhancement Proposals [1], which aim to solve a similar problem. I have only one remark at this point: By definition, a project has a limited scope and time frame, so at some point it has to end. For things like /usr-merge, or any other transition, this is a good fit. Adding features to Debian which require permanent additional maintenance is more akin to supporting a release architecture. The associated project would be the "incubation phase" where said feature gets introduced and its viability proven, and one success criterion would have to be the formation of a team that commits to the required maintenance work for the future. Similar to the release architectures, features should be evaluated at release time and discontinued if the team can no longer provide the required support. Cheers Timo [1] https://dep-team.pages.debian.net/ -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Multi-package projects
On Fri, 2022-10-07 at 14:21 +0200, Timo Röhling wrote: > * Wouter Verhelst [2022-10-07 13:37]: > > I've given this some thought over the past few days, and have come > > up > > with something that I believe might work, and I would like to > > submit it > > as a proposal to see what others think. > Great idea, thank you for your thoughts! > It reminds me of the Debian Enhancement Proposals [1], which aim to > solve a similar problem. > > I have only one remark at this point: By definition, a project has a > limited scope and time frame, so at some point it has to end. For > things like /usr-merge, or any other transition, this is a good fit. I think we did try something similar for usrmerge already: the tech- ctte was asked about the switch to the new filesystem for new installations, making the new layout the only supported layout in the future and migration of existing systems. The proposal adds a few more bits reminding me of old concept of release goals (which Debian dropped), but I'm not seeing how it would avoid the problems we had (or have) with systemd or usrmerge. It hides a lot of conflict behind this simple statement: | - After the merits and problems of the proposed new projects are | discussed, the release team decides which projects are accepted for | the next release. | (I specifically do not mention what rules the release team should | follow in deciding which projects to accept -- I trust their | judgement) and assuming everyone will then accept this decision. Ansgar
Evolving away from source package realms
(This is the continuation of an unspecified thread in the debian-private list that generated enough positive content that I deemed it smart enough to jump off from it, to a public mailing list. I'm not quoting anything from anyone, but there's certainly inspiration from various participants, so thanks for that!) So. We should be having a public discussion about our per-source ownership, _and_ about spread responsibilities. A long-established specificity of Debian development is that we have had only one, super-powerful, authorization scheme to the archive: become an uploading DD and get unrestricted, unsupervised upload right upon all packages. We solved the social friction using processes, documentation, etc. (Yes, DM status opened restricted upload rights to limited package sets). There are two sides to that. As all uploading DDs _can_ upload, we get (theoretical) built-in failover: when one goes emeritus (the ideal case), they can be replaced by any other without much process. We also get low-cost emergency fixups; if I upload something broken just before going (explicitly) VAC, anyone can revert and upload. Not having explicit barriers in place is (was?) a nice way to reduce administrativia, and to address ownership disputes in the open; the only restrictions on NMUs, orphaning and package salvaging, etc, are social, not technical. And by the nature of being social, we address them with processes, documentation, policy (and committees enforcing some of the rules). In other words, no technical barriers prevent me from uploading a broken src:base-files; but I will face social backlash (and possibly administrative measures), because I would have broken agreed-upon social norms. The flip-side of this is also that we all _care_; as I _can_ upload src:base- files, I feel partly responsible for it. I argue that uploading DDs care about all of Debian packages, not only because they care about Debian, but also because they have the needed authorization (power) to fix any and all of them. What matters is not that the power is exercised, but that it exists. The set "all Debian source packages" is a concern for all of us; we're one large team for one _very_ large set. Attempts to split this set has worked by interest- groups so far; language-specific, desktop-environment-specific, etc. (And it has worked quite well for these groups, also because the subsets they care about are reasonably self-contained). But as we all care, we are also all entitled to opinions (that might be conflicting) about OS-level design decisions which (as was amply demonstrated by this mega-thread) cannot reasonably be addressed by source-level ownership. Deciding that /lib is going to be a symlink cannot (and, for the avoidance of doubt, has not) be a single source package maintainer(s)' decision. But as things currently work, it ends up being implemented and steered as such, with our source-package-level conflict-handling processes (TC, etc, etc). So, we have eachothers' backs, and we all care, how to move from there? Looking at how Ubuntu is structured (with topic teams) made me wonder if some variation of that couldn't reasonably be applied to Debian, by dividing our giant set in subsets (topic teams, baskets, ...), under clearer team's responsibilities, and onboarding processes. That would imply that certain people would have more power: the "PostgreSQL server" subset team would have authority and (technical) upload rights upon their packages. And others would have less power: not being able to upload these anymore. The flip-side of such a setup, in which a large set of uploading-DDs would see their power over the "PostgresSQL server" set largely reduced, is that they would also "care less" (why investigating an RC bug if I can't NMU anyway). FWIW, I'd happily limit my uploading rights to forbid me to upload a Gnome package, a kernel package, or a PostgreSQL package, provided that there would be documented onboarding processes, should that ever interest me. But I argue that we're already _socially_ in such an environment: all contributors (including uploading DDs) not already in any given team go through onboarding processes, Salsa MRs' reviews, vetting and review before they do upload directly (modulo NMUs, of course). It's just not enforced by the archive. The last aspect would also be to completely remove the source-package-level realms; within a subset, there would be no package-specific maintainers or vetoes; disputes would move "out" from source-package-level to subset-level. That's not to say that within-subset disputes wouldn't happen nor could be escalated; it's rather to stipulate that the realms' boundaries wouldn't be the source-packages', but the subset's. In the current situation in which there's quite some friction around "merged- usr/" (and in the lingering situation around init systems), I'd see a "Debian core" subset made of base-file
Re: Multi-package projects
> - After the merits and problems of the proposed new projects are > discussed, the release team decides which projects are accepted for > the next release. > (I specifically do not mention what rules the release team should > follow in deciding which projects to accept -- I trust their > judgement) I like the idea in principle - just one comment here, isn't this role pretty much tailored for the CTTE? It already has standing to make project-wide decisions by existing rules, and in fact routinely does so. This is pretty much how the Fedora equivalent, the Steering Committee, operates, and it seems to work well over there. Any reason you preferred the Release Team in the proposal? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Multi-package projects
> "Luca" == Luca Boccassi writes: >> - After the merits and problems of the proposed new projects are >> discussed, the release team decides which projects are accepted >> for the next release. (I specifically do not mention what rules >> the release team should follow in deciding which projects to >> accept -- I trust their judgement) Luca> I like the idea in principle - just one comment here, isn't Luca> this role pretty much tailored for the CTTE? It already has Luca> standing to make project-wide decisions by existing rules, and Luca> in fact routinely does so. This is pretty much how the Fedora Luca> equivalent, the Steering Committee, operates, and it seems to Luca> work well over there. Any reason you preferred the Release Luca> Team in the proposal? I actually think that the skills and outlook you need for an appeals body of last resort are different than you need for the coordination of which of an overlapping set of projects to coordinate into a release. I don't know that the body making this decision should be the RT; I worked on a proposal like this that I circulated privately to a few people while I was DPL. There I was imagining something RT-like, probably with overlap in composition with the RT, but possibly not the same as the RT. Here are things I think the RT style composition has going for it. * The RT is used to trying to find ways to say yes, but is also used to managing stability and trying to minimize the number of parts moving at once so that releases can happen. * The RT needs to have buy-in; ultimately they are responsible for which changes are acceptable. For example in usrmerge, ultimately it was the RT that was able to say that we aren't going to actually move files around until dpkg gets fixed. Yes, their decision was consistent with the TC's decision, but the RT is used to, and good at saying "this is ready but that next step over there isn't yet." * the RT members are involved at a very detailed technical level in stuff. At an architecture review level, it's very easy to get stuck in the theoretical. When the RT is sitting there looking at the actual patches and going "wait! You want 60k lin.lines of changes in this close to the release," they see it is complex in a way that an architectural overview might hide. * The RT gets involved when things break. They have a very good exposure to what kinds of changes introduce real complexity than comes back to bite us and what kinds of changes are safe. * The RT is good at keeping processes focused on goals that we have wide agreement on. There is subjectivity, but with very few exceptions the RT isn't going to come back and tell me I shouldn't be able to do a transition; they are going to focus on working with me to make sure I'm ready for it and haven't missed details. In a proposal like this, whoever is deciding which projects should go in cannot be making the decision based on technical merits; they would need to be deciding whether adequate consensus has been reached, whether there are people lined up to do the work, whether all the stakeholders have had a say, that sort of thing. That looks a lot more like an architecture qualification than a TC decision. However, some of that is a bit beyond the work the RT appears to usually do, and certainly throwing that onto the existing work for the RT without adding a bunch of volunteers sounds challenging. And then there are the social factors. * the RT has a history of being able to say no in a way that we can accept. Oh, yes, there are some people who have gotten really upset (and I can think of one case where someone effectively minimized their Debian involvement) over RT decisions. But the RT has a really good track record of being able to say no without generating a project-wide storm. They have a lot of social capital. * I think that's in part because we all have positive interactions with the RT where we can see how they have helped us find a detail we missed in a transition, or asked an important question as we were proposing a stable update. Perhaps not all of us, but many of us have seen the RT actively working with us to move stuff we care about forward. Oh, I'm sure there's also frustration about how the RT doesn't move faster and the like. * And at the end of the day, the RT makes releases, and we all get to benefit from them. In contrast, the TC: * Is technically focused. The TC has a history of doing its own technical evaluations rather than working with consensus processes elsewhere. Sometimes that's exactly what we need, but I don't think that we would want that for early coordination of which shared projects we're working on. Also, the way that consensus stuff on debian-devel intermingled with TC bugs for usrmerge was a major step forward on this. * The TC is a body of last resort. That'
Re: Multi-package projects
On Fri, Oct 07, 2022 at 05:54:40PM +0100, Luca Boccassi wrote:
> > - After the merits and problems of the proposed new projects are
> > discussed, the release team decides which projects are accepted for
> > the next release.
> > (I specifically do not mention what rules the release team should
> > follow in deciding which projects to accept -- I trust their
> > judgement)
>
> I like the idea in principle - just one comment here, isn't this role
> pretty much tailored for the CTTE?
Perhaps, yes.
> It already has standing to make
> project-wide decisions by existing rules, and in fact routinely does
> so. This is pretty much how the Fedora equivalent, the Steering
> Committee, operates, and it seems to work well over there.
> Any reason you preferred the Release Team in the proposal?
A general principle that I think it's generally better to have the
people who are involved in implementing a decision also be the people
who made the decision in the first place; and it would be the release
team who gets to say (in the end) whether a goal has been reached or
not. I expect the TC to be involved when there are things that are more
complicated (either because the release team is unwilling to take a
decision and asks the TC to step in, or because they did take a decision
but someone believes they took the wrong one, as an escalation process).
But maybe that was wrong, and we should let the TC decide on which
projects are accepted. This part of the proposal isn't very fleshed out
(mostly because I don't have enough insight on how the release team
works), and while it is crucial that it works well for the whole
proposal to work, the specifics of *how* it works are not that crucial.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Multi-package projects
On Fri, Oct 07, 2022 at 02:21:04PM +0200, Timo Röhling wrote:
> Hi Wouter,
>
> * Wouter Verhelst [2022-10-07 13:37]:
> > I've given this some thought over the past few days, and have come up
> > with something that I believe might work, and I would like to submit it
> > as a proposal to see what others think.
> Great idea, thank you for your thoughts!
> It reminds me of the Debian Enhancement Proposals [1], which aim to
> solve a similar problem.
I'm not sure I agree with that assessment. I believe DEPs are mostly for
discussing changes that can then be voluntarily implemented by
individual package maintainers; whereas this is intended to allow those
who want the change to actually do the work for that change more easily,
which DEPs don't do. Perhaps I'm missing something?
> I have only one remark at this point: By definition, a project has a
> limited scope and time frame, so at some point it has to end. For
> things like /usr-merge, or any other transition, this is a good fit.
That's debatable, as the phrase "the Debian project" shows, but sure, I
guess we can rename things after the first release cycle if we think
it matters.
> Adding features to Debian which require permanent additional
> maintenance is more akin to supporting a release architecture. The
> associated project would be the "incubation phase" where said
> feature gets introduced and its viability proven, and one success
> criterion would have to be the formation of a team that commits to
> the required maintenance work for the future. Similar to the release
> architectures, features should be evaluated at release time and
> discontinued if the team can no longer provide the required support.
You may have missed it, but my proposal already contained a similar
suggestion:
> > - Maintained: the project reached it goals, and will be active in the
> >next release. Outstanding patches (if any) should be fixed and/or
> >applied ASAP; failure to apply such patches will become RC for the
> >relevant source package. However, the project is not finished, and
> >the pseudo-package will not be closed; further bugs that are
> >relevant only to the given project may still be assigned to the
> >pseudo-package, during this release cycle or future ones.
> >Maintainers of the project are expected to continue to provide
> >assistance to maintainers, and future evaluations of multi-package
> >projects for future releases may reclassify the project as "failed"
> >or "postponed" should it fall back in keeping up with maintainer
> >requests (this classification might be appropriate for projects that
> >require significant domain-specific knowledge, such as a "SE Linux
> >configuration for all daemons" project, or that require testing on
> >non-default installations, such as a "add support back for sysvinit"
> >project).
Yes, it absolutely makes sense to re-evaluate such projects for each
release cycle; and if the support from the drivers of this feature is no
longer available, then it should definitely be removed.
I suggested that it be evaluated together with other such features, at
the point where it is obvious whether or not such features are being
maintained; but I suppose that evaluating them together with the
viability of release architectures rather than with other similar
projects might work too. What matters is not *when*, but *that* it
happens.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Multi-package projects
Hi Ansgar, On Fri, Oct 07, 2022 at 02:07:55PM +0200, Ansgar wrote: > On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote: > > - After the merits and problems of the proposed new projects are > > discussed, the release team decides which projects are accepted for > > the next release. > > (I specifically do not mention what rules the release team should > > follow in deciding which projects to accept -- I trust their > > judgement) > > This sounds like you propose to create some sort of technical steering > committee which probably should not be required to be identical with > the release team. Not really; we already have a technical committee, there is no need to create another one. > But as a practical example: some people have suggested packages not > shipping configuration files in /etc (including, for example, init > scripts in /etc/init.d). As far as I understand some people even say it > is Debian's core mission to support such new configurations to give > more freedom to users. > > How would this work and reduce conflicts with your proposal? Would it > be okay for people driving this change to, for example, just drop > /etc/init.d scripts? [...] My proposal would indeed not work if there are multiple projects that want to make conflicting changes (i.e., one team that wants to remove all files from /etc, and one team that wants to add init scripts where necessary, which would by necessity be in /etc). I would expect the release team in this proposal to make sure that no such conflicting projects are accepted at the same time (or at least, for them to attempt to do so). On Fri, Oct 07, 2022 at 02:36:13PM +0200, Ansgar wrote: > The proposal adds a few more bits reminding me of old concept of > release goals (which Debian dropped), Yes, I can see that. However, there are a few crucial differences. Release goals were just "project wide goals that the release team thinks are a good idea". If a vocal minority objects to the goal, then they can veto it, at least for their own packages. The idea here is to add ways to work around such an inactivity veto. > but I'm not seeing how it would > avoid the problems we had (or have) with systemd or usrmerge. > It hides > a lot of conflict behind this simple statement: > > | - After the merits and problems of the proposed new projects are > | discussed, the release team decides which projects are accepted for > | the next release. > | (I specifically do not mention what rules the release team should > | follow in deciding which projects to accept -- I trust their > | judgement) > > and assuming everyone will then accept this decision. It makes no such assumption; instead, it assumes that there will indeed be people who oppose it, but that the project can still reach completion even in the face of such opposition. There are multiple ways in which Debian-wide projects fail: - There will always be a group of developers who procrastinate on implementing the required changes. This proposal makes it explicit that the drivers of the project are expected to write the necessary patches, and are allowed to NMU those patches given inaction by other developers, so that procrastination cannot be the reason why the necessary updates are not performed (unless it is procrastination on the part of the project's drivers, but, well...). - There are often some developers who prefer not to accept a given patch, because they don't want to be responsible for maintaining the offered code going forward. This proposal makes it explicit that the drivers of the project remain responsible for the necessary code, even after it has succeeded, and that it can be removed from packages with immediate effect should the project no longer have the necessary man power to keep up. This should (hopefully) mitigate that effect somewhat. - And yes, there is often (or perhaps I should say, "usually") a group of people who think the whole idea is a bad idea to begin with, and that Debian shouldn't implement this bad idea at all. These people will refuse actively to accept the given patches, not for any of the other two reasons I mentioned, but because they would rather that the project fail. If the number of developers who feel this way is large enough, then the project will likely fail to meet the release team's standard of completeness when the project is evaluated. At this point, the opposition will have "won", and the project-specific code can be removed from the project. Alternatively, however (and what I consider more likely), the vocal group of people who decided not to accept these patches will turn out to be a small minority, the release team will evaluate that the project has succeeded, and suddenly these patches turn into RC bugs, meaning they will either be accepted anyway, or the package in question will be removed from the archive -- either way, the proponents have "won", and the feature is available
Re: Multi-package projects
* Wouter Verhelst [2022-10-07 19:58]: I'm not sure I agree with that assessment. I believe DEPs are mostly for discussing changes that can then be voluntarily implemented by individual package maintainers; whereas this is intended to allow those who want the change to actually do the work for that change more easily, which DEPs don't do. Perhaps I'm missing something? I'm not that much of an expert in DEP scope either, but what they do share with your proposal is an associated state like your Accepted/Succeded/Failed/Postponed/Maintained. I have only one remark at this point: By definition, a project has a limited scope and time frame, so at some point it has to end. For things like /usr-merge, or any other transition, this is a good fit. That's debatable, as the phrase "the Debian project" shows, but sure, I guess we can rename things after the first release cycle if we think it matters. I knew you would bring up the "Debian Project" :) You may have missed it, but my proposal already contained a similar suggestion: I didn't miss it, but I think it should be a separate thing after the intial project has finished successfully, for psychological reasons: such a project will often be something experimental at first, and I also believe we should not be afraid to terminate projects which do not work out, if only to avoid endless frustration. But at some point, a project is no longer experimental, it becomes a part of Debian proper. It may sound like pedantry on my part, but I think it is a huge motivational boost to see your project "graduate" to something new and shiny, even if it does not make much of a difference in the daily workload. The Eclipse Foundation does something similar, they start with incubator projects, and once those have matured enough, they become "real" Eclipse projects. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
