[SSSD] [PATCH] DEBUG macro refactoring - 1.11 backport

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Fri May 9 19:21:11 UTC 2014


On 05/09/2014 10:00 PM, Lukas Slebodnik wrote:
> On (09/05/14 15:09), Nikolai Kondrashov wrote:
>> On 05/05/2014 10:36 PM, Lukas Slebodnik wrote:
>>> On (01/05/14 00:51), Nikolai Kondrashov wrote:
>>>> One thing, though: having the script-generated patches separate certainly made
>>>> cherry-picking easier and faster.
>>>>
>>> The patches were pushed, so we can continue with this discussion.
>>>
>>> The only way how to make chery-picking easier is to have better merging
>>> algorithm in version control syste. The script generated patches solve problem
>>> with back porting changes to diverged branches.
>>>
>>> I am not against script generated patches. I like scripting, it simplifies my
>>> life. My idea was to have script which will fix(convert) 99% of cases and
>>> the last 1% of corner cases can be solved easily by hand.
>>> Sometimes it is easier to fix the last 1% of problems by hand rather than
>>> spending days with creating a robust conversion script. But the main point is
>>> to include hand made changes to the generated patch and not to the separate
>>> patch. With this approach work is simplified with script and we don't lost
>>> benefit "every patch builds"
>>
>> The reason why I would sacrifice the "every patch builds" rule, originally,
>> was to simplify backporting to older branches, which would likely be
>> different and thus simply cherry-picking the monolithic (scripted+manual
>> changes) commit would not be possible to do with confidence, and re-running
>> the script would be necessary (which I did with this backport).
>>
>> In that case, my idea was, keeping manual changes separate would allow us to
>> simply cherry-pick them, without having to extract them from the monolithic
>> commit by hand or to do them again.
>>
> It was very bad assumption that patch which changed 215 files
> ( 7825 insertions, 7825 deletions) would be possible to cherry-pick
> to older branch without any problem. This is a reason why script was written.

Sure. There is some misunderstanding going on, apparently.
I didn't make the assumption that we can just cherry-pick a huge
script-generated commit, and it was me who wrote that script, partly to avoid
that, before I joined the team :)

I'm just saying that, of course, I would have to re-run the script on the
older branch and then I would have to fix up whatever the script missed.

However, my original assumption was that if we have a monolithic commit with
scripted+manual changes, it wouldn't be easy to extract the fixup part from
it and I would have to redo it by hand on the older branch.

As I say in the previous message, I now realize extracting the fixup part
would be possible, provided the script works the same way.

>> So, yes, it is possible to have "every patch builds" and also to backport
>> scripted+manual patches reliably. The script in question would better be
>> included with such commits, though.
>
> The script was included in commit message.

Sure, I put it there. I merely state a requirement for such system to work.

> At least, you learnt something new and will not do the same mistake in
> future.

I wouldn't say it was learning, rather realizing there is a way.
Once again, I support "every commit builds" idea. I'm implementing CI to make
that achievable, actually.

Neither it was my mistake much. I urged the maintainers to squash commits as
necessary and supported squashing manual changes into the scripted ones
explicitly. They didn't, probably to speed up the push and I decided to go
along the same way when backporting to make things simpler to track and
review.

I should probably stop defending myself now :)

Sincerely,
Nick



More information about the sssd-devel mailing list