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