Re: [PATCH 0/6] pre-processing pipeline and transient package replacement

[Claudius Heine <claudius.heine.ext@siemens.com>]

Hi Baurzahn,

On 24/04/2019 16.38, Baurzhan Ismagulov wrote:
> On Wed, Apr 24, 2019 at 10:38:08AM +0200, Claudius Heine wrote:
>> Well there are different kind of patchsets, some patchsets implement
>> features and some just cleanup/refactor code. The latter ones might contain
>> a number of small improvements all over the code base. They are related in a
>> sense that they 'do' the same (refactoring/cleanup), not necessarily with
>> the same code pieces. But they might work towards cleaning
>> up/refactoring/preparing the code for a bigger feature or rework that comes
>> later.
>>
>> So what you are saying that you would prefer instead of putting all those
>> small refactoring changes together in one bigger patchset, that I should
>> submit all those patches separate from each other? An then state that the
>> feature/rework patchset depends on all of them?
>>
>> I think that will cause more work on every ones end (especially with the
>> slow CI build), but if that is what needs to be done when contributing to
>> Isar, I will look into reordering my patchsets accordingly and maybe write
>> some scripts to automate this pipeline for myself.
> 
> The current practice resulted from past discussions, in which amending patches
> without reviewing again or applying series in part had been objected to.

IIRC there were objections about reordering patches within one series, 
since they normally depend on each other and always describing those 
dependencies explicitly does not really make sense IMO. I would also 
object to modifying a patch content without making it clear first what 
the issue with it is.

Fixing spelling or grammar mistakes is fine IMO, especially in commit 
messages, as long as it doesn't change the content itself to much.

Just applying some cleanup and refactoring patches from a series in 
order, without applying the feature (if it contains one) or some other 
latter problematic patches is fine as well IMO.

> I
> haven't looked at the proposals in detail yet, but in general, if we can
> improve the process to save overall effort, I'm for it.

Well the first goal should be to improve the code. Therefore fixes, 
cleanup and refactoring patches, if they make sense, should be merged 
fast. For features, new dependencies or bigger/backward incompatible 
rework (UX changes), there should be a discussion etc. maybe with help 
of an RFC patch to demonstrate those ideas.

Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de