> Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both on the way up ('upcoming')
and on the way down ('legacy')).
It seems to me that "second class ports" can be divided into three rough
categories, 'new ports that are up and coming' (arm64 and ppc64el were
in this category until recently, x32 could arguablly be included too),
'legacy ports where maintinance has slipped to the point they got kicked
out of the set of first class ports' (alpha, m68k, etc) and 'ports that
despite being around for years never made it to the set of first class
ports' (hurd-i386, ppc64, sparc64, sh4, powerpcspe, argubally x32)
Now on to the political side.
What should the expectations of maintainers of second class ports be?
Should they expect reasonable patches to be merged? who gets to define
"reasonable"? what if anything should their recourse be if/when
maintainers either ignore or activately stonewall them? is it ok for
maintainers of second class ports to NMU when they are ignored by
package maintainers? if package mtainers stonewall maintainers of second
class ports should they reffer the matter to the technical committe?
Should porter expectations be different between "upcoming", "legacy",
and "never made it" ports? should reports be clearly labelled so that
maintainers can quickly tell if the reported problem relates to a "first
class" or a "second class" port? should "second class" ports be labelled
as "unofficial"?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554945f0.9040...@p10link.net