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

[Gergely Nagy <algernon@madhouse-project.org>]

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
them.

> 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
port.

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.

Indeed.

> 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.

-- 
|8]