asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: PLEASE READ: Automatic formatting of sources
Date Tue, 30 Jan 2018 15:43:07 GMT
Sure. And it is your project.

The only value in my comments was the view from outside.

The fact that this is only for untouched does changes the matter
substantially

On Jan 29, 2018 7:04 PM, "Till Westmann" <tillw@apache.org> wrote:

> Hi Ted,
>
> just to follow up on this. We’ve been using a shared code format for a few
> years, so most of the code is formatted consistently. And we’ve also had a
> style checker for a while that checked the changed code against the style.
>
> However, one problem that we’ve still seen repeatedly is that different
> versions of tools (Eclipse, IDEA, the formatting plugin) - using the same
> input file - disagree on the way to break long lines. So we often had
> changes from one style of line breaks to another one and back which made
> diffs busier than necessary.
>
> This current change should fix that and it only affects
> - line breaks and
> - files that haven’t been touched since we introduced the format tests.
>
> So the amount (and complexity) of merge conflicts shouldn’t be too bad.
>
> Till
>
> On 29 Jan 2018, at 7:28, Michael Blow wrote:
>
> > Indeed it is a brute-force solution to the problem; while we pay a one
> time
> > cost to baseline the codebase as formatted, this eliminates the constant
> > extraneous (formatting) diffs when reviewing patches on gerrit as we make
> > incremental (and often reverse) progress.  To ensure we don't deviate
> from
> > the format, we have a Jenkins test which will block the patch in case of
> > noncompliant code.
> >
> > On Sun, Jan 28, 2018 at 8:42 PM Ted Dunning <ted.dunning@gmail.com>
> wrote:
> >
> >> I am an outsider, but this seems really heavy handed.
> >>
> >> Perhaps better would be a style checker that prevents tests from
> passing.
> >> That would allow a human to judge a bit of the best way to meet the
> >> requirements.
> >>
> >> Potentially large automated reformats can really be painful to merging.
> >>
> >> On Jan 28, 2018 3:01 PM, "Steven Jacobs" <sjaco002@ucr.edu> wrote:
> >>
> >>> Just curious, is it going to format everything (as in, your change
> >> cleaned
> >>> up the entire code base) or just the edited lines only?
> >>> Steven
> >>>
> >>> On Sun, Jan 28, 2018 at 1:01 PM Michael Blow <mblow.apache@gmail.com>
> >>> wrote:
> >>>
> >>>> All,
> >>>>
> >>>> As mentioned in last week's status meeting, I have submitted a change
> >>> which
> >>>> applies and enforces our code format[1] at build / jenkins time.  As
> of
> >>>> this commit, source formatting happens as part of the
> 'process-sources'
> >>>> build phase.  This can be run explicitly (to format your code prior
to
> >>>> commit) but is already run prior to the compile phase, so if you are
> >>>> building with maven, it will be run for you.
> >>>>
> >>>> Jenkins will be enforcing that patches moving forward comply with the
> >>>> template [2].  If your patch fails this job, ensure you run 'mvn
> >>>> process-sources' and resubmit the result.
> >>>>
> >>>> To migrate outstanding topic branches, it is recommended to do the
> >>>> following steps to minimize conflict resolution:
> >>>>
> >>>> *ade merge cb9ca97531eddee2cd312654bf13b0905cb3ef6e~1 *
> >>>> *mvn process-sources -Psource-format -Drat.skip*
> >>>> *ade commit -a*
> >>>> *ade merge cb9ca97531eddee2cd312654bf13b0905cb3ef6e*
> >>>> *ade commit -a*
> >>>>
> >>>> Let me know if you run into any issues,
> >>>>
> >>>> Thanks,
> >>>>
> >>>> -MDB
> >>>>
> >>>> [1] -
> >>>>
> >>>> https://cwiki.apache.org/confluence/download/attachments/61322291/
> >>> AsterixCodeFormatProfile.xml
> >>>> [2] -
> >>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-source-format/
> >>>>
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message