On Tuesday, February 8, 2022 8:23:36 AM EST Andreas Tille wrote: > Am Fri, Feb 04, 2022 at 09:39:09AM -0800 schrieb Russ Allbery: > > Various people have different reactions to and opinions about the > > necessity of this review, which I understand and which is great for > > broadening the discussion. But I feel like we're starting to lose track > > of my original point, > > Apropos loosing track. ;-) > > > namely that I don't see why we are prioritizing this > > particular category of bugs over every other type of bug in Debian. The > > justification has always been dire consequences if we don't stamp out all > > of these bugs, but to be honest I think this is wildly unlikely. > > I fully subscribe to this. > > I'd also like to thank Scott for > a) His speedy processing of onetbb (which was the package triggering > this thread. > b) Taking part in the discussion (as so far only member of the ftpteam > TTBOMK) > > I think the point of Scott in this discussion is clear. However, to my > understanding it is in contrast to the posting I originally pointed > to[1]. I would like to hear some official statement for the specific > case of packages that are in new. > > Specific remark to onetbb: I'd fully agree with Scott that this might > be a good example to stress his point since the package was obviously > not OK and was in serious need of some extra work. But in the same way > it serves to support Russ' point as well: While d/copyright was not OK > it was probably not OK only according to our strict standards (which I > subscribe as well) and nothing someone would Debian sue about. The > delay in the new queue delayed the Python 3.10 migration and kept > several other friction points. So how do we want to weight "just another > RC bug that should be fixed" against the delay of development in other > aspects? > > I'd be supper happy if this discussion would lead to some statement > in some document we could use as reference which would probably avoid > further discussion of this kind. I'd even volunteer to draft such > a document ... if I would only know what should be written. > > Kind regards > > Andreas. > > [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html First, once it was pointed out that onetbb was blocking something, it got a quick review. While it doesn't always work out (no need to write in with examples of when it didn't), generally if there's feedback that a particular package is delaying things it will get processed reasonably quickly. I know that someone noticing the issue and manually poking the FTP Team for a review is still a point of friction, but it's not like we delayed python3.10 by months or anything. Upon reflection, I think there may be a certain amount of talking past each other going on. When Russ says treat licensing/copyright bugs like other RC bugs, I think we see different things. >From my point of view, treating something like other common classes of RC bugs means that the project is producing tools and processes to make detection of such bugs more automated to remove them from the archive, that developers are actively looking for them, and that they are routinely fixed in the normal course of Debian development. When it comes to this class of RC bug, I don't see a lot of that happening. My suggestion earlier in the thread about there being lots of these issues in the archive that could stand fixing wasn't that this is OK, but that it seems pretty clear that we are, as a project, not treating these bugs like other RC bugs. I understand Russ meant not block things from the archive until manual review has determined they are reasonably OK (New review isn't perfect) in this respect. I don't think what Russ is asking for (as I understand it) is currently feasible. I think our choices today are requiring manual review to at least provide some mitigation in this area or give up and decide we don't care. If developers, as a whole, treated these kinds of bugs with the same seriousness they treat other RC bugs, then I think we might be in a different position. None of the work required to get into that different position requires changes in New. I think changing New first is putting the cart before the horse [doing things in the wrong order]. If people want licensing and copyright issues to be treated like other RC bugs, I think the first step is to treat them like other RC bugs[1]. This is, of course, just my perspective, not a team position. Scott K [1] I am aware that there are people doing stuff on this front. This is not a dig at you.
Attachment:
signature.asc
Description: This is a digitally signed message part.