On Fri, Oct 07, 2022 at 02:21:04PM +0200, Timo Röhling wrote: > Hi Wouter, > > * Wouter Verhelst <wou...@debian.org> [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.