Re: Project direction with testing changes (branches and patches)

[Lars-Dominik Braun <lars@6xq.net>]

Hi Chris,

> So, I think I've recently switched to thinking about the problem as one
> of testing changes, rather than just testing patches. Since both patch
> series, and branches are used to propose changes, I think this makes
> sense.
I agree with this analysis and this was always something that bugged me
about Patchwork: That it knew about patch series (most of the time), but
seemed to operate on individual patches only.

>   - Then there's the general UI component, ideally a first time
>     contributor would be able to take advantage of automatic feedback
>     about a patch they submit. There's multiple other groups of users
>     though, like patch reviewers, and committers for example.
> […]
> The UI part is much less certain, I've done some work with Patchwork,
> and I do have some ideas in mind, but there's still more thinking and
> work to do in this area.
This is the main problem right now: UI. As a reviewer I need the
following information about a changeset:

1 Is anyone else reviewing it already and what were the comments? (Do I
  need to take a look at it?)
2 Which packages/components are affected? (Do I have the knowledge to
  review this changeset?)
3 Are there any obvious issues with it? (Does it pass linting? Does it
  build? Can it be rebased onto master without conflicts?)
4 Where can I pull the changeset from to do further tests?
  (Patch-over-email is super-fragile, from encoding/newline issues to
  merging problems)
5 Who is the contributor? (Does he/she have commit access or do I have
  to commit on his behalf?)

I also want to subscribe to certain changesets (new comments, new
versions, …) and filter them to find those, where I can actually help.

And debbugs certainly can’t provide any of this. I believe it would be
wise not to spend too much time to recreate what GitLab/gitea/GitHub/…
do already and just use them to our advantage, filling the holes with
bridges/bots to some CI infrastructure (it does not matter whether this
is Cuirass, Chris’ build coordinator, the Data Service, … – we just have
to be able to get the data in and out somehow).

Cheers,
Lars