On Fri, Oct 26, 2012 at 09:59:16AM +0200, Gergely Nagy wrote:
> 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.
When a package has clearly not been maintained for years, then marking it as
orphaned doesn't take "away something from someone".
I agree that there is some responsibility involved. But the work is easy. In
obvious cases sufficient ACKs will be collected in no time. When there is
doubt, a NACK is appropriate. I trust DDs to be responsible with this.
>
> >> 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.
Marking a clearly unmaintained package as orphaned is useful regardless of
previous attempts to update it.
>
> >> >> 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.
I'm with Steve L. on this. Without sufficient ACKs, no orphaning.
> 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?
Collecting ACKs is useful to avoid needless delay to wait for possible
objections. It is, in my opinion, OK to conclude the ITO with three ACKs,
without further delay. If nobody sends ACKs nor NACKs then something went
probably wrong with the cc to debian-qa.
> These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
I prefer no delay in the text, but I have no strong opinion on this.
> and default to yes in case of no replies,
Without sufficient ACKs, no orphaning. My opinion on that is quite strong.
> 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).
Of course, the maintainer can re-adopt his/her package during the time it is
orphaned. But if someone else already has retitled the O to ITA, then in
general that person should be allowed to continue. Of course, all involved
parties can still talk and agree on something else.
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/20121026093548.gb23...@master.debian.org
