[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

Charles Plessy <plessy@debian.org> writes:

> Le Sun, Aug 19, 2012 at 11:13:23PM +0200, Gergely Nagy a écrit :
>> Michael Biebl <biebl@debian.org> writes:
>> > If those ports need a GR to silence any criticsm regarding those ports,
>> > then something is going seriously wrong.
>> I've yet to see said criticism.
> In the absense of regression tests, we distribute thousands of packages that
> nobody knows if they work or not, because nobody ever used them.

That's not a criticism against the port, but a criticism against
packages not having tests. It is by no means the fault of the port that
packages are not properly tested, as that applies to every single one of

> Then one day they happen to fail to build, or regression tests are implemented
> and crash, and suddenly the maintainer has to take care of development issues
> that are not supported upstream nor by the porters.

If neither upstream, nor porters care about a particular package, that
means there are very little use of having it on that port, and one
should consider changing the Architecture line to exclude the failing

That's about a minute of work + an RM request for that port: another
minute or two. I don't think this is a bad thing, or something *any*
maintainer should find troublesome.

> We need to take this specialisation into account, be proud of what
> our ports bring to their users, and be more open-minded about ignoring
> combinations of softwares and architectures that were never designed
> to work together.


> There is a simple heuristic to detect such cases, it is when the only help a
> maintainer receives is guidance on how to ask for a login on the porter box and
> fix the package himself.  If neither upstream, the users and the porters care,
> then we need to provide to the maintainer some ways to ignore issues without
> having to spend time on requesting architecture-specific archive
> removals, etc.

What's wrong with requesting arch-specific removals? It doesn't take a
lot of time, perhaps at the other end. But then, such removal requests
are - judging by a quick glimpse of bugs-dist - aren't all that common
to warrant special treatment of any kind.


Reply to: