On 2013-10-29 17:48, Ian Jackson wrote:
> Niels Thykier writes ("Re: Bits from the Release Team (Jessie freeze info)"):
>> [...]
>> As mentioned we are debating whether the "5 DDs" requirement still makes
>> sense. Would you say that we should abolish the requirement for DD
>> porters completely? I.e. Even if there are no (soon to be) DDs, we
>> should consider the porter requirements fulfilled as long as they are
>> enough "active porters" behind the port[0]?
>
> I don't have a good feel for the answer to that question.
>
> It's just that if it is the case that a problem with ports is the lack
> of specifically DDs, rather than porter effort in general, then
> sponsorship is an obvious way to solve that problem.
>
> If you feel that that's not really the main problem then a criterion
> which counts porters of any status would be better.
>
I suppose a "sponsor-only" DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes. I guess the sponsor would also need to dedicate
time to mentor (new?) porters on workflows and on quicks like when is a
FTBFS RC and when it isn't etc.
> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been done "well enough".)
>
> [...]
>
> Thanks,
> Ian.
>
>
Ah, you are not the first to question this process. Obviously, we
intend to keep people up on their promise by "actively maintaining their
port". Sadly, we do not have a clear definition of "actively maintained
ports" and I doubt we will have it any time soon either.
But porters can start by working on the concerns from DSA (if they
haven't already done so). Ports having gcc-4.6 as default compiler
might also consider improving in that area[1].
Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
(#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to
ruby2.0 FTBFS (#726095[3]). Personally, I would also expect that
key-packages work on all ports (on which they are built) in general[4].
All of the (non-mild) DSA concerns are already something we will
officially hold against the ports. Most of the other issues listed
above are not official concerns. However, I would not be surprised if
most of them became official issues eventually.
Until we have a clear definition of "actively maintained ports", I would
recommend porters to err on the side of being verbose over being silent.
As an example, lack of visible reply to mails like [5] makes it seem
like nobody is home.
Mind you, I am not saying porters have the responsibility to fix every
problem forwarded to their port list. I am also aware that sometimes
issues/mail "disappear" in the depths of people inbox - heck it happens
to me as well.
Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS). That way it would at least be
easier for all people to find outstanding issues for the port[6]. It
would also give us the possiblity to trivial declare a problem RC (or
not) for ports. (Plus, then I won't have to update some random file on
release.d.o for every new issue :P)
Anyhow, I hope to be able to give a more "official" statement in the
near future.
~Niels
[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
acceptable as a default for Jessie.
[2] Apparently it is controversial whether that bug should be RC, but it
definitely looks like that kind of thing that will cause issues for ia64
later.
[3] That one got a patch, but it might be worth it to put some pressure
on the maintainer or even doing a NMU.
[4] A rule of thumb could be something like "your port should probably
not be listed here in the long run:
http://udd.debian.org/bugs.cgi?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=asc
"
[5] https://lists.debian.org/debian-mips/2013/08/msg00005.html
Btw, this is not intended to single out mips.
[6] I know that people have been usertags for issues that affect the
port, but it is not clear to me that all those usertags bugged is
something we expect porters to fix. Rather it seems more like porters
tagging the FTBFS bugs they file.
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52762b6a.5060...@thykier.net
