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.
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. 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, hans...@apache.org 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);
