Andrey, I see the following options for PR checks (without intention to merge it): 1.
On Mon, 8 Jun 2020 at 17:59, Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > > HI, > > > Why do you want to run a reproducer from the user list on the TC? > It may be useful to verify a race that can't be reproduced locally on my NB > due to some performance reasons. > > > If all code style rules are good then we should use them in daily coding, > isn’t it? > Yes, also we do not force users to rewrite their code regarding our own > code style. > But I found the code-style (checkstyle, license and inspections) rules > force us to do unnecessary work in this particular case, > thus makes contribution a bit harder. > > > On Mon, Jun 8, 2020 at 5:27 PM Nikolay Izhikov <nizhi...@apache.org> wrote: > > > Hello, Andrey. > > > > Sorry, I still don’t understand your use-case. > > Can you, please, use correct quoting so I can parse your message? :) > > > > Why do you want to run a reproducer from the user list on the TC? > > > > > There is no specific rule. > > > > If all code style rules are good then we should use them in daily coding, > > isn’t it? > > > > Anyway, I think forcing code style rules as early as we can is a good > > thing. > > Some open-source projects(Kafka, for example) forces code style rules even > > on a local test run. > > > > > 8 июня 2020 г., в 17:22, Andrey Mashenkov <andrey.mashen...@gmail.com> > > написал(а): > > > > > > Hi Niolay, > > > > > > Why do you ignore code style rules while developing «quick reproducer»? > > > > > > I don't think it worth effor to fix a user code (e.g. from userlist) just > > > to validate some race condition. > > > > > > There is no specific rule. > > > I'm sad we have no ability to run user code without using any hacks to > > skip > > > style checks with no intention to merge such code to master. > > > > > > > > > On Mon, Jun 8, 2020 at 4:50 PM Nikolay Izhikov <nizhi...@apache.org> > > wrote: > > > > > >> Hello, Andrey. > > >> > > >>> I've just found that I should waste my time fixing styles in user code > > >> that (may be) reproduce some bug, just to validate the bug or fix > > provided > > >> by the user. > > >> > > >> Why do you ignore code style rules while developing «quick reproducer»? > > >> > > >> What specific code style rule is an issue for you? > > >> If we have some rules is just a waste of the time - may be it better to > > >> remove them? > > >> > > >> I’m ++1 to fail the build on code style errors. > > >> Code style errors == compile errors for me. > > >> > > >>> 8 июня 2020 г., в 16:40, Andrey Mashenkov <andrey.mashen...@gmail.com> > > >> написал(а): > > >>> > > >>> Konstantin, > > >>> > > >>> +1 > > >>> > > >>> I've just found that I should waste my time fixing styles in user code > > >> that > > >>> (may be) reproduce some bug, just to validate the bug or fix provided > > by > > >>> the user. > > >>> I'm ok with the idea to block commits with style errors to master > > branch, > > >>> but not for other branches\PR. > > >>> > > >>> Can anybody explain why commiters should waste their time for this? > > >>> Why we even have such a rule to fail build on TC if there is some kind > > of > > >>> style error? > > >>> It looks (like a bullshit) counterintuitive as it is still possible to > > >>> commit to master with having style error, but impossible to just build > > a > > >>> project or to run a test. > > >>> > > >>> > > >>> On Thu, May 21, 2020 at 12:23 PM Konstantin Orlov <kor...@gridgain.com > > > > > >>> wrote: > > >>> > > >>>> Hi Ivan, > > >>>> > > >>>> Thanks for your reply! It’s better to get an answer late than never :) > > >>>> > > >>>> -- > > >>>> Regards, > > >>>> Konstantin Orlov > > >>>> > > >>>> > > >>>>> On 18 May 2020, at 09:04, Ivan Pavlukhin <vololo...@gmail.com> > > wrote: > > >>>>> > > >>>>> Hi Konstantin, > > >>>>> > > >>>>> Surprisingly, I found your message in a Spam folder (gmail). > > >>>>> > > >>>>> We had discussions about the subject before. The most recent one and > > >>>>> reflecting a current state is [1]. You can find many thoughts and > > >>>>> arguments in another discussion [2] (it might be better to start > > >>>>> reading from a bottom). > > >>>>> > > >>>>> [1] > > >>>> > > >> > > https://lists.apache.org/thread.html/6995a4e789117ba3f5577651866cfa99a6ffcc208cf60330d17d5a48%40%3Cdev.ignite.apache.org%3E > > >>>>> [2] > > >>>> > > >> > > http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-td27709i80.html#a41297 > > >>>>> > > >>>>> 2020-04-20 11:00 GMT+03:00, Konstantin Orlov <kor...@gridgain.com>: > > >>>>>> Igniters, > > >>>>>> > > >>>>>> Currently we have code sanity checks [1][2] integrated within a > > build > > >>>> task > > >>>>>> [3]. Do we really need to fail the build (and therefore the other > > >>>> tasks) if > > >>>>>> there is a minor flaw like a missing line at the end of a file or an > > >>>> unused > > >>>>>> import? As for me it could be separated from the build task. > > >>>>>> > > >>>>>> What do you think? > > >>>>>> > > >>>>>> [1] > > >>>>>> > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyle > > >>>>>> < > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyle > > >>>>> > > >>>>>> [2] > > >>>>>> > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_LicensesHeaders > > >>>>>> < > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_LicensesHeaders > > >>>>> > > >>>>>> [3] > > >>>>>> > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite > > >>>>>> < > > >>>> > > >> > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite > > >>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Regards, > > >>>>>> Konstantin Orlov > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> > > >>>>> Best regards, > > >>>>> Ivan Pavlukhin > > >>>> > > >>>> > > >>> > > >>> -- > > >>> Best regards, > > >>> Andrey V. Mashenkov > > >> > > >> > > > > > > -- > > > Best regards, > > > Andrey V. Mashenkov > > > > > > -- > Best regards, > Andrey V. Mashenkov