That's all just lovely sentiment Hans. The point is that communication is the key, if you see a problem in the trunk due to a recent commit then report it to the committer (if you know who it was) via the dev list. If it's a blocking bug then reverting it is fine, but it really needs to come along with the report. We've always done this so I'm not sure why it's becoming an issue now.
Negative statements were merely following negatively perceived (and unusual) actions on your part. Regards Scott On 29/08/2013, at 3:28 PM, Hans Bakker wrote: > Thank you Jacques, you are doing a really good job not only committing > contributions but also keeping everybody working together. > > I admit my action was a bit quick, but on the other hand getting a change in > the system which is blocking, (this change cannot be shown to a customer) > then still my action was at least understandable. It took me some time which > commit did it where i was short in time anyway. Still I think that changes > which are blocking in major functions like the main menu should not be > committed. > > That said, let me make some general comments. My business would not exist and > continue to exist without the help of OFBIz committers, In general, the last > couple of years, Scott and Adrian did an excellent job on commenting and > contributions, Jacques is the King and help line of the contributors, Jacopo > more on the background making sure Apache interests are respected and I am > trying to contribute requests from my customers more on the application level. > > The last 2 years I see the requests especially from larger companies > increasing. We are expanding the activities in AntWebsystems and will move to > a new building the end of the Year. Let stick together and encourage each > other making this product better and refrain from sending negative statements? > > Thank you all, committers and contributers for the time you spend on Apache > OFBiz. > > Regards, > Hans > > > On 08/28/2013 05: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); >
