On Thu, Oct 25, 2012 at 01:50:10PM +0200, Gergely Nagy wrote:
> Bart Martens <ba...@debian.org> writes:
> > On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
> >> Steve Langasek <vor...@debian.org> writes:
> >>
> >> > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
> >> >> > 4. When/if consensus has been reached, the package can be orphaned by
> >> >> > retitling and reassigning the ITO bug accordingly.
> >> >
> >> >> I fear a bit the situation "nobody care enough to comment", being
> >> >> interpreted as lack of consensus. But I do think in that case we should
> >> >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK
> >> >> </joke>).
> >> >> Any suggestion on how to word that properly, without adding yet another
> >> >> timeout rule carved in stone?
> >> >
> >> > I disagree on this point. If you can't get anyone to ack that you
> >> > should go
> >> > ahead with the orphaning, then the system is not working as designed and
> >> > consensus has not been achieved. It's then incumbent on the person
> >> > looking
> >> > to orphan the package to rattle the cage and get developers to pay
> >> > attention.
> >>
> >> On the other hand, it is already hard to find people willing to review
> >> other peoples work. Mandating acks means trusting that there will be
> >> enough manpower to review something potentially unknown. I can't see
> >> that happening reliably.
> >
> > I think that sufficient DDs will review the ITOs. Note that most work is
> > already done by the ITO submitter. Sponsoring a package at mentors ("review
> > other peoples work") is, in my opinion, much more work than reading an ITO
> > and
> > sending an ACK.
>
> On the other hand, ACKing an ITO is much more responsibility, becasue
> it's not only about a package, but about taking over a package too.
No, it is not. See the "two activities" explained here:
http://lists.debian.org/debian-devel/2012/10/msg00261.html
> An
> ITO will also contain quite a lot of info about previous attempts at
> updating the package - that's not simple to review either. It is less
> technical too, which can be off-putting to some.
No, an ITO should just enumerate the reasons why the package should be marked
as orphaned.
> (Mind you, I'm not against the ACK/NACK system, I'm only arguing for
> being able to proceed without N acks after a reasonable amount of time.)
OK thanks for clarifying that. Well, also for clarity, I expect every ITO to
get sufficient ACKs or NACKs (thanks to the cc to debian-qa).
>
> >> As said elsewhere in the thread, the process needs to be easy and
> >> efficient. Hunting ACKs is neither easy, nor efficient.
> >
> > The proposed text is quite easy, in my opinion.
>
> Indeed, it is. Partly because as far as I understand it, it only
> recommends a 3/1 majority, and does not demand it. That's perfectly
> fine.
I guess it's a recommendation because it would go in developers-reference.
That doesn't mean that it would be OK to randomly orphan packages ignoring the
recommended procedure in developers-reference.
Regards,
Bart Martens
--
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/20121026052546.gc10...@master.debian.org
