Discussion: Application Metrics Feature

[BJ Freeman]

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

[BJ Freeman]

just for clarification this is not a new features map, but a Dev
consideration map. so people can see what has been considered and the
outcome.

BJ Freeman sent the following on 7/16/2012 3:54 AM:

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

[Pierre Smits]

You make it sound like it is still open for debate. However, you committed
this new feature to trunk. In barely under 30 hours after you started this
mail thread. If you were truly seeking input from the community, you could
and should have waited longer and for the outcome.

[Adrian Crum-3]

We are still discussing it, and if there are any objections I can revert
the commit.

-Adrian

On 7/16/2012 12:04 PM, Pierre Smits wrote:
> You make it sound like it is still open for debate. However, you committed
> this new feature to trunk. In barely under 30 hours after you started this
> mail thread. If you were truly seeking input from the community, you could
> and should have waited longer and for the outcome.
>

[Pierre Smits]

Then I object to having it in trunk before the outcome of this discussion.

2012/7/16 Adrian Crum <[hidden email]>

> We are still discussing it, and if there are any objections I can revert
> the commit.
>
> -Adrian
>
>
> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>
>> You make it sound like it is still open for debate. However, you committed
>> this new feature to trunk. In barely under 30 hours after you started this
>> mail thread. If you were truly seeking input from the community, you could
>> and should have waited longer and for the outcome.
>>
>>
>
>

[Adrian Crum-3]

For what reason? Is there a flaw in the design?

-Adrian

On 7/16/2012 12:16 PM, Pierre Smits wrote:

> Then I object to having it in trunk before the outcome of this discussion.
>
> 2012/7/16 Adrian Crum <[hidden email]>
>
>> We are still discussing it, and if there are any objections I can revert
>> the commit.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>
>>> You make it sound like it is still open for debate. However, you committed
>>> this new feature to trunk. In barely under 30 hours after you started this
>>> mail thread. If you were truly seeking input from the community, you could
>>> and should have waited longer and for the outcome.
>>>
>>>
>>

[Pierre Smits]

You didn't state any conditions for reverting it.

2012/7/16 Adrian Crum <[hidden email]>

> For what reason? Is there a flaw in the design?
>
> -Adrian
>
>
> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>
>> Then I object to having it in trunk before the outcome of this discussion.
>>
>> 2012/7/16 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>> >
>>
>>  We are still discussing it, and if there are any objections I can revert
>>> the commit.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>
>>>  You make it sound like it is still open for debate. However, you
>>>> committed
>>>> this new feature to trunk. In barely under 30 hours after you started
>>>> this
>>>> mail thread. If you were truly seeking input from the community, you
>>>> could
>>>> and should have waited longer and for the outcome.
>>>>
>>>>
>>>>
>>>
>
>

[Pierre Smits]

Now go do like you said you would do. Or is your word not your bond?

2012/7/16 Pierre Smits <[hidden email]>

> You didn't state any conditions for reverting it.
>
>
> 2012/7/16 Adrian Crum <[hidden email]>
>
>> For what reason? Is there a flaw in the design?
>>
>> -Adrian
>>
>>
>> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>>
>>> Then I object to having it in trunk before the outcome of this
>>> discussion.
>>>
>>> 2012/7/16 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>> >
>>>
>>>  We are still discussing it, and if there are any objections I can revert
>>>> the commit.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>>
>>>>  You make it sound like it is still open for debate. However, you
>>>>> committed
>>>>> this new feature to trunk. In barely under 30 hours after you started
>>>>> this
>>>>> mail thread. If you were truly seeking input from the community, you
>>>>> could
>>>>> and should have waited longer and for the outcome.
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>

[Adrian Crum-3]

Please take time to understand how the community works:

http://www.apache.org/foundation/voting.html

Commits are not reverted simply because a user asks for it.

-Adrian

On 7/16/2012 12:26 PM, Pierre Smits wrote:

> Now go do like you said you would do. Or is your word not your bond?
>
> 2012/7/16 Pierre Smits <[hidden email]>
>
>> You didn't state any conditions for reverting it.
>>
>>
>> 2012/7/16 Adrian Crum <[hidden email]>
>>
>>> For what reason? Is there a flaw in the design?
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>>>
>>>> Then I object to having it in trunk before the outcome of this
>>>> discussion.
>>>>
>>>> 2012/7/16 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>>>   We are still discussing it, and if there are any objections I can revert
>>>>> the commit.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>>>
>>>>>   You make it sound like it is still open for debate. However, you
>>>>>> committed
>>>>>> this new feature to trunk. In barely under 30 hours after you started
>>>>>> this
>>>>>> mail thread. If you were truly seeking input from the community, you
>>>>>> could
>>>>>> and should have waited longer and for the outcome.
>>>>>>
>>>>>>
>>>>>>
>>>

