On Sat, 10 Jan 2015 01:34:34 +0300 Boris Baykov dev@borisbaykov.com wrote:
On Fri, 9 Jan 2015 22:49:56 +0100 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
On Fri, 9 Jan 2015 23:54:28 +0300 Boris Baykov dev@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