[flashrom] please reject my two previous letters

[Antonio Ospite]

On Sat, 10 Jan 2015 01:34:34 +0300
Boris Baykov <dev at borisbaykov.com> wrote:

> On Fri, 9 Jan 2015 22:49:56 +0100
> Stefan Tauner <stefan.tauner at alumni.tuwien.ac.at>
>
> > On Fri, 9 Jan 2015 23:54:28 +0300
> > Boris Baykov <dev at borisbaykov.com> wrote:
> 
[...]
> >> Please explain how is better to split this patch to make it easy for review.
> 
> > We want to verify all changes to flashrom in quite some detail to keep
> > it as stable as it is. A single huge patch like yours takes a very long
> > time to fully understand. It is probably not even possible to review
> > such a big change in one go without making some mistakes or overlook
> > error of the original author. Smaller independent patches could be
> > reviewed entirely without getting too much of a headache. Does that
> > make sense to you?
> 
[...]
> 
> Unfortunately I can't imagine how to split this patch in parts because all
> the patch logically has one idea and that's why my changes in different
> files are connected to other changes and they work together.
> 

These are just examples of how you _could_ logically split you patch:
  - base support for the JEDEC extensions can go into a separate patch;
  - flashrom hooking for the extensions and for 4 byte addressing can go
    into a dedicated patch;
  - the simulation code may go into a followup patch, optionality is
    a hint for identifying a splitting point;
  - programmers specific support for 4ba can go into a dedicated patch;
  - new flash chip definitions can go into a dedicated patch;
  - cosmetic fixes, if any, go into a dedicated patch;
  - standalone UI changes (strings in console messages) can go into
    a dedicated patch;
  - Implementation of the progress meter can go into a separate patch.

As you said, splitting by files in general does not make sense, but
splitting by "feature" does.

The idea is that an incremental patchset is a coarse (and cleaned up)
version of your development history.

If you want details of examples of _how_ this can be achieved in
practice starting from a single big patch I can elaborate more.

The tools you use influence the way you operate: svn, when used locally,
tends to encourage big patches, where a tool with better support for
local branches (e.g. git) could make it easier to track locally the
development history and review it before public submission.
No flame intended whatsoever.

Ciao,
   Antonio

-- 
Antonio Ospite http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?