[Jacques Le Roux]

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

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.
This could be used in BJ's spirit for larger tasks...

Jacques

From: "BJ Freeman" <[hidden email]>

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

[Pierre Smits]

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 <[hidden email]>

> 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" <[hidden email]>
>
>  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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>

[Adrian Crum-3]

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 <[hidden email]>
>
>> 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" <[hidden email]>
>>
>>   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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>

[Scott Gray-2]

No, that's exactly what this discussion is about, here let me remind you about what Ruth asked:
> Shouldn't this be discussed on the "user" list?

The mailing lists are what they are, I'm just describing the purposes that they are intended to fill.  I'm not placing myself above the community, I don't even know how to respond to that.

Regards
Scott

On 16/07/2012, at 9:59 PM, Pierre Smits wrote:

> This isn't about what the mailing lists are for.
>
> Don't try to fill in what others care about or need. But it would
> definitely help if you would be a community member first, in stead of
> placing yourself above it.
>
>
> 2012/7/16 Scott Gray <[hidden email]>
>
>> It all comes back to a general misunderstanding of the difference between
>> the user and dev lists.
>>
>> The user list is for people who are using OFBiz as a business user or
>> developing customized applications.  When these types of people have a
>> question, the user list is definitely appropriate.  They don't necessarily
>> care about the ongoing development of OFBiz itself, they need to discuss
>> how to use what has been released.
>> The dev list is for people who are interested in the ongoing development
>> of OFBiz and wish to contribute code, documentation and ideas.  If you care
>> about the future of OFBiz then this is where you come and contribute.
>>
>> No one is attempting to exclude OFBiz users from any discussions, if they
>> want to be involved in the development of OFBiz then they subscribe to the
>> dev list just like everyone else.  I feel like a broken record though, is
>> there some way that we can more clearly articulate the distinction to the
>> community?
>>
>> Regards
>> Scott
>>
>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>>
>>> 2012/7/16 Adrian Crum <[hidden email]>
>>>
>>>> No, it smells like the current goal of moving things we don't want in
>> the
>>>> main project to external projects. This type of decision-making has been
>>>> going on for years.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>> community
>>>>> should decide on this.
>>>>>
>>>>> Furthermore, the remark 'users might like a new feature, but that
>> doesn't
>>>>> mean the dev community wants it in the project' smells like measuring
>> with
>>>>> double standards; as if the meritocratic principle doesn't apply when
>> the
>>>>> committers don't want it in. Or as if changes always get in, when only
>> the
>>>>> committers want it.
>>>>>
>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>> [hidden email]>
>>>>>>
>>>>>
>>>>> Ruth,
>>>>>>
>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>> to
>>>>>> the dev list to see if it is something the dev community wants
>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from the
>> dev
>>>>>> community, then I would offer it as an add-on product and announce it
>> on
>>>>>> the user list.
>>>>>>
>>>>>> I am also a user, and the design was based on the requirement to
>> monitor
>>>>>> and control server performance. I suppose I could go to the user list
>> for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those are
>> all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>
>>>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>

[Jacques Le Roux]

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" <[hidden email]>

> 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 <[hidden email]>
>
>> 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" <[hidden email]>
>>
>>  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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>

[Pierre Smits]

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 <[hidden email]>

> 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 <[hidden email]>
>>
>>  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" <[hidden email]>
>>>
>>>   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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
>

[Jacques Le Roux]

From: "Pierre Smits" <[hidden email]>

> 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 <[hidden email]>
>
>> 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 <[hidden email]>
>>>
>>>  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" <[hidden email]>
>>>>
>>>>   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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>
>>
>

[BJ Freeman]

I am using this one since it is a long thread and I don't want to read
it all.
This is a great opportunity for someone, like yourself, to take on the
task of informing the user list of activity of the Dev list.
Those that think it of interest on the user list can join or read the
archive of the dev list.

Pierre Smits sent the following on 7/16/2012 2:11 AM:

> You mean excluding parts of the community from participating in the
> decision-taking processes?
>
> 2012/7/16 Adrian Crum<[hidden email]>
>
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>>
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>>
>>> 2012/7/15 Adrian Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>>>>
>>>
>>>   Ruth,
>>>>
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>>
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>
>>>>   Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>>
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>>
>>
>>
>

