Sorry for stealing your thread, but you started asking about github review emails :)

Standard review inline comments are disabled on purpose, each comment generates one email, so we decided that is better after review to write a regular comment "NACK, please see inline comments" or so.

I would expecting that the new review feature is sending all comments in one batch, but I was wrong. I used the new review feature (with the pending comments) but when I sent it I received all comments as single notifications again, so again one inline comment = one email

Even worse it is with states of review (approved, required change). I didn't received any notification from github related to this (not sure if is part of any inline comment message or just not implemented yet). This is not documented in their API docs (according David) so we cannot use it our tools yet.

Generally adding Labels ACK/Rejected are more visible and filters can be made easily.

So for now I would stay with our old workflow and not extend email notifications. We can play with new review feature for longer time and decide if it is worth to use it (and change email notification accordingly)


On 15.09.2016 22:49, Ben Lipton wrote:
On 09/15/2016 02:12 AM, jcholast wrote:
jcholast commented on a pull request

In addition to my inline comments above:

1. "Certificate mapping" does not really evoke "certificate request templating" 
to me, and is also used in the context of mapping identities to certificates. Could we use a more 
suitable name to avoid confusion?
2. The `ipalib.certmapping` module is used only in `ipaclient`, so that's where 
it should be located. It can be moved to `ipalib` later if necessary.
3. I don't think `IPAExtension` deserves it's own module, at least not now.

See the full comment 

Tried sending my comments as a "review" (new Github feature) and it seems they don't get sent to the list that way. So:

Thanks for the comments! I've fixed the simple ones and replied to the rest. Regarding your comments about file organization:

 1. I quite agree that certmapping isn't a good name for what this
    turned out to be. With the convention of naming modules after the
    objects they model, perhaps a good name would
    be|certrequest|or|csr|? The command could be renamed to something
 2. Just to confirm, you're suggesting just moving these classes to
    the|ipaclient.plugins.<whatever we end up calling it>|module?
 3. Seems reasonable, I've moved it into the ipalib module for now. It
    will go wherever the contents of that module end up.

Logistical stuff:

  * Now that this is under review I won't add any more content. Are
    you ok with the two commits about testing being part of this
    review or should I remove them?
  * If you run rebase --autosquash with the latest commit it doesn't
    actually apply cleanly, but I'm trying not to change history while
    it's being reviewed, so I'll do the rebase later on if that's ok?

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA:

Reply via email to