[Spice-devel] spice refactoring: workflow suggestion

[Frediano Ziglio]

> 
> Hi,
> 
> As in a mailing list it is a bit hard to track of the status of each
> PATCH (acked/reviewed/pushed) and we still have tons of batch of
> patches to apply/test/review I would like to suggest the following:
> 
> 1-) When a batch is pushed, send an email in-reply-to 00/00 mail saying
> that patches were pushed.
> -- This really helps when one is behind following the changes
> 

This can be done.
On the same subject I thing the spreadsheet should be publicly available
(read only). It mainly contains list of open source patches, progress,
some report.

> 2-) Push series as a whole when acked instead of pushing each patch
> when acked. In case a few patches of a series are taking time but a
> few have been acked, maybe pushing those acked but let us know with
> an email
> -- Reviewing a patch to later on see that it was pushed already means
> time lost. I believe an email is quicker then matching which patch awas
> pushed or not.
> 

These series are quite different from normal ones as the patches inside
are quite different one from another, they don't share the same aim.
It never happened that all patches was accepted at once.
I agree a reply saying "pushed" could work.

> 3-) Might sound silly but as this involves lots of patchs in a short
> period, it might be interesting to have acked-by, tested-by, reviewed-by
> ? At least for the refactoring...
> 

I add the Acked-by. Nobody seems to review but not ack to but if somebody
want to distinguish the two cases is free to tell review instead of ack.
Do you think we should add a reviewed-by line for each people that commented
the patch?
I don't know if is worth to add the tested-by. I do some small test before
committing but is really dirty and fast. I mean, style/move patches you can
just test that is mainly compiling, working but fix for instance would
require reproduction and I don't think this is done strictly for all fix
(we must take also in consideration there are really few fixes compared
to other changes).
Just to not scare people on testing we run quite often some automated test
and I/we ran different tests for leaks and memory errors but more
periodically than for single patches.

> Any thoughts?
> Regards,
>   Victor Toso

I really agree something is wrong in the process.

I have the sensation that the acknowledge process is a bit weird and
different than usual. One reason is that author is not changing the
patches that are changed by somebody else. This makes the editor a
co-author removing him the theoretical possibility to ack the patch.

Frediano