[FFmpeg-devel] [PATCH v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.

[Michael Niedermayer]

On Tue, Jul 07, 2020 at 04:00:10PM +0200, Nicolas George wrote:
> Manolis Stamatogiannakis (12020-07-05):
> > The section has been expanded to outline how to manage patch revisions.
> > ---
> >  doc/developer.texi | 37 ++++++++++++++++++++++++++-----------
> >  1 file changed, 26 insertions(+), 11 deletions(-)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index b33cab0fc7..dec27cb509 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -491,18 +491,25 @@ as base64-encoded attachments, so your patch is not trashed during
> >  transmission. Also ensure the correct mime type is used
> >  (text/x-diff or text/x-patch or at least text/plain) and that only one
> >  patch is inline or attached per mail.
> > -You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show up, its mime type
> > -likely was wrong.
> > +You can check the most recently received patches on
> > + at url{https://patchwork.ffmpeg.org, patchwork}.
> > +If your patch does not show up, its mime type likely was wrong.
> >  
> > -Your patch will be reviewed on the mailing list. You will likely be asked
> > +Your patch will be reviewed on the mailing list. Give us a few days to react.
> > +But if some time passes without reaction, send a reminder by email.
> > +Your patch should eventually be dealt with. However, you will likely be asked
> >  to make some changes and are expected to send in an improved version that
> >  incorporates the requests from the review. This process may go through
> >  several iterations. Once your patch is deemed good enough, some developer
> >  will pick it up and commit it to the official FFmpeg tree.
> >  
> > -Give us a few days to react. But if some time passes without reaction,
> > -send a reminder by email. Your patch should eventually be dealt with.
> > -
> 
> > +When preparing an updated version of you patch, make sure you increment
> > +its @emph{roll-counter}. This is achieved by adding a @code{-v <n>} argument
> > +to @code{git format-patch}/@code{git send-email} commands.
> 
> I know many core developers do not bother with that, and I never found
> these "v3" very useful: if I am not involved in the discussion, I will
> not remember what number is the latest. And if I become involved in the
> discussions, my mail client can sort the patch by date and I take the
> latest.
> 
> > +Additionally, it is recommended to register for a
> > + at uref{https://patchwork.ffmpeg.org, patchwork account}.
> > +This will allow you to mark previous version of your patches as "Superseded",
> > +and reduce the chance of someone spending time to review a stale patch.
> 
> Is interacting with Patchwork to become mandatory when submitting
> patches?
> 
> There is this classic scenario:
> 
> 1. People work on something.
> 
> 2. Somebody sets up a tool to make the work easier.
> 
> 3. People start relying on the tool.
> 
> 4. The tool proves imperfect.
> 
> 5. People are required extra work to go around the flaws of the tool.
> 
> 6. Overall, the tool has made the work not easier but harder.
> 
> Are we going that way with Patchwork?
> 
> If I am required to log into a website and do maintenance each time I
> send an updated patch, I will just send less updated patches. I am not
> alone in this.

a lot of patchwork patch maintaince can be automated, ive written a script
to do that.
What this does is basically look at local git, fetch all patches from patchwork
(and cache them locally)
and then find stuff which is either invalid, superseeded, applied, ... but not
marked correctly
last it dumps the command line commands to the screen for a human to decide
if they are correct and should be run as is or not.
See:
https://github.com/michaelni/patchwork-update-bot

It worked fine until the server was updated or maybe the number of patches
became too big.
now it times out  while fetching patches, the command line tool (pwclient) 
times out too (xmlrpclib.ProtocolError: <ProtocolError for patchwork.ffmpeg.org/xmlrpc/: 504 Gateway Time-out>)
so the bug is not in patchwork-update-bot
Someone has to investigate why this timeout happens and make it not timeout
then run this automatically in regular intervalls

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200707/3fe0e5be/attachment.sig>