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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> ----- > > > > Date: Wed, 30 Nov 2016 11:08:27 +0100 > > From: Laszlo Ersek <[email protected] <mailto:[email protected]>> > > Subject: [Qemu-devel] a suggestion to place *.c hunks last in patches > > To: qemu devel list <[email protected] > > <mailto:[email protected]>> > > > > 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 ] > >
