[Avocado-devel] Fwd: [Qemu-devel] a suggestion to place *.c hunks last in patches

[Lucas Meneghel Rodrigues]

Although I'm not sure if github pull requests would follow this ordering
rule. If they do, the order proposed seems sane.

On Wed, Nov 30, 2016 at 5:51 PM Cleber Rosa <crosa at redhat.com> wrote:

>
>
> On 11/30/2016 12:14 PM, Lucas Meneghel Rodrigues wrote:
> > +1. Looks interesting!
> >
> >
>
> Indeed! +1 from me too.
>
> > On Wed, Nov 30, 2016, 12:10 PM Ademar Reis <areis at redhat.com
> > <mailto:areis at redhat.com>> wrote:
> >
> >     Saw this message on qemu-devel and I think it's a nice suggestion
> >     for Avocado developers.
> >
> >     The ordering for a python project should be different, but you
> >     get the idea (replies to this thread with the suggested list are
> >     welcome).
> >
> >     Thanks.
> >        - Ademar
> >
> >     ----- Forwarded message from Laszlo Ersek <lersek at redhat.com
> >     <mailto:lersek at redhat.com>> -----
> >
> >     Date: Wed, 30 Nov 2016 11:08:27 +0100
> >     From: Laszlo Ersek <lersek at redhat.com <mailto:lersek at redhat.com>>
> >     Subject: [Qemu-devel] a suggestion to place *.c hunks last in patches
> >     To: qemu devel list <qemu-devel at nongnu.org
> >     <mailto:qemu-devel at nongnu.org>>
> >
> >     Recent git releases support the diff.orderFile permanent setting. (In
> >     older releases, the -O option had to be specified on the command
> line,
> >     or in aliases, for the same effect, which was quite inconvenient.)
> From
> >     git-diff(1):
> >
> >            -O<orderfile>
> >                Output the patch in the order specified in the
> <orderfile>,
> >                which has one shell glob pattern per line. This overrides
> >                the diff.orderFile configuration variable (see git-
> >                config(1)). To cancel diff.orderFile, use -O/dev/null.
> >
> >     In my experience, an order file such as:
> >
> >     configure
> >     *Makefile*
> >     *.json
> >     *.txt
> >     *.h
> >     *.c
> >
>
> Since most Python projects have very few files not ending in `.py`, I
> suspect most relevant configurations will contain a list of paths instead.
>
> For Avocado, I believe something like this could make sense:
>
> Makefile
> docs/source/*.rst
> avocado/utils/*.py
> avocado/core/*.py
> avocado/plugins/*.py
> scripts/*.py
> selftests/*
>
> Reasoning: it's nice to read the docs to get a grasp about the feature.
> Then, take a look at utility functions that may have added, and then
> used by core code.
>
> A new or existing plugin may leverage those changes, and so can the
> avocado test runner tool itself.
>
> Finally, check how that is being tested.  We could also add unittests
> right after avocado/{utils,core}/*.py.  In reality, though, we tend to
> keep a utility API change in its commit...
>
> Anyway, let's try that out.  I'm all in favor of easier to read commits.
>
> - Cleber.
>
> >     that is, a priority order that goes from
> >     descriptive/declarative/abstract to imperative/specific works wonders
> >     for reviewing.
> >
> >     Randomly picked example:
> >
> >     [Qemu-devel] [PATCH] virtio-gpu: track and limit host memory
> allocations
> >
> http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg05144.html
> >
> >     This patch adds several fields to several structures first, and then
> it
> >     does things with those new fields. If you think about what the
> English
> >     verb "to declare" means, it's clear you want to see the declaration
> >     first (same as the compiler), and only then how the field is put to
> use.
> >
> >     Thanks!
> >     Laszlo
> >
> >
> >     ----- End forwarded message -----
> >
> >     --
> >     Ademar Reis
> >     Red Hat
> >
> >     ^[:wq!
> >
>
> --
> Cleber Rosa
> [ Sr Software Engineer - Virtualization Team - Red Hat ]
> [ Avocado Test Framework - avocado-framework.github.io ]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20161130/eeaca01e/attachment.htm>