On 08/13/2014 05:17 PM, thierry bordaz wrote:
On 08/13/2014 04:48 PM, Petr Viktorin wrote:
On 08/08/2014 09:24 AM, thierry bordaz wrote:

The attached patch is a first patch related to 'User Life Cycle'

It creates 'Stage' and 'Delete' containers and configure DS plugin to
scope only 'Active' container or exclude 'Stage'/'Delete'


The .ldif files are copied only during initial installation. When
upgrading to a version with this patch, changes in .ldif files are not

So all updates need to be in .update files. For example, for DNA
plugin configuration you would need something like this in an .update

dn: cn=Posix IDs,cn=Distributed Numeric Assignment
remove:dnaScope: "$SUFFIX"
add:dnaScope: "cn=accounts,$SUFFIX"

.update files, on the other hand, are applied both on installation and
on upgrade. To avoid duplication you can put whole entries in .update
and delete them from the .ldif, provided the entries always end up
being created in a correct order.

Hello Petr,

    Thanks you very much for your review. I understand that the fix does
    not work in upgrade and I will change it following your recommendation.
    I think that adding entries with the .update syntax should be
    similar to what is in 55-pbacmemberof.update for example.


Patch submission technicalities:
Please don't add the "Reviewed by" tag to the commit message, it's
added when pushing. The other tags are not used FreeIPA. (What's a
"Flag Day"?)
When you send more patches that depend on each other, either attach
them all to one e-mail, or explicitly say what each patch depends on.

    That is correct I used a review template that was for 389-ds and I
    will change it. 'Flag Day' was part of 389-DS template, it was a
    flag to inform if the fix had a wide impact (things needing to be
    I split ULC fix into several logical sub fixes and you are right
    they are all related even if for example 0002 does not depend on 0001.
    Do you want I resend patch 0003 with the statement it relies on 0001
    (and with the correct commit message ?).

These guidelines just make it easier for us to handle the large numbers of patches that land on the list. Try to follow them next time you send a patch (or revision), but there's no need to resubmit things just to comply.
We can change the message when pushing if the patch contents are acked.

Thanks for the dependency information.


Freeipa-devel mailing list

Reply via email to