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>> 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>> ----- > > Date: Wed, 30 Nov 2016 11:08:27 +0100 > From: Laszlo Ersek <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>> > > 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 ]
signature.asc
Description: OpenPGP digital signature
