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

Stephen Gallagher sgallagh at redhat.com
Mon May 12 12:35:11 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2014 06:09 AM, Jakub Hrozek wrote:
> On Fri, May 09, 2014 at 09:00:28PM +0200, 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.
>> 
>>> However, now I realize that we could have simply ran the script
>>> on the commit before the original and made a diff to extract
>>> manual changes, which we could have then applied on the older
>>> tree, after running the script there.
>>> 
>> Backporting much simpler patches can be difficult. I already
>> wrote in previous mail how it should be done.
>> 
>>> 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. At least, you learnt
>> something new and will not do the same mistake in future.
> 
> Please let's stay technical and considerate to one another. This 
> discussion has took the route of bikeshedding already.
> 
> On the topic of every patch builds, yes, I prefer that too and I
> should have reviewed this aspect of the patchset. But it's not
> worth bringing up on the devel list in more context than something
> to keep in mind for next time.

Just to chime in here as well, we have never had a *strict*
requirement that every patch builds individually. We strongly prefer
it (for backporting purposes), but there are plenty of occasions where
we have opted for (This patch-*set* compiles together, but we have
broken the patches up along sensible lines to make review possible).

I personally think this patch-set is fully in keeping with that
philosophy (that ability to review sanely trumps technical purity). As
long as it's noted in the review request that "patches A, B and C must
always be applied together to work properly".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNwv/8ACgkQeiVVYja6o6N5HgCcC2DM1dWQN6yOwAAe1+/mTGN6
Xn4An3w+waTsWFBoqJZvly3CsW0NZ9dR
=PUHx
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list