[Ruth Hoffman-2]

You guys are a hoot! I love reading this list.
Com'on BJ...this is silly. Don't be so pretentious. Adrian already
explained his point of view.
So now I wanna know: What makes you think you can assign "opportunities"
to Pierre? Or is that also part of the "meritocracy" that comes with
being a member of this community?
Best Regards,
Ruth
On 7/16/12 11:49 AM, BJ Freeman wrote:

> I am using this one since it is a long thread and I don't want to read
> it all.
> This is a great opportunity for someone, like yourself, to take on the
> task of informing the user list of activity of the Dev list.
> Those that think it of interest on the user list can join or read the
> archive of the dev list.
>
> Pierre Smits sent the following on 7/16/2012 2:11 AM:
>> You mean excluding parts of the community from participating in the
>> decision-taking processes?
>>
>> 2012/7/16 Adrian Crum<[hidden email]>
>>
>>> No, it smells like the current goal of moving things we don't want
>>> in the
>>> main project to external projects. This type of decision-making has
>>> been
>>> going on for years.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>
>>>> I agree with Ruth. This sounds like a user requirement. And the
>>>> community
>>>> should decide on this.
>>>>
>>>> Furthermore, the remark 'users might like a new feature, but that
>>>> doesn't
>>>> mean the dev community wants it in the project' smells like
>>>> measuring with
>>>> double standards; as if the meritocratic principle doesn't apply
>>>> when the
>>>> committers don't want it in. Or as if changes always get in, when
>>>> only the
>>>> committers want it.
>>>>
>>>> 2012/7/15 Adrian
>>>> Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>>>>>
>>>>
>>>>   Ruth,
>>>>>
>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>> ideas to
>>>>> the dev list to see if it is something the dev community wants
>>>>> included
>>>>> in
>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>> the
>>>>> dev
>>>>> community wants it in the project. If there was no interest from
>>>>> the dev
>>>>> community, then I would offer it as an add-on product and announce
>>>>> it on
>>>>> the user list.
>>>>>
>>>>> I am also a user, and the design was based on the requirement to
>>>>> monitor
>>>>> and control server performance. I suppose I could go to the user
>>>>> list for
>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>> users
>>>>> will be free to enhance it in whatever way they please.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>
>>>>>   Hi Adrian:
>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>> "applications" and "stats about services and entities"...those
>>>>>> are all
>>>>>> indicative of user requirements, not developer requirements.
>>>>>>
>>>>>> Users should be driving requirements gathering and analysis for
>>>>>> OFBiz
>>>>>> and
>>>>>> not developers.
>>>>>> Just my 2 cents.
>>>>>> Regards,
>>>>>> Ruth
>>>>>>
>>>>>>
>>>
>>>
>>
>

[BJ Freeman]

there must be a language barrier here.
it was a suggestion and as I prefaced, I used Pierre's since I did not
want to find the original. I could have used yours just as well.
It was if you want to get something done, do it yourself type of suggestion.
You add to the drama Ruth.
Not something I enjoy.

Ruth Hoffman sent the following on 7/16/2012 9:25 AM:

> You guys are a hoot! I love reading this list.
> Com'on BJ...this is silly. Don't be so pretentious. Adrian already
> explained his point of view.
> So now I wanna know: What makes you think you can assign "opportunities"
> to Pierre? Or is that also part of the "meritocracy" that comes with
> being a member of this community?
> Best Regards,
> Ruth
> On 7/16/12 11:49 AM, BJ Freeman wrote:
>> I am using this one since it is a long thread and I don't want to read
>> it all.
>> This is a great opportunity for someone, like yourself, to take on the
>> task of informing the user list of activity of the Dev list.
>> Those that think it of interest on the user list can join or read the
>> archive of the dev list.
>>
>> Pierre Smits sent the following on 7/16/2012 2:11 AM:
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>>
>>> 2012/7/16 Adrian Crum<[hidden email]>
>>>
>>>> No, it smells like the current goal of moving things we don't want
>>>> in the
>>>> main project to external projects. This type of decision-making has
>>>> been
>>>> going on for years.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>>>>> community
>>>>> should decide on this.
>>>>>
>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>> doesn't
>>>>> mean the dev community wants it in the project' smells like
>>>>> measuring with
>>>>> double standards; as if the meritocratic principle doesn't apply
>>>>> when the
>>>>> committers don't want it in. Or as if changes always get in, when
>>>>> only the
>>>>> committers want it.
>>>>>
>>>>> 2012/7/15 Adrian
>>>>> Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>>>>>
>>>>>>
>>>>>
>>>>> Ruth,
>>>>>>
>>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>>> ideas to
>>>>>> the dev list to see if it is something the dev community wants
>>>>>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>> the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from
>>>>>> the dev
>>>>>> community, then I would offer it as an add-on product and announce
>>>>>> it on
>>>>>> the user list.
>>>>>>
>>>>>> I am also a user, and the design was based on the requirement to
>>>>>> monitor
>>>>>> and control server performance. I suppose I could go to the user
>>>>>> list for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those
>>>>>>> are all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>
>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>> OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
>
>

