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.
Where do you propose the bug mail be sent for NEW/binNEW packages without 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.
> 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'd like Debian project leader to engage in the matter of improving
> transparency of ftp-masters team operations and procedures.
This feels a lot like starting a GR and not allowing appropriate discussion.
It's heavy-handed, isn't going to get anywhere, and is going to hurt feelings.
> As very minimum I recommend to change current ftp-master procedures to use
> ITP bugs instead of internal comments whenever possible, for the sake of
> transparency and to optimise communication.
I replied to this idea above.
> I want to encourage a public discussion regarding opening of the ftp-master
> mail list to the public. Currently reasons for unjustified secrecy of ftp-
> master processes is not explained...
It's often said that emotions don't play well with productive discussions.
Adding phrases such as "where it belong", using "secrecy" over "privacy",
calling it "unjustified", and immediately jumping to demands of the DPL are
accusatory and inflammatory, and will likely just get you ignored or start an
unproductive flame war.
I too would love to engage in a civil discussion about ways to improve the
situation. Let's start with this-
Why do reviews take so long?
- The team is tiny
- Much of the team seems very burned out
- The ones that are active tend to stick to source or "unloved" tasks
- There are some very large and/or messy packages that need review
- There are a lot of redundant tasks and frequently-made mistakes
+ A little more automation could help that
- (my opinion) The tools are archaic, cumbersome, and inefficient
+ Fixing this would be a very (non-technically) difficult task
+ An idea I have would help to bring transparency to the process...
^ it's missing an interest requirement :(
--
Michael Lustfield
Attachment:
pgpHploBpzx1V.pgp
Description: OpenPGP digital signature