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.


On Wed, Nov 30, 2016 at 5:51 PM Cleber Rosa <cr...@redhat.com
<mailto:cr...@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 <ar...@redhat.com 
    > <mailto:ar...@redhat.com <mailto:ar...@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 <ler...@redhat.com 
    >     <mailto:ler...@redhat.com <mailto:ler...@redhat.com>>> -----
    >     Date: Wed, 30 Nov 2016 11:08:27 +0100
    >     From: Laszlo Ersek <ler...@redhat.com <mailto:ler...@redhat.com>
    <mailto:ler...@redhat.com <mailto:ler...@redhat.com>>>
    >     Subject: [Qemu-devel] a suggestion to place *.c hunks last in patches
    >     To: qemu devel list <qemu-de...@nongnu.org 
    >     <mailto:qemu-de...@nongnu.org <mailto:qemu-de...@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.) 
    >     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

    For Avocado, I believe something like this could make sense:


    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 
    >     http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg05144.html
    >     This patch adds several fields to several structures first, and then 
    >     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 
    >     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> ]

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to