There is an Apache way for that also: http://www.apache.org/dev/committers.html. And a related "OFBiz way"
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Hans is simply committing work from his team. As long as he reviews and
amend/fix the code, there is nothing we can say about it.
Some complain that code quality has lowered for some time. But this is not only
due to Hans's commits (committing contibutions is
not an easy job). My opinion on this is as long as you improve your code, there
is nothing wrong in committing lower quality code
(not bad or wrong code of course). Of course it should not break and make wrong
logic/business asumptions... Everybody has the right
to learn... Sometimes it's the hard way... Are we not here to share?
This is my own opinion, not the PMC of course...
Jacques
From: "BJ Freeman" <bjf...@free-man.net>
I have notice quite different coding styles that just does not fit one
person committing code from Hans account. Maybe getting each an account
would better clarify who is committing what.
Jacques Le Roux sent the following on 9/12/2011 1:03 PM:
I don't think you should feel disqualified because you wrote the right
code intially!
Hans has an explanation, but democracy is majority. And Apache way is
vote and majority in such cases. Unfortunately there are no
other best ways than a vote. Now, as David remarked, last time we felt
like the United Nations in some conflicts: you need a
respected police or army to make the law respected...
What I don't understand is why Hans can't keep his changes for himself
to let all the others happy (at least Adrian, Scott, David and I so far...)
Jacques
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
Maybe a vote is in order. I am not going to initiate one because I am
the author of the original code, so I feel like I am
disqualified.
-Adrian
On 9/12/2011 8:13 PM, David E Jones wrote:
Thanks Adrian, I understand what you're getting at exactly now.
Yes, this is frustrating isn't it, and this pattern seems to come up
over and over. That's why I like the moderated community
approach better (as opposed to the Apache way), and I guess you know
my thoughts and approach on that based on my recent efforts…
Still, I suppose that by the Apache way we should vote on this and
consider the results binding, and make the corresponding
changes. If someone goes against that vote result, then I'm not sure
what the Apache way is… i.e. what do you do about a commit
war?
I don't know.
-David
On Sep 12, 2011, at 12:02 PM, Adrian Crum wrote:
David,
Keep in mind that the original design is one that you participated
in. The agreement on the setting precedence in the original
Jira issue was this:
widget.properties -> web.xml -> URL parameters
where widget.properties is the global default, which can be
overridden by a setting in web.xml, which can be overridden by
screen widgets or scripts or whatever (via the current context Map).
The design worked great. Then Hans changed it due to a
misunderstanding of how the design works. Despite repeated explanations
of how the design works, and requests from three PMC members to
revert his change, he refused to change it and threatened the
community with a commit war. Since then we have had a number of
issues reported on the mailing list describing how his change
makes the setting unusable.
It amazes me that a single -1 vote vetoes a change in the Apache
community, but three -1 votes from PMC members can't revert
this obvious break in software design.
-Adrian
On 9/12/2011 7:24 PM, Adrian Crum wrote:
No. The approach suggested by (and committed by) Hans is that the
setting in the widget.properties file overrides any other
setting.
-Adrian
On 9/12/2011 6:19 PM, David E Jones wrote:
No one agrees with which approach? The approach that if you pass a
widgetVerbose=true HTTP parameter that it should override
the widget.properties setting? I agree with that approach…
-David
On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
That's the problem - no one agrees with that approach.
-Adrian
On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
I think I forgot to forward Hans's answer
Jacques
Hans Bakker wrote:
On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
widget.properties's widget.verbose setting has precedence over
web.xml's widgetVerbose setting. So you can't use
parameters.widgetVerbose to override widget.verbose to false.
Is ModelWidget.widgetBoundaryCommentsEnabled() written this
way for
some reasons?
there was a lengthly discussion of this. As long as by default the
properties file is not overridden in web.xml is fine either way.
Another issue is that these HTML boundary comments get
outputted even though the view handler is set to "screencsv". In
the
widget-screen.xsd, the only way to invoke a template to
produce CSV is using<html><html-template />, but this always adds
HTML
comments even if the output is CSV (see HtmlWidget class).
Maybe we could introduce a<csv> element or something like
that?
Anyway, both of those problems combined mean that there are no
apparent clean ways to remove the HTML "template begin/end"
boundary comments from the CSV output if you try to draw it
with an *.ftl template. A workaround kludge for now is to
invoke
the FTL manually through a Groovy script.
Thanks
Jacques
