Raphael Hertzog <hertzog@debian.org> writes:

We should have a single web service that is able to handle all those workflows and provide all the inputs that each team needs to make their decision. It should have a nifty web interface (including with
authentication and restricted access for embargoed security updates) where people can inspect the packages and approve/reject the packages if they
are part of the affected teams.

I know that many people would like more web interfaces, but if I _have_
to use a web service to do my packaging work, I will stop. No accounting
for taste I guess.

d

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:

That's where you come into play: it would be nice if you could share
what are — according to you — the most important projects/improvements that Debian ought to make. You can share your ideas here by replying to
this email, but it would be interesting to file them as new issues in
the "grow-your-ideas" project and then reply here pointing to your new
issue:

I filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/19 which states:

# Unified workflow for package review

## The problem

There are many processes in Debian where we want to review Debian packages
in some way:

* when you upload to Debian for the first time (the NEW queue)
* when you upload a stable update
* when you upload a security update (embargoed or not)
* when you upload a backports
* when you upload to mentors.debian.net
* when you sponsor a package for someone else
* when you review a merge request on salsa that changes your packaging rules

All of those have custom workflows, and different but somewhat overlapping
set of checks. Sometimes you have an associated web interface, sometimes
not, but it's never the same web interface.

## Expected situation

We should have a single web service that is able to handle all those
workflows and provide all the inputs that each team needs to make their decision. It should have a nifty web interface (including with
authentication and restricted access for embargoed security updates) where people can inspect the packages and approve/reject the packages if they
are part of the affected teams.

## Additional information

Some of the problem space described here is actually part of the reasons
why I decided to start debusine and why we inject Freexian money into
debusine:
https://freexian-team.pages.debian.net/debusine/devel/why.html

We want to improve the review workflow for LTS updates.

Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 08 Feb 2022, David Bremner wrote:

Raphael Hertzog <hertzog@debian.org> writes:

We should have a single web service that is able to handle all those workflows and provide all the inputs that each team needs to make their decision. It should have a nifty web interface (including with authentication and restricted access for embargoed security updates) where people can inspect the packages and approve/reject the packages if they
are part of the affected teams.

I know that many people would like more web interfaces, but if I _have_
to use a web service to do my packaging work, I will stop. No accounting
for taste I guess.

I fully expect such a service to have an API that can be used to build
a command line interface for people like you.

At the same time, we must recognize that our aging email-based workflows
and the multitude of different workflows are hurting our ability to
on-board new contributors.

Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Raphael Hertzog <hertzog@debian.org> writes:

I fully expect such a service to have an API that can be used to build
a command line interface for people like you.

Yep, but I already don't use the various things like that for e.g. salsa
or github because it's too much hassle to set up for too little
benefit. Similarly my experience with the "addon email workflows" for
web based tools is that (as second class citizens) they typically don't
quite work right.

At the same time, we must recognize that our aging email-based workflows
and the multitude of different workflows are hurting our ability to
on-board new contributors.

Fair enough. Every tooling choice involves tradeoffs. We just have to be mindful and honest about the friction created for existing contributors
by reducing it for new contributors. I think it's easy to underestimate
other peoples difficulties/annoyances with the workflow that we are used
to. So for people immersed in github or gitlab, this seems like the
natural and obvious way to work, just like for (some) people immersed in
email workflows those seem natural and obvious.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)