Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


Hi,

On Fri, Oct 27, 2017 at 04:49:55PM +0200, Jan Holesovsky <kendy@collabora.com> wrote:
Good point - another reason why not to do the rewriting completely
automatically server side I guess.

But still, I see the Thorsten's point why it would be easier for people
in many cases; that's why I proposed the 'automatic, but ending up as
an additional changeset' way, that at least gives a chance to inspect &
do something about that.

I see the benefit of that, and I can accept that as a compromise, though
I fear a bit it introduces another set of problems:

- Currently pushing via gerrit is not required, just recommended. So we
  have a pre-commit hook which we can depend on (I don't remember any
  leftover SAL_DEBUG in commits in the past year e.g.), but it happens
  regularly that the "gerrit hook" (Jenkins) is bypassed.

- It is not clear to me who would do the CI integration work. One could
  say I should do it, since I'm proposing the clang-format enforcement,
  but while hacking the per-commit hook is OK, I have very little
  interest in diving into Gerrit and/or Jenkins plugins. ;-)

- If the style is violated, a new patch set gets created, which means a
  new build -- so our valuable build-on-4-platforms CI would be even
  more slow than today.

(Last point would be that this still means: if you have a patch series,
and only CI points out style problems, you get conflicts in later
commits, while a pre-commit hook would catch these problems early and
would not lead to conflicts later.)

It's not clear to me if the "let's push this to TDF infra instead of
running it locally" technique for style enforcement solves more problems
than it introduces.

Regards,

Miklos

Attachment: signature.asc
Description: Digital signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.