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 >>>>> >>>>> >>>>> >>> >>> >>>
