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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52762b6a.5060...@thykier.net