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

Lukáš Doktor ldoktor at redhat.com
Thu Dec 1 08:52:04 UTC 2016


Dne 30.11.2016 v 22:18 Lucas Meneghel Rodrigues napsal(a):
> Although I'm not sure if github pull requests would follow this ordering
> rule. If they do, the order proposed seems sane.
>
That's exactly what I had in mind :-) We can give it a try, though.

Lukáš

> On Wed, Nov 30, 2016 at 5:51 PM Cleber Rosa <crosa at redhat.com
> <mailto: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>
>     > <mailto: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>
>     >     <mailto: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>
>     <mailto: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>
>     >     <mailto: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
>     <http://avocado-framework.github.io> ]
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 502 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20161201/bbf610c2/attachment.sig>


More information about the Avocado-devel mailing list