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

[Ricardo Wurmus]

Christopher Baines <mail@cbaines.net> writes:

> I think using Patchwork or Mumi is viable, it would probably not 
> be
> great to use both in the long term. The most useful thing for me 
> would
> be to pick an approach.
>
> Patchwork is closer in terms of features I think, since it has 
> an API
> for patch series and checks. I know mumi gained the ability to 
> generate
> mbox files for patch series now though.

I wouldn’t mind getting rid of Mumi.

Surely Patchwork has a way to configure the user interface 
somewhat?

> I think the requirements in terms of Mumi would be to have some 
> way of
> querying for patch series to test, or at least all/recent patch
> series. I suppose something could just ask for the 1st or latest 
> series
> each time there's an email to a issue, that might be the 
> simplest
> approach.

There is an /issue/<id>/patch-set/<num> handler to download patch 
series.  IIRC there is a bug somewhere that makes it not work as 
intended, but I did use it in the past to get a whole bunch of 
patches and apply them with ‘git am’.

> Then there's the bits you describe about showing relevant
> information about whatever tests take place. I guess Mumi would 
> need an
> API or some way to find out about that information, and then 
> display
> it. Maybe that could happen in the form of emails with 
> machine+human
> readable data that Mumi could interpret.

I don’t know what this means.  What exactly is needed here?

> Unfortunately I don't know much about the Mumi 
> internals. Ricardo, are
> you able to comment on the feasibility and whether this 
> direction would
> make sense?

I think it’s feasible to add a few more things to Mumi to make the 
existing features work better.  But I should also emphasize that 
I’m in no way attached to Mumi.  If we have something better I’d 
be happy to retire it.  Mumi has served us well; we don’t need to 
extend its use beyond what is reasonable.

--
Ricardo