[Olivier.heintz]

Le 16/07/2012 12:04, Adrian Crum a écrit :
> If anyone is placing themselves over anyone else, it is you. Scott and
> I are trying to help you understand how this community works, but you
> are not interested in being taught - you are only interested in
> railroading through your opinions.
I completely agree with Adrian and Scott, their answers are clear and
only re-explain goal of each mailing-list.

>
> -Adrian
>
> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>> This isn't about what the mailing lists are for.
>>
>> Don't try to fill in what others care about or need. But it would
>> definitely help if you would be a community member first, in stead of
>> placing yourself above it.
>>
>>
>> 2012/7/16 Scott Gray <[hidden email]>
>>
>>> It all comes back to a general misunderstanding of the difference
>>> between
>>> the user and dev lists.
>>>
>>> The user list is for people who are using OFBiz as a business user or
>>> developing customized applications.  When these types of people have a
>>> question, the user list is definitely appropriate.  They don't
>>> necessarily
>>> care about the ongoing development of OFBiz itself, they need to
>>> discuss
>>> how to use what has been released.
>>> The dev list is for people who are interested in the ongoing
>>> development
>>> of OFBiz and wish to contribute code, documentation and ideas.  If
>>> you care
>>> about the future of OFBiz then this is where you come and contribute.
>>>
>>> No one is attempting to exclude OFBiz users from any discussions, if
>>> they
>>> want to be involved in the development of OFBiz then they subscribe
>>> to the
>>> dev list just like everyone else.  I feel like a broken record
>>> though, is
>>> there some way that we can more clearly articulate the distinction
>>> to the
>>> community?
>>>
>>> Regards
>>> Scott
>>>
>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>
>>>> You mean excluding parts of the community from participating in the
>>>> decision-taking processes?
>>>>
>>>> 2012/7/16 Adrian Crum <[hidden email]>
>>>>
>>>>> No, it smells like the current goal of moving things we don't want in
>>> the
>>>>> main project to external projects. This type of decision-making
>>>>> has been
>>>>> going on for years.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>
>>>>>> I agree with Ruth. This sounds like a user requirement. And the
>>> community
>>>>>> should decide on this.
>>>>>>
>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>> doesn't
>>>>>> mean the dev community wants it in the project' smells like
>>>>>> measuring
>>> with
>>>>>> double standards; as if the meritocratic principle doesn't apply
>>>>>> when
>>> the
>>>>>> committers don't want it in. Or as if changes always get in, when
>>>>>> only
>>> the
>>>>>> committers want it.
>>>>>>
>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>>> [hidden email]>
>>>>>> Ruth,
>>>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>>>> ideas
>>> to
>>>>>>> the dev list to see if it is something the dev community wants
>>> included
>>>>>>> in
>>>>>>> the project. Users might like a new feature, but that doesn't
>>>>>>> mean the
>>>>>>> dev
>>>>>>> community wants it in the project. If there was no interest from
>>>>>>> the
>>> dev
>>>>>>> community, then I would offer it as an add-on product and
>>>>>>> announce it
>>> on
>>>>>>> the user list.
>>>>>>>
>>>>>>> I am also a user, and the design was based on the requirement to
>>> monitor
>>>>>>> and control server performance. I suppose I could go to the user
>>>>>>> list
>>> for
>>>>>>> more ideas, but the code I'm planning to commit is pretty basic,
>>>>>>> and
>>>>>>> users
>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>> Hi Adrian:
>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>> "applications" and "stats about services and entities"...those are
>>> all
>>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>>
>>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>>> OFBiz
>>>>>>>> and
>>>>>>>> not developers.
>>>>>>>> Just my 2 cents.
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
>
>