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 do so. Any code in packages relevant to the
project may be immediately removed by their maintainers before the
release (there should be a sufficient amount of time for maintainers
to do so before the freeze), whether it is functional or not.
- Postponed: the project failed to reach all of its goals, but it is
likely they might be able to do so in the next release cycle.
Maintainers *may* remove code relevant to this project before the
next release with the same rules as projects in the "failed"
category, but the project will probably be back next release, so it
is likely they'll have to add that code back by that time.
- 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).
The goal of this proposal is to attempt to balance the (sometimes
conflicting) interests of multiple parties:
- Package maintainers who are not interested in a project should not
have to work on it (they can just reassign bugs and forget about
them);
- Developers who are interested in a project should not be stymied by
having to convince each and every individual developer of the merits
of their proposal (they have to convince the project at large before
they can get started, but once that's happened the project is active
and maintainers are expected to apply reasonable patches); they get a
chance to complete their project, but there is a clear "success or
bust" cut-off point;
- Projects that will require ongoing maintenance will be maintained by
the people who care about it; should these people disappear, there
will again be a clear "success or bust" cut-off point after which the
relevant code can be immediately removed.
Does any of that make sense?
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
