Bart Martens <ba...@debian.org> writes:
>> > 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
It is still more responsibility than sponsoring, whether you orphan or
take over the package, because you're not just introducing a new package
or a new version as with sponsoring, you're not just doing an NMU, but
you're taking away something from someone. This latter part is what - in
my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
NMUs.
>> 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.
And the reasons why the package should be orphaned overlaps quite a bit
with previous attempts at getting the package fixed/updated/whatever by
other means.
If there were no previous attempts, then the package should not be
considered for ITO.
>> >> 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.
I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
I never said otherwise. I merely said that *waiting* for ACK/NACK
replies should have a timeout, and if no response arrives within a
reasonable amount of time, we should default to allowing the salvager to
proceed.
That is all. Without the timeout, we have a hole in the system: how long
do you have to wait for replies? When is majority reached? As soon as
3/0? What if that happens within 10 minutes, and a NACK would come on
the 15th? If waiting for majority does have a timeout, what happens if
there are no replies for one reason or the other?
These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
and default to yes in case of no replies, on the grounds that mistakes
can be corrected, and we should be civilised enough to not flame the
salvager to crisp if that happens (since it was us who failed to give
him feedback in the first place - punishment shall be on us, not the
salvager).
--
|8]
--
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/87d305y88b....@luthien.mhp
