Quoting Michael Lustfield (2020-02-09 11:04:25) > On Thu, 06 Feb 2020 10:32:42 +1100 > Dmitry Smirnov <onlyjob@debian.org> wrote: > > > IMHO it is disturbing that one of the most essential processes in > > Debian -- acceptance of new and modified packages -- operates almost > > in secrecy. > > This is an understandable perspective, but secrecy probably isn't the > best word. > > > To make matters worse ftp-masters rarely leave their comments in ITP > > issues. As I've recently learned that have profound effect on > > processing of new packages. > > I personally think this sounds like a fantastic (and not very > difficult) idea. Me too. > Where do you propose the bug mail be sent for NEW/binNEW packages > without an ITP? I suggest (for now) to use our issue tracker only for packages with an ITP. > > One of my packages spent a year in the NEW queue at some point > > raising to position number 4. Apparently before release of Buster > > (2019-07-06) member of ftp-masters team left an internal (invisible > > to the public) comment on my package that was not communicated to me > > until 7 months later when my package was rejected based on that > > comment. The comment could have been addressed without delay if it > > was left on the corresponding ITP issue where it belong. > > I suspect when you say, "member of ftp-masters team," what you mean is > "FTP-Masters Trainee." FWIW- Trainees are not technically part of the > team. We get just enough access to be able to provide package reviews. > Those reviews are then either discussed with us or sent back in a > rejection/prod message. > > I agree that it could be valuable to see comments; however, they're > almost always going to be from Trainees. Since we're not technically > part of the team, it's important that we don't speak on behalf of the > team. Publishing Trainee comments would effectively be doing that. I suggest (for now) that ftp trainees CC an ITP (when such ITP exists) when they share their findings with ftp-masters. To help avoid misunderstandings, such messages could begin with something like this: NB! This is no FTP-Masters ruling (just suggestions from a Trainee). Is anything stopping Trainees from voluntarily changing their praxis right now to cc ITPs when available? > > A precious time was lost but more importantly one can see that > > current process requires an extra effort to communicate with > > maintainers -- a something that would not be necessary if > > ftp-masters use the official channel that exist specifically to > > discuss introduction of new packages -- ITP bug reports. [...] > > I would personally *LOVE* to see ITPs be a requirement for *ALL* new > packages. Making it a requirement and expecting ftp-masters to ignore > any upload until the ITP has existed for at least X days would be > absolutely fantastic. It would fix some redundant library uploads (see > golang/nodejs/etc.) and it would provide a mandatory level of review > by the wider community. > > Back when I tried to get gitea packaged for main, I had a number of > ITPs commented/closed mentioning the alternate library name or a > reason it can't be packaged. I think we don't need mandatory ITPs to get the ball rolling on better transparency. I suggest that (for now) we just make transparency yet another argument for voluntarily filing ITPs. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature