Re: Multi-package projects
On Fri, Oct 07, 2022 at 02:21:04PM +0200, Timo Röhling wrote:
> Hi Wouter,
>
> * Wouter Verhelst <wouter@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.
Reply to: