Scott Gray wrote: > Keeping things productive was definitely the goal of my email. A jira just > wasn't necessary in this case and requiring one adds > additional burden to committers with very little real benefit. The only > purpose served would have been if somebody actually > applied the patch and tested it which is unlikely and would have probably > taken at least a few days, no design discussion was > needed. Adrian fixed the issue within a few hours of receiving a proper > description of what the problem was which is fantastic.
I was more thinking about a Jira creation at the initial time. After the discussion took place, year ago. The general idea is to not hesitate to create a Jira issue with as simple info as possible. I don't see it as really a burden, and it's all benefits at long term. Because you have better capabilities to categorize, historize and search than on a simple ML. > The *only* issue here is that code was reverted without *any* discussion or > notification of the problems faced. A bit rude for > sure, but I don't think it is the end of the world. I would only ask that > Hans be more mindful in the future and follow the > process we've always followed for as long as I can remember. It only > requires us to work together as a team rather than against > each other. +1, KISS when possible, indeed Jacques > Regards > Scott > > On 28/08/2013, at 10:10 PM, Jacques Le Roux wrote: > >> Thanks for your opinion Scott, >> >> Let's try to keep it productive... >> >> Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp >> I'm sure you did not miss it even if it's not part of this email. >> >> I still believe that, the more we share through Jira, the better. For many >> reasons it's more effective than ML. >> For this peculiar case, I must admit, years after, it was out of mind. Here >> a reference to Jira issue, with even a simple >> sentence in description, possibly with a reference to the "aforementioned" >> dev ML thread (the one about "macro widget >> renderers") and if necessary commit/s reference/s, would have help. >> >> What we are so far discussing about in this thread is based on what we >> already agreed (or at least what I remember about it). >> First discuss on dev ML and if necessary open a Jira to collect/share >> opininons and keep a track on all possible info. >> If there is nothing let to discuss and it's a simple thing, don't create a >> Jira and then code and commit straight away. >> >> Let's now compare the possible flows of actions. >> >> Currently (hell) using present for a better story: >> Years ago, we discuss on "macro widget renderers" on dev ML and agree we >> can code and commit straight away (correct me if there >> is/are (a) Jira issue/s about it) >> Few days ago, Adrian directly commits changes about macro widget renderers; >> without noticing on dev ML, thinking everybody >> remember what we talked about. >> Hans finds few issues and reverts Adrian's commit without noticing anyone on >> dev ML. I guess, to do a such thing, at this point >> Hans did not remember about macro widget renderers and "netiquette" was a >> bit upset, or in a hurry. >> Adrian is (rightly) upset and then our current discussion begins... >> >> Possibly (heaven): >> Years ago, we would have discussed on "macro widget renderers" on dev ML >> and created (a) Jira issue/s with references (links) >> to the discussion and commits and all possibly shared info. >> Few days ago, Adrian would have committed changes, noticing others on dev >> ML, with just a link about the Jira (or just saying >> there is one, for others to look for). Possibly only with a comment/link in >> the commit. >> After Hans finds few issues he can refer to the Jira or/and the previous >> discussion about "macro widget renderers". He >> understands what and why Adrian did, and ask for help on the dev ML, instead >> of abruptly reverting Adrian's commit (unfair).- >> >> As I said, I agree Hans made the misconduct. But it's not a reason to put >> all on him and not try to get things better. >> >> This is my opinion (Jira is our friend) >> >> Jacques >> >> Scott Gray wrote: >>> Stop trying to create some sort of solution to a non-existent problem. >>> Things get refactored and sometimes it causes issues, >>> that is the nature of the trunk and Hans can deal with it the same as >>> anyone else, by reporting and/or fixing issues first, and >>> then reverting if no reasonably quick actions can be taken. >>> >>> It's not appropriate to revert a commit without any discussion whatsoever, >>> he didn't even describe the problem until a day >>> later. How is the original committer supposed to rectify the issue without >>> any details? >>> >>> Regards >>> Scott >>> >>> On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: >>> >>>> Then maybe a few words on the dev ML would not have hurt. >>>> >>>> Jacques >>>> >>>> Adrian Crum wrote: >>>>> That was not the case in my commit. The macro widget renderers were >>>>> proposed by Jacopo years ago and we discussed it. The implementation was >>>>> incomplete however. So, I merely finished an incomplete implementation >>>>> of a new feature we agreed on years ago. >>>>> >>>>> -Adrian >>>>> >>>>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>>>> This is indeed a concern. I believe we should always all follow the Jira >>>>>> way of sharing and testing before committing any new >>>>>> major feature or major bug fix (not trivial ones of course). Then, it's >>>>>> possible to wait few days for others to check, not >>>>>> bullet proof but surely better. >>>>>> >>>>>> Jacques >>>>>> >>>>>> Hans Bakker wrote: >>>>>>> If you would have announced this before you implemented it, i would have >>>>>>> known, now in first instance we think this is caused by our changes..... >>>>>>> And only later check the svn updates.... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> Try entering a purchase invoice: >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>>>> >>>>>>> try entering a new accounting transaction: >>>>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> >>>>>>> and at a number of other places...... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>>>> message and I would have fixed it. >>>>>>>> >>>>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>>>> reason to revert it. >>>>>>>> >>>>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>>>> co-operation is a concept you consistently fail to understand. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>>>> Adrian, >>>>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Very good to hear you like my commits which at least make a >>>>>>>>> difference for our end users. Although i personally appreciate your >>>>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>>>> mostly not aware of it. >>>>>>>>> >>>>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>>>> keep up the good work! >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>>>> Hans, >>>>>>>>>> >>>>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>>>> else's commit. >>>>>>>>>> >>>>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>>>> project. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> On 8/25/2013 11:28 PM, [email protected] wrote: >>>>>>>>>>> Author: hansbak >>>>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>>>> New Revision: 1517434 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>>>> Log: >>>>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>>>> >>>>>>>>>>> Removed: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>>>> >>>>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> URL: >>>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>>>> ============================================================================== >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> (original) >>>>>>>>>>> +++ >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>>>> implemented >>>>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>>>> null, screenStringRenderer); >>>>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>>>> servletContext); >>>>>>>>>>> + // this is the object used to render forms from their >>>>>>>>>>> definitions >>>>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>>>> formStringRenderer); >>>>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>>>> treeStringRenderer); >>>>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".encoder"))); >>>>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>>>> screens.getContext()); >>>>>>>>>>> screens.render(page);
