From: "Pierre Smits" <[email protected]>
Adrian,
I want you and any other committer to follow the procedures and guidelines
established by the Apache foundation. If you feel that you aren't obliged
to adhere to them you shouldn't be a committer.
Jacques,
The Apache document on voting (which has been referred to) clearly states
that voting should take place for at least 72 hours to let everybody in the
community have his or her say. Also, although the document also states that
only PMC members have a binding vote the expressions made by other
community members should be considered as well.
Furthermore, Adrian explicitly said 'any objection'. Thus, inviting any
OFBiz member participating in development. If Adrian kept to his word, we
would have seen the commits reverted. And not have this discussion.
Vote is only when no consensus is found. I can agree Adrian was a bit short on time, else there was a consensus it seems (note the
number of +1), apart Ruth and you. Not even sure Ruth is against actually.
Jacques
2012/7/16 Adrian Crum <[email protected]>
Pierre,
Please stop wasting everyone's time. We have tried to explain to you how
the community works. If it is that difficult for you to grasp, then perhaps
you should just let it go.
-Adrian
On 7/16/2012 1:02 PM, Pierre Smits wrote:
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<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>
<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
