Hi Paul, Am Fri, Apr 29, 2022 at 07:13:42AM +0800 schrieb Paul Wise: > > The packaging work is supposed to start *after* the ITP is filed,
Sure. > so > this is a suboptimal order to do things in and doesn't provide much > value, The "packaging work" to create the debian/ dir is a 1min process since for R this is automated. Do you expect a racing condition in this minute? > except as a way to prevent people packaging the same R library > during the wait in NEW, but the presence of the R library in the R-pkg > team VCS already provides that, so the ITP bug isn't really needed. The automated process also checks existing WNPP bugs so it makes sense to file such a bug. Moreover it is used to document rejects. I don't want to say that WNPP bugs are a better solution than your proposal. My point was simply that there is some existing relation between BTS and NEW which might be usable or not. > Even when filing ITPs before packaging, for language ecosystem teams > where all library packages for the language go through the same team, > team co-ordination mechanisms are probably enough of a way to prevent > duplication of work, and that work is mostly automated anyway for > several such teams, so the ITP bug mostly isn't really needed. I confirm that it is not strictly needed (that's another reason why we feel pretty safe to file the ITP after the packaging) but as I explained it has some use anyway and since it is so brain dead simple to create we do it. > Some teams make exceptions for packages that aren't strictly just > libraries; for eg Rust folks to ITPs for things that ship executables, > so that people can hear about things they might want to use on Debian. > > > That's true. I just wanted to mention that some of your ideas > > are in a way used even now. > > Yeah, the proposal was derived from the suggestion to file ITPs for all > NEW packages, mostly aimed at avoiding the deficiencies with that idea. Nice. Kind regards Andreas. -- http://fam-tille.de