Hi Scott, I really appreciate your feedback, especially with respect to how other contributors might react. It is important to stress to all contributors and committers that I'm a deep believer in community work and I look forward to learning from and working with all of you. I warmly remember the initiative that Sharan and I took with the community in [1]. I also raise my hand as the first person to make mistakes, both in code and also in communicating.
My language might be a bit harsh, and I will work to tone it down and be more objective. However, I also ask you all to look at things in context. This is not a thread in isolation from what has been going on for a long time. There is a reason and history behind our reactions. To avoid repeating what we discussed in [2] I will just get to the point: Jacques, using his own words "Commits a lot". This machine-gun commit pattern means more quantity and less quality which is the reason why he gets vetoes. In fact, I cannot even remember when / if I vetoed others. Committing faulty / bad quality code in addition to being degrading to the project, is also time consuming for other contributors / committers to review. A time which could be spent writing code, refactoring and doing useful stuff. If you are providing quality commits consistently and then you make an error then I wouldn't react the same way to my reaction here. My perception of the reason you said you "I understand your frustration" is that you see this pattern as clearly as I do. In many occasions, I make an objection with (using your words) a "brief description" for a certain commit, but end up spending lots of time arguing because Jacques would refuse to revert. So you would expect after all these incidents that either a) he will be more careful or b) he would be more willing to revert and cooperate; neither seems to be happening. Jacques has an immense amount of energy that I really wish we can positively utilize in the community by just slowing down and being a bit more careful. I do not enjoy nor do I find it the best use of my time to review commits and veto them, and it would be actually much easier to just ignore all this stuff and say to hell with it. So please try understand where I'm coming from. Finally, I apologize for anyone who was displeased with my tone, and again I look forward to working with all of you. Cheers, [1] https://cwiki.apache.org/confluence/display/OFBIZ/Re-Factor+To-Do+List [2] https://s.apache.org/jB5f Taher Alkhateeb On Thu, Jun 29, 2017 at 1:13 AM, Scott Gray <[email protected]> wrote: > Hi Taher, > > I can understand your frustration, but this: > >> This commit is wrong and bad on multiple levels. Please revert > > > is an unproductive and unreasonable request. Whether you want to or not, > you have to justify the request. Obviously the developer doesn't know what > is wrong or they wouldn't have committed it in the first place. Asking > them to revert without giving even a brief explanation of what you find > wrong leaves the committer completely in the dark and it isn't how vetoes > are supposed to work. Asking for blind obedience to your demands to save > you the time of explaining them will never fly with any committer. > > Again, I understand your frustration and I've been there myself many times > in the past but being hostile accomplishes nothing other than your ability > to work productively with other committers in the future. I can say from > bitter experience that it does nothing to improve the behavior of whoever > you're communicating with and if you're being obviously unreasonable it > will damage your standing with other contributors as well. > > Regards > Scott > > On 25 June 2017 at 21:22, Taher Alkhateeb <[email protected]> > wrote: > >> As usual, you refuse to revert because you don't understand the code and I >> pay the price of spending my time explaining. I hope you will reconsider >> this time consuming and non-cooperative behavior. >> >> The quick version: >> - copy and paste antipattern >> - incorrect conditional checking leading to both blocks getting executed or >> both blocks not executing >> >> Your belief that Gradle fails because java does not expect to be killed is >> amazing! It means you do not understand what this code is doing and what is >> causing the failure. >> >> >> On Jun 25, 2017 10:42 AM, "Jacques Le Roux" <[email protected]> >> wrote: >> >> What makes you think it's wrong? I tested it locally using 2 background >> instances and it cleaned worked. >> >> I also tried with one standard instance (not in background). It works, and >> you get this message >> >> :ofbiz FAILED >> FAILURE: Build failed with an exception. >> * What went wrong: >> Execution failed for task ':ofbiz'. >> > Process 'command '/usr/lib/jvm/java-8-oracle/bin/java'' finished with >> non-zero exit value 137 >> >> Which I believe is OK because Java does not expect to be killed! >> >> Jacques >> >> >> >> Le 24/06/2017 à 20:04, Taher Alkhateeb a écrit : >> >> > This commit is wrong and bad on multiple levels. Please revert >> > >> > On Sat, Jun 24, 2017 at 10:56 AM, <[email protected]> wrote: >> > >> > Author: jleroux >> >> Date: Sat Jun 24 07:56:45 2017 >> >> New Revision: 1799736 >> >> >> >> URL: http://svn.apache.org/viewvc?rev=1799736&view=rev >> >> Log: >> >> No functional change >> >> >> >> Improves terminateOfbiz byt using TERM before KILL >> >> https://fr.wikipedia.org/wiki/Kill_(Unix) >> >> https://unix.stackexchange.com/questions/8916/when- >> >> should-i-not-kill-9-a-process >> >> >> >> Modified: >> >> ofbiz/ofbiz-framework/trunk/build.gradle >> >> >> >> Modified: ofbiz/ofbiz-framework/trunk/build.gradle >> >> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/ >> >> build.gradle?rev=1799736&r1=1799735&r2=1799736&view=diff >> >> ============================================================ >> >> ================== >> >> --- ofbiz/ofbiz-framework/trunk/build.gradle (original) >> >> +++ ofbiz/ofbiz-framework/trunk/build.gradle Sat Jun 24 07:56:45 2017 >> >> @@ -332,8 +332,13 @@ task terminateOfbiz(group: ofbizServer, >> >> standardOutput = processOutput >> >> } >> >> processOutput.toString().split(System.lineSeparator()). >> each >> >> { line -> >> >> + // Try to terminate cleanly >> >> if (line ==~ /.*org\.apache\.ofbiz\.base\.s >> >> tart\.Start.*/) >> >> { >> >> - exec { commandLine 'kill', '-9', >> >> line.tokenize().first() } >> >> + exec { commandLine 'kill', '-TERM', >> >> line.tokenize().first() } >> >> + } >> >> + // Only kill if needed >> >> + if (line ==~ /.*org\.apache\.ofbiz\.base\.s >> >> tart\.Start.*/) >> >> { >> >> + exec { commandLine 'kill', '-KILL', >> >> line.tokenize().first() } >> >> } >> >> } >> >> } >> >> >> >> >> >> >> >> >>
