Pierre,
The below procedure are not ASF but OFBiz. There is nothing about it in ASF rules. Each community is asked to use its own. These are
OFBiz's.
Please note that only PMC members have the right to vetoing a commit
http://www.apache.org/foundation/voting.html#binding-votes
also read carefully http://www.apache.org/foundation/voting.html#Veto and all
the page
It's all about meritocracy
http://www.apache.org/foundation/how-it-works.html#meritocracy
Jacques
From: "Pierre Smits" <[email protected]>
There you have it. This commit should and must be reverted because Apache
procedures weren't followed. I just reminded you of that.
When you asked for the opinions of the community you solicited a vote. Thus
procedures should be followed. Or do you feel that you can implement
changes without following procedures?
2012/7/16 Jacques Le Roux <[email protected]>
As we already agreed long ago, the flow should roughly be:
Dev ML proposition => dev ML dicusssion => if tiny change and community
consensus then code and commit else if not tiny change (I let apart no
consensys as it's obvious) => Jira + patch => reviews (not only from
committers, we pray developers not being committers to review as well, a
good way to become committers BTW) => if agreement then commit => if
necessary and possible create a wiki page to explain the feature
Did I miss something? Ha maybe vote. In a rare cases where there is no
consensus (as a community we should always try to get to a consensus) and
the community thinks a vote is needed.
Please refer to ASF documentation for more http://www.apache.org/**
foundation/voting.html <http://www.apache.org/foundation/voting.html>
So the preliminary doc (mostly requirements, etc) should be in Jira, then
completed in wiki
David also created a wiki space for "OFBiz Requirements and Designs":
https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>.
This could be used in BJ's spirit for larger tasks...
Jacques
From: "BJ Freeman" <[email protected]>
that is true, however a month from now it will be lost and will have to
be searched.
So you start by putting you proposal on the wiki then link in the email
for discussion.
once the discussion is completed it is put on the wiki with a link to a
page of the discussion. and a synopsis of the result of the discussion.
Adrian Crum sent the following on 7/16/2012 3:45 AM:
Having a Wiki page that describes the new feature would be great, but it
needs to be created after the commit and some review. Creating a Wiki
page before there is any interest expressed in the proposal could be a
waste of time. So, I cover the goal, scope, and effect on the current
design in the emailed proposal.
-Adrian
On 7/16/2012 11:32 AM, BJ Freeman wrote:
What would be great is if we had a Dev map that showed a design plan
The Goal, Scope, and effect on the current design.
having all these in one place on the wiki would help in over all design.
my 2 cents.
Adrian Crum sent the following on 7/14/2012 3:38 AM:
I have an application metrics feature working on my local copy and I
was
wondering if there would be any interest in including it in the
project.
A metric is a measure of average execution time. Each metric is given a
unique name.
I modified the control servlet and service dispatcher to use metrics.
To
add a metric to a request, just include an XML element:
<metric name="URL: webtools/main" />
to the request map and the average response time for the URL will be
maintained. Likewise, to add a metric to a service, just include an XML
element:
<metric name="Service: createMaintsFromTimeInterval" />
to the service definition and the average execution time for the
service
will be maintained.
Metrics are kept in memory. There is a service to retrieve all metrics.
There is also a Web Tools page to view all metrics.
A heartbeat server could retrieve the metrics to check on server load
or
to provide histograms.
The metric element has an optional threshold attribute, so some action
could be taken when the metric crosses a threshold. For example, in the
following request map:
<request-map uri="ViewMetrics">
<security https="true" auth="true"/>
<metric name="URL: webtools/ViewMetrics" threshold="1000"/>
<response name="success" type="view" value="ViewMetrics"/>
<response name="threshold-exceeded" type="view"
value="ServerBusy"/><!--
displays a friendly 'server busy' page -->
</request-map>
the ServerBusy view would be rendered if the average response time
exceeded 1000 mS. This can be useful for providing a lively web
experience on a heavy-traffic web page.
The service dispatcher does not use the threshold. I could not think of
a use case where service behavior should be modified based on average
execution time.
The metrics code is very small - two java files. Also, the
modifications
to the webapp component and service component are very small.
What do you think?
-Adrian
