Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

Side note: geronimo just started to implement Microprofile metrics which is
a kind of copy of the dropwizard/codehale API, maybe it can be a place to
host this kind of thing too. [1] is quite close I think

[1]
https://gitbox.apache.org/repos/asf?p=geronimo-metrics.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/metrics/impl/TimerImpl.java;h=d8ac05ecef4aea726fe8d8b948e0d067ad35f455;hb=HEAD

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 11 juin 2018 à 20:35, Otto Fowler  a
écrit :

> Thanks to everyone who took that time to review.
>
> Although my preference was to contribute this utility back to commons, it
> seems like it has kind
> of spiraled into something much more, and there doesn’t seem to be a clear
> consensus.
>
> So if you think it was useful :
> you grab it now from
> https://bintray.com/palindromicity/stackwatch/stackwatch/0.0.1
> https://github.com/palindromicity/stackwatch
>
>
>
> On April 23, 2018 at 08:16:46, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote:
> > Bump
>
> More than a vote, you need someone to take on the tasks to
> create the new component.
>
> I feel that no argument were made against bringing ex-Sirona
> back to "Commons" (or contributing your code to Romain's
> Sirona fork), and I'm afraid that nothing else will be
> added to that component (or: where is the plan?).
>
> Best,
> Gilles
>
> > On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com)
> > wrote:
> >
> > There has been no comment, do we need an explicit vote?
> >
> >
> > On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com)
> > wrote:
> >
> > So do we need a vote? What is next to move this forward?
> >
> >
> > On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com)
> > wrote:
> >
> > OK, sounds fine to me. Hopefully we’ll get some buy in and can move
> > forward.
> > I’m not sure what is next though ;)
> >
> >
> >
> > On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com)
> > wrote:
> >
> > On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler
> > 
> > wrote:
> >
> >> How about commons-timing, having StopWatch, StackWatch and other
> >> classes
> >> that
> >> we can find?
> >>
> >
> > I think we start small with only what we need and have today, namely
> > these
> > two classes.
> >
> > Gary
> >
> >
> >>
> >>
> >>
> >> On March 20, 2018 at 18:40:05, Romain Manni-Bucau
> >> (rmannibu...@gmail.com)
> >> wrote:
> >>
> >> I would be happy to revive sirona @asf but dont think [monitoring]
> >> as just
> >> a few classes would bring enough value compare to a lambda not
> >> worthing
> > any
> >> lib/dep in apps - just my opinion indeed.
> >>
> >> For circuit breaker: geronimo safeguard can be interested in hosting
> >> that
> >> utility part and drop failsafe dependency. Maybe something to
> >> discuss in
> >> another thread.
> >>
> >> Le 20 mars 2018 23:27, "Otto Fowler"  a
> >> écrit :
> >>
> >> > Sirona is gone, it is a closed incubator project. Romain has
> >> forked it
> > to
> >> > his own repo.
> >> >
> >> >
> >> >
> >> > On March 20, 2018 at 18:24:06, Gilles
> >> (gil...@harfang.homelinux.org)
> >> > wrote:
> >> >
> >> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> >> > > If monitoring was started a new, and not re-viving the old
> >> > > monitoring?
> >> >
> >> > Can the feature be contributed to "Sirona"? Otto, are you
> >> > interested in this?
> >> > Does it make sense to have "Commons Monitoring" revived based
> >> > on part/all of "Sirona"?
> >> > Romain, are you interested in this?
> >> > What would be the scope/description of "Commons Monitoring"?
> >> >
> >> > Noting Romain's experience that the original "Commons" project
> >> > ev

Re: [DISCUSS] new component for timing?

[Otto Fowler]

Thanks to everyone who took that time to review.

Although my preference was to contribute this utility back to commons, it seems 
like it has kind 
of spiraled into something much more, and there doesn’t seem to be a clear 
consensus.

So if you think it was useful : 
you grab it now from 
https://bintray.com/palindromicity/stackwatch/stackwatch/0.0.1
https://github.com/palindromicity/stackwatch



On April 23, 2018 at 08:16:46, Gilles (gil...@harfang.homelinux.org) wrote:

On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote:  
> Bump  

More than a vote, you need someone to take on the tasks to  
create the new component.  

I feel that no argument were made against bringing ex-Sirona  
back to "Commons" (or contributing your code to Romain's  
Sirona fork), and I'm afraid that nothing else will be  
added to that component (or: where is the plan?).  

Best,  
Gilles  

> On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com)  
> wrote:  
>  
> There has been no comment, do we need an explicit vote?  
>  
>  
> On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com)  
> wrote:  
>  
> So do we need a vote? What is next to move this forward?  
>  
>  
> On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com)  
> wrote:  
>  
> OK, sounds fine to me. Hopefully we’ll get some buy in and can move  
> forward.  
> I’m not sure what is next though ;)  
>  
>  
>  
> On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com)  
> wrote:  
>  
> On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler  
>   
> wrote:  
>  
>> How about commons-timing, having StopWatch, StackWatch and other  
>> classes  
>> that  
>> we can find?  
>>  
>  
> I think we start small with only what we need and have today, namely  
> these  
> two classes.  
>  
> Gary  
>  
>  
>>  
>>  
>>  
>> On March 20, 2018 at 18:40:05, Romain Manni-Bucau  
>> (rmannibu...@gmail.com)  
>> wrote:  
>>  
>> I would be happy to revive sirona @asf but dont think [monitoring]  
>> as just  
>> a few classes would bring enough value compare to a lambda not  
>> worthing  
> any  
>> lib/dep in apps - just my opinion indeed.  
>>  
>> For circuit breaker: geronimo safeguard can be interested in hosting  
>> that  
>> utility part and drop failsafe dependency. Maybe something to  
>> discuss in  
>> another thread.  
>>  
>> Le 20 mars 2018 23:27, "Otto Fowler"  a  
>> écrit :  
>>  
>> > Sirona is gone, it is a closed incubator project. Romain has  
>> forked it  
> to  
>> > his own repo.  
>> >  
>> >  
>> >  
>> > On March 20, 2018 at 18:24:06, Gilles  
>> (gil...@harfang.homelinux.org)  
>> > wrote:  
>> >  
>> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:  
>> > > If monitoring was started a new, and not re-viving the old  
>> > > monitoring?  
>> >  
>> > Can the feature be contributed to "Sirona"? Otto, are you  
>> > interested in this?  
>> > Does it make sense to have "Commons Monitoring" revived based  
>> > on part/all of "Sirona"?  
>> > Romain, are you interested in this?  
>> > What would be the scope/description of "Commons Monitoring"?  
>> >  
>> > Noting Romain's experience that the original "Commons" project  
>> > evolved into "Sirona", it would be strange to start from scratch  
>> > without a plan to not follow the same route again...  
>> >  
>> > Gilles  
>> >  
>> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (  
>> > > brunodepau...@yahoo.com.br.invalid) wrote:  
>> > >  
>> > > I think StopWatch and CircuitBreakers could be moved together to  
>> the  
>> > > same  
>> > > component. However, a circuit breaker can be time-related, or  
>> not  
>> > > (e.g. a  
>> > > circuit breaker for memory size). So probably commons-timing  
>> could be  
>> > > a  
>> > > good place for StopWatch, but maybe not for circuit-breaker. But  
>> I  
>> > > think  
>> > > both could be under commons-monitoring perhaps?  
>> > >  
>> > > From: Otto Fowler   
>> > > To: Romain Manni-Bucau ; Commons  
>> Developers  
>> > > List <  
>> > > dev@commons.apache.org>  
>> > > Sent: Wednesday, 21 March 2018 10:30 AM  
>>

Re: [DISCUSS] new component for timing?

[Gilles]

On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote:

Bump


More than a vote, you need someone to take on the tasks to
create the new component.

I feel that no argument were made against bringing ex-Sirona
back to "Commons" (or contributing your code to Romain's
Sirona fork), and I'm afraid that nothing else will be
added to that component (or: where is the plan?).

Best,
Gilles

On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


There has been no comment, do we need an explicit vote?


On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) 
wrote:


On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 


wrote:

How about commons-timing, having StopWatch, StackWatch and other 
classes

that
we can find?



I think we start small with only what we need and have today, namely 
these

two classes.

Gary






On March 20, 2018 at 18:40:05, Romain Manni-Bucau 
(rmannibu...@gmail.com)

wrote:

I would be happy to revive sirona @asf but dont think [monitoring] 
as just
a few classes would bring enough value compare to a lambda not 
worthing

any

lib/dep in apps - just my opinion indeed.

For circuit breaker: geronimo safeguard can be interested in hosting 
that
utility part and drop failsafe dependency. Maybe something to 
discuss in

another thread.

Le 20 mars 2018 23:27, "Otto Fowler"  a 
écrit :


> Sirona is gone, it is a closed incubator project. Romain has 
forked it

to

> his own repo.
>
>
>
> On March 20, 2018 at 18:24:06, Gilles 
(gil...@harfang.homelinux.org)

> wrote:
>
> On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > If monitoring was started a new, and not re-viving the old
> > monitoring?
>
> Can the feature be contributed to "Sirona"? Otto, are you
> interested in this?
> Does it make sense to have "Commons Monitoring" revived based
> on part/all of "Sirona"?
> Romain, are you interested in this?
> What would be the scope/description of "Commons Monitoring"?
>
> Noting Romain's experience that the original "Commons" project
> evolved into "Sirona", it would be strange to start from scratch
> without a plan to not follow the same route again...
>
> Gilles
>
> > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > brunodepau...@yahoo.com.br.invalid) wrote:
> >
> > I think StopWatch and CircuitBreakers could be moved together to 
the

> > same
> > component. However, a circuit breaker can be time-related, or 
not

> > (e.g. a
> > circuit breaker for memory size). So probably commons-timing 
could be

> > a
> > good place for StopWatch, but maybe not for circuit-breaker. But 
I

> > think
> > both could be under commons-monitoring perhaps?
> >
> > From: Otto Fowler 
> > To: Romain Manni-Bucau ; Commons 
Developers

> > List <
> > dev@commons.apache.org>
> > Sent: Wednesday, 21 March 2018 10:30 AM
> > Subject: Re: [DISCUSS] new component for timing?
> >
> > I would love to get this on track. I apologize if I have made it
> > more
> > confusing than it needs to be,
> > I’m trying to be open to all the suggestions.
> >
> > If we assume that stack watch is worth ‘having’, then the 
question is

> > where
> > to put it.
> > commons-monitoring / sirota seems to me to be a ‘complete’ 
solution

> > as
> > opposed to
> > a set of or collection of like classes.
> >
> > Setting the community support / project aspect of sirota aside, 
it

> > seems
> > strange to put
> > a separate class into a more complete and uniform system. Unless
> > there is
> > some generically
> > useful set of timing utility classes that could be taken out of
> > sirota to
> > go into commons-,
> > along with things identified ( StopWatch?) out of commons lang 
and

> > possibly
> > other commons projects.
> >
> > commons-timing seems reasonable. Thoughts?
> >
> >
> >
> > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > (rmannibu...@gmail.com)
> > wrote:
> >
> > Yes but consequence was a lack of community increase which is a
> > killer for
> > an incubator project on the long run.
> >
> > Le 17 mars 2018 15:19, "Gilles"  a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, R

Re: [DISCUSS] new component for timing?

[Otto Fowler]

Bump


On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com) wrote:

There has been no comment, do we need an explicit vote?


On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as just
> a few classes would bring enough value compare to a lambda not worthing
any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it
to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :

Re: [DISCUSS] new component for timing?

[Otto Fowler]

There has been no comment, do we need an explicit vote?


On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as just
> a few classes would bring enough value compare to a lambda not worthing
any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it
to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain 

Re: [DISCUSS] new component for timing?

[Otto Fowler]

So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as just
> a few classes would bring enough value compare to a lambda not worthing
any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it
to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles"  a
> > >>> éc

Re: [DISCUSS] new component for timing?

[Otto Fowler]

OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as
just
> a few classes would bring enough value compare to a lambda not worthing
any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it
to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles"  a
> > >>> écrit :
> > >>>
> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> > >>>

Re: [DISCUSS] new component for timing?

[Gary Gregory]

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as just
> a few classes would bring enough value compare to a lambda not worthing any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles"  a
> > >>> écrit :
> > >>>
> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
> > >>>>
> > >>>> If we can come to consensus on the way forward, I’ll be happy to
> > >>&

Re: [DISCUSS] new component for timing?

[Otto Fowler]

How about commons-timing, having StopWatch, StackWatch and other classes
that
we can find?



On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

I would be happy to revive sirona @asf but dont think [monitoring] as just
a few classes would bring enough value compare to a lambda not worthing any
lib/dep in apps - just my opinion indeed.

For circuit breaker: geronimo safeguard can be interested in hosting that
utility part and drop failsafe dependency. Maybe something to discuss in
another thread.

Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :

> Sirona is gone, it is a closed incubator project. Romain has forked it to
> his own repo.
>
>
>
> On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > If monitoring was started a new, and not re-viving the old
> > monitoring?
>
> Can the feature be contributed to "Sirona"? Otto, are you
> interested in this?
> Does it make sense to have "Commons Monitoring" revived based
> on part/all of "Sirona"?
> Romain, are you interested in this?
> What would be the scope/description of "Commons Monitoring"?
>
> Noting Romain's experience that the original "Commons" project
> evolved into "Sirona", it would be strange to start from scratch
> without a plan to not follow the same route again...
>
> Gilles
>
> > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > brunodepau...@yahoo.com.br.invalid) wrote:
> >
> > I think StopWatch and CircuitBreakers could be moved together to the
> > same
> > component. However, a circuit breaker can be time-related, or not
> > (e.g. a
> > circuit breaker for memory size). So probably commons-timing could be
> > a
> > good place for StopWatch, but maybe not for circuit-breaker. But I
> > think
> > both could be under commons-monitoring perhaps?
> >
> > From: Otto Fowler 
> > To: Romain Manni-Bucau ; Commons Developers
> > List <
> > dev@commons.apache.org>
> > Sent: Wednesday, 21 March 2018 10:30 AM
> > Subject: Re: [DISCUSS] new component for timing?
> >
> > I would love to get this on track. I apologize if I have made it
> > more
> > confusing than it needs to be,
> > I’m trying to be open to all the suggestions.
> >
> > If we assume that stack watch is worth ‘having’, then the question is
> > where
> > to put it.
> > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > as
> > opposed to
> > a set of or collection of like classes.
> >
> > Setting the community support / project aspect of sirota aside, it
> > seems
> > strange to put
> > a separate class into a more complete and uniform system. Unless
> > there is
> > some generically
> > useful set of timing utility classes that could be taken out of
> > sirota to
> > go into commons-,
> > along with things identified ( StopWatch?) out of commons lang and
> > possibly
> > other commons projects.
> >
> > commons-timing seems reasonable. Thoughts?
> >
> >
> >
> > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > (rmannibu...@gmail.com)
> > wrote:
> >
> > Yes but consequence was a lack of community increase which is a
> > killer for
> > an incubator project on the long run.
> >
> > Le 17 mars 2018 15:19, "Gilles"  a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles"  a
> >>> écrit :
> >>>
> >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
> >>>>
> >>>> If we can come to consensus on the way forward, I’ll be happy to
> >>>> do the
> >>>>
> >>>>> work ( although I’ll need help of course ).
> >>>>> I guess I’m the straw that broke the camel’s back then? ;)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On March 15, 2018 at 08:09:45, Gilles
> >>>>> (gil...@harfang.homelinux.org)
> >>>>> wrote:
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> >>>>> > I think bringing back commons-monitoring/sirota would only be
> >>>>

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

I would be happy to revive sirona @asf but dont think [monitoring] as just
a few classes would bring enough value compare to a lambda not worthing any
lib/dep in apps - just my opinion indeed.

For circuit breaker: geronimo safeguard can be interested in hosting that
utility part and drop failsafe dependency. Maybe something to discuss in
another thread.

Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :

> Sirona is gone, it is a closed incubator project.  Romain has forked it to
> his own repo.
>
>
>
> On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > If monitoring was started a new, and not re-viving the old
> > monitoring?
>
> Can the feature be contributed to "Sirona"? Otto, are you
> interested in this?
> Does it make sense to have "Commons Monitoring" revived based
> on part/all of "Sirona"?
> Romain, are you interested in this?
> What would be the scope/description of "Commons Monitoring"?
>
> Noting Romain's experience that the original "Commons" project
> evolved into "Sirona", it would be strange to start from scratch
> without a plan to not follow the same route again...
>
> Gilles
>
> > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > brunodepau...@yahoo.com.br.invalid) wrote:
> >
> > I think StopWatch and CircuitBreakers could be moved together to the
> > same
> > component. However, a circuit breaker can be time-related, or not
> > (e.g. a
> > circuit breaker for memory size). So probably commons-timing could be
> > a
> > good place for StopWatch, but maybe not for circuit-breaker. But I
> > think
> > both could be under commons-monitoring perhaps?
> >
> > From: Otto Fowler 
> > To: Romain Manni-Bucau ; Commons Developers
> > List <
> > dev@commons.apache.org>
> > Sent: Wednesday, 21 March 2018 10:30 AM
> > Subject: Re: [DISCUSS] new component for timing?
> >
> > I would love to get this on track. I apologize if I have made it
> > more
> > confusing than it needs to be,
> > I’m trying to be open to all the suggestions.
> >
> > If we assume that stack watch is worth ‘having’, then the question is
> > where
> > to put it.
> > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > as
> > opposed to
> > a set of or collection of like classes.
> >
> > Setting the community support / project aspect of sirota aside, it
> > seems
> > strange to put
> > a separate class into a more complete and uniform system. Unless
> > there is
> > some generically
> > useful set of timing utility classes that could be taken out of
> > sirota to
> > go into commons-,
> > along with things identified ( StopWatch?) out of commons lang and
> > possibly
> > other commons projects.
> >
> > commons-timing seems reasonable. Thoughts?
> >
> >
> >
> > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > (rmannibu...@gmail.com)
> > wrote:
> >
> > Yes but consequence was a lack of community increase which is a
> > killer for
> > an incubator project on the long run.
> >
> > Le 17 mars 2018 15:19, "Gilles"  a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles"  a
> >>> écrit :
> >>>
> >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
> >>>>
> >>>> If we can come to consensus on the way forward, I’ll be happy to
> >>>> do the
> >>>>
> >>>>> work ( although I’ll need help of course ).
> >>>>> I guess I’m the straw that broke the camel’s back then? ;)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On March 15, 2018 at 08:09:45, Gilles
> >>>>> (gil...@harfang.homelinux.org)
> >>>>> wrote:
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> >>>>> > I think bringing back commons-monitoring/sirota would only be
> >>>>> > possible if
> >>>>> > it were to be modular enough that you could bring in the ‘core’
> >>>>> > classes
> >>>

Re: [DISCUSS] new component for timing?

[Gilles]

On Tue, 20 Mar 2018 15:27:45 -0700, Otto Fowler wrote:
Sirona is gone, it is a closed incubator project.  Romain has forked 
it to

his own repo.


The code is there; the rationale is the same: some functionality
started "here" and got "there".
Is anyone interested to get (part of) it back "here"?

Gilles

On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org) 
wrote:


On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:

If monitoring was started a new, and not re-viving the old
monitoring?


Can the feature be contributed to "Sirona"? Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the
same
component. However, a circuit breaker can be time-related, or not
(e.g. a
circuit breaker for memory size). So probably commons-timing could 
be

a
good place for StopWatch, but maybe not for circuit-breaker. But I
think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers
List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track. I apologize if I have made it
more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question 
is

where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution
as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it
seems
strange to put
a separate class into a more complete and uniform system. Unless
there is
some generically
useful set of timing utility classes that could be taken out of
sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and
possibly
other commons projects.

commons-timing seems reasonable. Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau
(rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a
killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a
écrit :


On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:


Le 17 mars 2018 11:49, "Gilles"  a
écrit :

On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

2018-03-15 14:36 GMT+01:00 Otto Fowler :


If we can come to consensus on the way forward, I’ll be happy to
do the


work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)




On March 15, 2018 at 08:09:45, Gilles
(gil...@harfang.homelinux.org)
wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the 
‘core’

> classes
> without needing to bring in all of what sirota ended up being,
which
> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]


Sirona was done modular, just the API, the in memory part, 
etc...

But this kind of impl needs way more just after so not sure it
does

worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons
instead

of
creating a community @incubator with an E2E solution? This is 
what

I

fail

to see.
My experience - coming exactly from here - tends to make me think

commons

will not fit very long or will not bring enough value pretty
quickly

but

that's just my opinion.



Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate. Unless we learn
1. why the precursor needed to become TLP, and
2. why the TLP didn't succeed,
we'd go in circles.


We failed at community@asf and pby communication/promotion levels 
I

think.
Other parts were successful (prod etc).



[It seems that part of your message went missing.]

Lack of marketing skills should not entail failure, especially
not since communication is a transverse concern.

Gilles

Would it make sense that Sirona becomes (again?) "Commons
Monitoring"?

Does the "StackWatck" (Otto's contribution that started this
discussion)
already exist in a Sirona module? If not, can it be done, so that
usage
is sim

Re: [DISCUSS] new component for timing?

[Otto Fowler]

Sirona is gone, it is a closed incubator project.  Romain has forked it to
his own repo.



On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org) wrote:

On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> If monitoring was started a new, and not re-viving the old
> monitoring?

Can the feature be contributed to "Sirona"? Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles

> On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> brunodepau...@yahoo.com.br.invalid) wrote:
>
> I think StopWatch and CircuitBreakers could be moved together to the
> same
> component. However, a circuit breaker can be time-related, or not
> (e.g. a
> circuit breaker for memory size). So probably commons-timing could be
> a
> good place for StopWatch, but maybe not for circuit-breaker. But I
> think
> both could be under commons-monitoring perhaps?
>
> From: Otto Fowler 
> To: Romain Manni-Bucau ; Commons Developers
> List <
> dev@commons.apache.org>
> Sent: Wednesday, 21 March 2018 10:30 AM
> Subject: Re: [DISCUSS] new component for timing?
>
> I would love to get this on track. I apologize if I have made it
> more
> confusing than it needs to be,
> I’m trying to be open to all the suggestions.
>
> If we assume that stack watch is worth ‘having’, then the question is
> where
> to put it.
> commons-monitoring / sirota seems to me to be a ‘complete’ solution
> as
> opposed to
> a set of or collection of like classes.
>
> Setting the community support / project aspect of sirota aside, it
> seems
> strange to put
> a separate class into a more complete and uniform system. Unless
> there is
> some generically
> useful set of timing utility classes that could be taken out of
> sirota to
> go into commons-,
> along with things identified ( StopWatch?) out of commons lang and
> possibly
> other commons projects.
>
> commons-timing seems reasonable. Thoughts?
>
>
>
> On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> (rmannibu...@gmail.com)
> wrote:
>
> Yes but consequence was a lack of community increase which is a
> killer for
> an incubator project on the long run.
>
> Le 17 mars 2018 15:19, "Gilles"  a
> écrit :
>
>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>
>>> Le 17 mars 2018 11:49, "Gilles"  a
>>> écrit :
>>>
>>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>>
>>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>>
>>>> If we can come to consensus on the way forward, I’ll be happy to
>>>> do the
>>>>
>>>>> work ( although I’ll need help of course ).
>>>>> I guess I’m the straw that broke the camel’s back then? ;)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On March 15, 2018 at 08:09:45, Gilles
>>>>> (gil...@harfang.homelinux.org)
>>>>> wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
>>>>> > I think bringing back commons-monitoring/sirota would only be
>>>>> > possible if
>>>>> > it were to be modular enough that you could bring in the ‘core’
>>>>> > classes
>>>>> > without needing to bring in all of what sirota ended up being,
>>>>> which
>>>>> > was an
>>>>> > end to end solution.
>>>>>
>>>>> Isn't it possible? [I didn't look; Romain should tell whether he
>>>>> would be interested in taking that route.]
>>>>>
>>>>>
>>>>> Sirona was done modular, just the API, the in memory part, etc...
>>>> But this kind of impl needs way more just after so not sure it
>>>> does
> worth
>>>> splitting it to put it back altogether after.
>>>>
>>>> What is the rational to try to push a very small part @commons
>>>> instead
> of
>>>> creating a community @incubator with an E2E solution? This is what
>>>> I
> fail
>>>> to see.
>>>> My experience - coming exactly from here

Re: [DISCUSS] new component for timing?

[Gilles]

On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
If monitoring was started a new, and not re-viving the old 
monitoring?


Can the feature be contributed to "Sirona"?  Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the 
same
component. However, a circuit breaker can be time-related, or not 
(e.g. a
circuit breaker for memory size). So probably commons-timing could be 
a
good place for StopWatch, but maybe not for circuit-breaker. But I 
think

both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers 
List <

dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it 
more

confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is 
where

to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution 
as

opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it 
seems

strange to put
a separate class into a more complete and uniform system.  Unless 
there is

some generically
useful set of timing utility classes that could be taken out of 
sirota to

go into commons-,
along with things identified ( StopWatch?) out of commons lang and 
possibly

other commons projects.

commons-timing seems reasonable.  Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau 
(rmannibu...@gmail.com)

wrote:

Yes but consequence was a lack of community increase which is a 
killer for

an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a 
écrit :



On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:

Le 17 mars 2018 11:49, "Gilles"  a 
écrit :


On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

2018-03-15 14:36 GMT+01:00 Otto Fowler :


If we can come to consensus on the way forward, I’ll be happy to 
do the



work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)




On March 15, 2018 at 08:09:45, Gilles 
(gil...@harfang.homelinux.org)

wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the ‘core’
> classes
> without needing to bring in all of what sirota ended up being, 
which

> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]


Sirona was done modular, just the API, the in memory part, etc...
But this kind of impl needs way more just after so not sure it 
does

worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons 
instead

of
creating a community @incubator with an E2E solution? This is what 
I

fail

to see.
My experience - coming exactly from here - tends to make me think

commons
will not fit very long or will not bring enough value pretty 
quickly

but

that's just my opinion.



Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate. Unless we learn
1. why the precursor needed to become TLP, and
2. why the TLP didn't succeed,
we'd go in circles.


We failed at community@asf and pby communication/promotion levels I
think.
Other parts were successful (prod etc).



[It seems that part of your message went missing.]

Lack of marketing skills should not entail failure, especially
not since communication is a transverse concern.

Gilles

Would it make sense that Sirona becomes (again?) "Commons 
Monitoring"?
Does the "StackWatck" (Otto's contribution that started this 
discussion)
already exist in a Sirona module? If not, can it be done, so that 
usage

is similar to what Otto had in mind?

Regards,
Gilles


commons-monitoring or commons-timing seem to be the correct thing



> however,
> but I would like to think that there would be more impetus

I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather

Re: [DISCUSS] new component for timing?

[Bruno P. Kinoshita]

Not sure. I'm not familiar with sirona/commons-monitoring.
Sirona seems to already have a StopWatch, and looks like there's some users 
already? No strong opinion here, so happy with either of these.


  From: Otto Fowler 
 To: Romain Manni-Bucau ; Bruno P. Kinoshita 
; Commons Developers List 
 
 Sent: Wednesday, 21 March 2018 11:00 AM
 Subject: Re: [DISCUSS] new component for timing?
  
If monitoring was started a new, and not re-viving the old monitoring?


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the same
component. However, a circuit breaker can be time-related, or not (e.g. a
circuit breaker for memory size). So probably commons-timing could be a
good place for StopWatch, but maybe not for circuit-breaker. But I think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
>>>> work ( although I’ll need help of course ).
>>>> I guess I’m the straw that broke the camel’s back then? ;)
>>>>
>>>>
>>>>
>>>>
>>>> On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
>>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
>>>> > I think bringing back commons-monitoring/sirota would only be
>>>> > possible if
>>>> > it were to be modular enough that you could bring in the ‘core’
>>>> > classes
>>>> > without needing to bring in all of what sirota ended up being, which
>>>> > was an
>>>> > end to end solution.
>>>>
>>>> Isn't it possible? [I didn't look; Romain should tell whether he
>>>> would be interested in taking that route.]
>>>>
>>>>
>>>> Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monito

Re: [DISCUSS] new component for timing?

[Otto Fowler]

If monitoring was started a new, and not re-viving the old monitoring?


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the same
component. However, a circuit breaker can be time-related, or not (e.g. a
circuit breaker for memory size). So probably commons-timing could be a
good place for StopWatch, but maybe not for circuit-breaker. But I think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
>>>> work ( although I’ll need help of course ).
>>>> I guess I’m the straw that broke the camel’s back then? ;)
>>>>
>>>>
>>>>
>>>>
>>>> On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
>>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
>>>> > I think bringing back commons-monitoring/sirota would only be
>>>> > possible if
>>>> > it were to be modular enough that you could bring in the ‘core’
>>>> > classes
>>>> > without needing to bring in all of what sirota ended up being, which
>>>> > was an
>>>> > end to end solution.
>>>>
>>>> Isn't it possible? [I didn't look; Romain should tell whether he
>>>> would be interested in taking that route.]
>>>>
>>>>
>>>> Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
>>>> >

Re: [DISCUSS] new component for timing?

[Bruno P. Kinoshita]

I think StopWatch and CircuitBreakers could be moved together to the same 
component. However, a circuit breaker can be time-related, or not (e.g. a 
circuit breaker for memory size). So probably commons-timing could be a good 
place for StopWatch, but maybe not for circuit-breaker. But I think both could 
be under commons-monitoring perhaps?

  From: Otto Fowler 
 To: Romain Manni-Bucau ; Commons Developers List 
 
 Sent: Wednesday, 21 March 2018 10:30 AM
 Subject: Re: [DISCUSS] new component for timing?
   
I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
>>>> work ( although I’ll need help of course ).
>>>> I guess I’m the straw that broke the camel’s back then? ;)
>>>>
>>>>
>>>>
>>>>
>>>> On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
>>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
>>>> > I think bringing back commons-monitoring/sirota would only be
>>>> > possible if
>>>> > it were to be modular enough that you could bring in the ‘core’
>>>> > classes
>>>> > without needing to bring in all of what sirota ended up being, which
>>>> > was an
>>>> > end to end solution.
>>>>
>>>> Isn't it possible? [I didn't look; Romain should tell whether he
>>>> would be interested in taking that route.]
>>>>
>>>>
>>>> Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
>>>> > however,
>>>> > but I would like to think that there would be more impetus
>>>>
>>>> I'm afraid that it's rather the lack of manpowe

Re: [DISCUSS] new component for timing?

[Otto Fowler]

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?



On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)




 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]


 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the lack of manpower.
 [And my inner conviction is that that state of things often
 led to rush to cramming more code into existing components,
 rather than "distribute" more uniformly according to subject
 matters. When scarce human resources ("community") disappear,
 cruft accumulates, sometimes up to stifle clean-up, maintenance,
 improvement, and even development.]

 > to do this than
 > thinking StackWatch is ‘too big’ for lang.time.

 It isn't any more than many other functionalities that were
 introduced but shouldn't have been.
 Depending on what the "Commons" PMC wants to favour ("code"
 *or* "community"?), the choice is between continuing with the
 accumulation, or back-pedaling through the creation of as
 many *real* components as they are developers willing to
 maintain them.

 > It really isn’t that complicated a thing.

 Sure.
 The issue is somewhere else.
 Note that, personally, I hadn't imagined that there would
 be an issue for regular developers of [Lang] (or I wouldn't
 have spent time reviewing the "details" ;-).
 But I of course agree that the question should be asked; the
 more so that, with [Math], we've a striking example of what
 awaits a library that lacks boundary checks and explic

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)




 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]


 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead of
>>> creating a community @incubator with an E2E solution? This is what I fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think commons
>>> will not fit very long or will not bring enough value pretty quickly but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate.  Unless we learn
>>  1. why the precursor needed to become TLP, and
>>  2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module?  If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the lack of manpower.
 [And my inner conviction is that that state of things often
 led to rush to cramming more code into existing components,
 rather than "distribute" more uniformly according to subject
 matters. When scarce human resources ("community") disappear,
 cruft accumulates, sometimes up to stifle clean-up, maintenance,
 improvement, and even development.]

 > to do this than
 > thinking StackWatch is ‘too big’ for lang.time.

 It isn't any more than many other functionalities that were
 introduced but shouldn't have been.
 Depending on what the "Commons" PMC wants to favour ("code"
 *or* "community"?), the choice is between continuing with the
 accumulation, or back-pedaling through the creation of as
 many *real* components as they are developers willing to
 maintain them.

 > It really isn’t that complicated a thing.

 Sure.
 The issue is somewhere else.
 Note that, personally, I hadn't imagined that there would
 be an issue for regular developers of [Lang] (or I wouldn't
 have spent time reviewing the "details" ;-).
 But I of course agree that the question should be asked; the
 more so that, with [Math], we've a striking example of what
 awaits a library that lacks boundary checks and explicit
 road map.

 Regards,
 Gilles

 > On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
 > wrote:
 >
 > On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
 >> -1 to "commons-misc". It feels to me like a copout and unfocused
 >> like
 >> SomethingUtils.
 >> We need a proper home.
 >
 > +1
 >
 >> How about the idea of commons-measure.
 >
 > Just because the first feature would happen to be a timer?
 > What other content do you foresee?
 >
 >> Then there
 >> still the idea of resurrecting other Apache projects. Kind of going
 >> in
 >> circles...
 >
 > Indeed, IIRC the questions were asked (whether the feature could
 > be contributed to ex-Sirona and whether that project would be
 > repatriated to "Commons") but not 

Re: [DISCUSS] new component for timing?

[Gilles]

On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
Le 17 mars 2018 11:49, "Gilles"  a 
écrit :


On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:


2018-03-15 14:36 GMT+01:00 Otto Fowler :

If we can come to consensus on the way forward, I’ll be happy to do 
the

work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)




On March 15, 2018 at 08:09:45, Gilles 
(gil...@harfang.homelinux.org)

wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the ‘core’
> classes
> without needing to bring in all of what sirota ended up being, 
which

> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]



Sirona was done modular, just the API, the in memory part, etc...
But this kind of impl needs way more just after so not sure it does 
worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons 
instead of
creating a community @incubator with an E2E solution? This is what I 
fail

to see.
My experience - coming exactly from here - tends to make me think 
commons
will not fit very long or will not bring enough value pretty quickly 
but

that's just my opinion.



Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate.  Unless we learn
 1. why the precursor needed to become TLP, and
 2. why the TLP didn't succeed,
we'd go in circles.


We failed at community@asf and pby communication/promotion levels I 
think.

Other parts were successful (prod etc).



[It seems that part of your message went missing.]

Lack of marketing skills should not entail failure, especially
not since communication is a transverse concern.

Gilles

Would it make sense that Sirona becomes (again?) "Commons 
Monitoring"?
Does the "StackWatck" (Otto's contribution that started this 
discussion)
already exist in a Sirona module?  If not, can it be done, so that 
usage

is similar to what Otto had in mind?

Regards,
Gilles



commons-monitoring or commons-timing seem to be the correct thing

> however,
> but I would like to think that there would be more impetus

I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather than "distribute" more uniformly according to subject
matters. When scarce human resources ("community") disappear,
cruft accumulates, sometimes up to stifle clean-up, maintenance,
improvement, and even development.]

> to do this than
> thinking StackWatch is ‘too big’ for lang.time.

It isn't any more than many other functionalities that were
introduced but shouldn't have been.
Depending on what the "Commons" PMC wants to favour ("code"
*or* "community"?), the choice is between continuing with the
accumulation, or back-pedaling through the creation of as
many *real* components as they are developers willing to
maintain them.

> It really isn’t that complicated a thing.

Sure.
The issue is somewhere else.
Note that, personally, I hadn't imagined that there would
be an issue for regular developers of [Lang] (or I wouldn't
have spent time reviewing the "details" ;-).
But I of course agree that the question should be asked; the
more so that, with [Math], we've a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

> On March 8, 2018 at 11:50:17, Gilles 
(gil...@harfang.homelinux.org)

> wrote:
>
> On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
>> -1 to "commons-misc". It feels to me like a copout and unfocused
>> like
>> SomethingUtils.
>> We need a proper home.
>
> +1
>
>> How about the idea of commons-measure.
>
> Just because the first feature would happen to be a timer?
> What other content do you foresee?
>
>> Then there
>> still the idea of resurrecting other Apache projects. Kind of 
going

>> in
>> circles...
>
> Indeed, IIRC the questions were asked (whether the feature could
> be contributed to ex-Sirona and whether that project would be
> repatriated to "Commons") but not answered (unless I'm 
mistaken)...

>
> Best,
> Gilles
>
>
>> Gary
>>
>> On Mar 8, 2018 08:58, "Otto Fowler"  
wrote:

>>
>> So, could think about commons-misc or something?
>> I don’t think we are going to come up with a perfect module for
>> these
>> things.
>>
>> Maybe the way it can work is:
>>
>> commons-misc exists.
>>
>> It is the landing place for things that seem to be outside the 
scope

>> of
>> commons-, but don’t justify
>> a new module or sandbox effort.
>>
>> Things in misc can be reevaluated for inclusion in new modules 
at

>> things
>> go, and at that point @Depricated
>> out of misc.
>>
>> ?
>>
>>
>>
>> On March 3, 2018 at 00:42:12, Matt Sicker (boa.

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

Le 17 mars 2018 11:49, "Gilles"  a écrit :

On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>
> If we can come to consensus on the way forward, I’ll be happy to do the
>> work ( although I’ll need help of course ).
>> I guess I’m the straw that broke the camel’s back then? ;)
>>
>>
>>
>>
>> On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
>> wrote:
>>
>> Hi.
>>
>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
>> > I think bringing back commons-monitoring/sirota would only be
>> > possible if
>> > it were to be modular enough that you could bring in the ‘core’
>> > classes
>> > without needing to bring in all of what sirota ended up being, which
>> > was an
>> > end to end solution.
>>
>> Isn't it possible? [I didn't look; Romain should tell whether he
>> would be interested in taking that route.]
>>
>>
> Sirona was done modular, just the API, the in memory part, etc...
> But this kind of impl needs way more just after so not sure it does worth
> splitting it to put it back altogether after.
>
> What is the rational to try to push a very small part @commons instead of
> creating a community @incubator with an E2E solution? This is what I fail
> to see.
> My experience - coming exactly from here - tends to make me think commons
> will not fit very long or will not bring enough value pretty quickly but
> that's just my opinion.
>

Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate.  Unless we learn
 1. why the precursor needed to become TLP, and
 2. why the TLP didn't succeed,
we'd go in circles.


We failed at community@asf and pby communication/promotion levels I think.
Other parts were successful (prod etc).



Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
Does the "StackWatck" (Otto's contribution that started this discussion)
already exist in a Sirona module?  If not, can it be done, so that usage
is similar to what Otto had in mind?

Regards,
Gilles


> commons-monitoring or commons-timing seem to be the correct thing
>> > however,
>> > but I would like to think that there would be more impetus
>>
>> I'm afraid that it's rather the lack of manpower.
>> [And my inner conviction is that that state of things often
>> led to rush to cramming more code into existing components,
>> rather than "distribute" more uniformly according to subject
>> matters. When scarce human resources ("community") disappear,
>> cruft accumulates, sometimes up to stifle clean-up, maintenance,
>> improvement, and even development.]
>>
>> > to do this than
>> > thinking StackWatch is ‘too big’ for lang.time.
>>
>> It isn't any more than many other functionalities that were
>> introduced but shouldn't have been.
>> Depending on what the "Commons" PMC wants to favour ("code"
>> *or* "community"?), the choice is between continuing with the
>> accumulation, or back-pedaling through the creation of as
>> many *real* components as they are developers willing to
>> maintain them.
>>
>> > It really isn’t that complicated a thing.
>>
>> Sure.
>> The issue is somewhere else.
>> Note that, personally, I hadn't imagined that there would
>> be an issue for regular developers of [Lang] (or I wouldn't
>> have spent time reviewing the "details" ;-).
>> But I of course agree that the question should be asked; the
>> more so that, with [Math], we've a striking example of what
>> awaits a library that lacks boundary checks and explicit
>> road map.
>>
>> Regards,
>> Gilles
>>
>> > On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
>> > wrote:
>> >
>> > On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
>> >> -1 to "commons-misc". It feels to me like a copout and unfocused
>> >> like
>> >> SomethingUtils.
>> >> We need a proper home.
>> >
>> > +1
>> >
>> >> How about the idea of commons-measure.
>> >
>> > Just because the first feature would happen to be a timer?
>> > What other content do you foresee?
>> >
>> >> Then there
>> >> still the idea of resurrecting other Apache projects. Kind of going
>> >> in
>> >> circles...
>> >
>> > Indeed, IIRC the questions were asked (whether the feature could
>> > be contributed to ex-Sirona and whether that project would be
>> > repatriated to "Commons") but not answered (unless I'm mistaken)...
>> >
>> > Best,
>> > Gilles
>> >
>> >
>> >> Gary
>> >>
>> >> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
>> >>
>> >> So, could think about commons-misc or something?
>> >> I don’t think we are going to come up with a perfect module for
>> >> these
>> >> things.
>> >>
>> >> Maybe the way it can work is:
>> >>
>> >> commons-misc exists.
>> >>
>> >> It is the landing place for things that seem to be outside the scope
>> >> of
>> >> commons-, but don’t justify
>> >> a new module or sandbox effort.
>> >>
>> >> Things in misc can be reevaluated for inclusion in new modules at
>> >> things
>> >> go, and at that point @Depricated
>> >> out of m

Re: [DISCUSS] new component for timing?

[Gilles]

On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

2018-03-15 14:36 GMT+01:00 Otto Fowler :

If we can come to consensus on the way forward, I’ll be happy to do 
the

work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)




On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the ‘core’
> classes
> without needing to bring in all of what sirota ended up being, 
which

> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]



Sirona was done modular, just the API, the in memory part, etc...
But this kind of impl needs way more just after so not sure it does 
worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons 
instead of
creating a community @incubator with an E2E solution? This is what I 
fail

to see.
My experience - coming exactly from here - tends to make me think 
commons
will not fit very long or will not bring enough value pretty quickly 
but

that's just my opinion.


Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate.  Unless we learn
 1. why the precursor needed to become TLP, and
 2. why the TLP didn't succeed,
we'd go in circles.

Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
Does the "StackWatck" (Otto's contribution that started this 
discussion)
already exist in a Sirona module?  If not, can it be done, so that 
usage

is similar to what Otto had in mind?

Regards,
Gilles


> commons-monitoring or commons-timing seem to be the correct thing
> however,
> but I would like to think that there would be more impetus

I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather than "distribute" more uniformly according to subject
matters. When scarce human resources ("community") disappear,
cruft accumulates, sometimes up to stifle clean-up, maintenance,
improvement, and even development.]

> to do this than
> thinking StackWatch is ‘too big’ for lang.time.

It isn't any more than many other functionalities that were
introduced but shouldn't have been.
Depending on what the "Commons" PMC wants to favour ("code"
*or* "community"?), the choice is between continuing with the
accumulation, or back-pedaling through the creation of as
many *real* components as they are developers willing to
maintain them.

> It really isn’t that complicated a thing.

Sure.
The issue is somewhere else.
Note that, personally, I hadn't imagined that there would
be an issue for regular developers of [Lang] (or I wouldn't
have spent time reviewing the "details" ;-).
But I of course agree that the question should be asked; the
more so that, with [Math], we've a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

> On March 8, 2018 at 11:50:17, Gilles 
(gil...@harfang.homelinux.org)

> wrote:
>
> On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
>> -1 to "commons-misc". It feels to me like a copout and unfocused
>> like
>> SomethingUtils.
>> We need a proper home.
>
> +1
>
>> How about the idea of commons-measure.
>
> Just because the first feature would happen to be a timer?
> What other content do you foresee?
>
>> Then there
>> still the idea of resurrecting other Apache projects. Kind of 
going

>> in
>> circles...
>
> Indeed, IIRC the questions were asked (whether the feature could
> be contributed to ex-Sirona and whether that project would be
> repatriated to "Commons") but not answered (unless I'm 
mistaken)...

>
> Best,
> Gilles
>
>
>> Gary
>>
>> On Mar 8, 2018 08:58, "Otto Fowler"  
wrote:

>>
>> So, could think about commons-misc or something?
>> I don’t think we are going to come up with a perfect module for
>> these
>> things.
>>
>> Maybe the way it can work is:
>>
>> commons-misc exists.
>>
>> It is the landing place for things that seem to be outside the 
scope

>> of
>> commons-, but don’t justify
>> a new module or sandbox effort.
>>
>> Things in misc can be reevaluated for inclusion in new modules at
>> things
>> go, and at that point @Depricated
>> out of misc.
>>
>> ?
>>
>>
>>
>> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) 
wrote:

>>
>> On 2 March 2018 at 13:31, Oliver Heger
>> 
>> wrote:
>>>
>>> One other suggestion: It was stated in the past that the 
concurrent

>>> classes are also a bit out of scope for [lang], especially the
>>> circuit
>>> breaker implementations. Would it make sense to move those into 
a

>>> new
>>> module, and could this be a home for the watch classes, too?
>>>
>>
>> Considering the

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

2018-03-15 14:36 GMT+01:00 Otto Fowler :

> If we can come to consensus on the way forward, I’ll be happy to do the
> work ( although I’ll need help of course ).
> I guess I’m the straw that broke the camel’s back then? ;)
>
>
>
>
> On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> Hi.
>
> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> > I think bringing back commons-monitoring/sirota would only be
> > possible if
> > it were to be modular enough that you could bring in the ‘core’
> > classes
> > without needing to bring in all of what sirota ended up being, which
> > was an
> > end to end solution.
>
> Isn't it possible? [I didn't look; Romain should tell whether he
> would be interested in taking that route.]
>

Sirona was done modular, just the API, the in memory part, etc...
But this kind of impl needs way more just after so not sure it does worth
splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons instead of
creating a community @incubator with an E2E solution? This is what I fail
to see.
My experience - coming exactly from here - tends to make me think commons
will not fit very long or will not bring enough value pretty quickly but
that's just my opinion.


>
> > commons-monitoring or commons-timing seem to be the correct thing
> > however,
> > but I would like to think that there would be more impetus
>
> I'm afraid that it's rather the lack of manpower.
> [And my inner conviction is that that state of things often
> led to rush to cramming more code into existing components,
> rather than "distribute" more uniformly according to subject
> matters. When scarce human resources ("community") disappear,
> cruft accumulates, sometimes up to stifle clean-up, maintenance,
> improvement, and even development.]
>
> > to do this than
> > thinking StackWatch is ‘too big’ for lang.time.
>
> It isn't any more than many other functionalities that were
> introduced but shouldn't have been.
> Depending on what the "Commons" PMC wants to favour ("code"
> *or* "community"?), the choice is between continuing with the
> accumulation, or back-pedaling through the creation of as
> many *real* components as they are developers willing to
> maintain them.
>
> > It really isn’t that complicated a thing.
>
> Sure.
> The issue is somewhere else.
> Note that, personally, I hadn't imagined that there would
> be an issue for regular developers of [Lang] (or I wouldn't
> have spent time reviewing the "details" ;-).
> But I of course agree that the question should be asked; the
> more so that, with [Math], we've a striking example of what
> awaits a library that lacks boundary checks and explicit
> road map.
>
> Regards,
> Gilles
>
> > On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
> >> -1 to "commons-misc". It feels to me like a copout and unfocused
> >> like
> >> SomethingUtils.
> >> We need a proper home.
> >
> > +1
> >
> >> How about the idea of commons-measure.
> >
> > Just because the first feature would happen to be a timer?
> > What other content do you foresee?
> >
> >> Then there
> >> still the idea of resurrecting other Apache projects. Kind of going
> >> in
> >> circles...
> >
> > Indeed, IIRC the questions were asked (whether the feature could
> > be contributed to ex-Sirona and whether that project would be
> > repatriated to "Commons") but not answered (unless I'm mistaken)...
> >
> > Best,
> > Gilles
> >
> >
> >> Gary
> >>
> >> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
> >>
> >> So, could think about commons-misc or something?
> >> I don’t think we are going to come up with a perfect module for
> >> these
> >> things.
> >>
> >> Maybe the way it can work is:
> >>
> >> commons-misc exists.
> >>
> >> It is the landing place for things that seem to be outside the scope
> >> of
> >> commons-, but don’t justify
> >> a new module or sandbox effort.
> >>
> >> Things in misc can be reevaluated for inclusion in new modules at
> >> things
> >> go, and at that point @Depricated
> >> out of misc.
> >>
> >> ?
> >>
> >>
> >>
> >> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
> >>
> >> On 2 March 2018 at 13:31, Oliver Heger
> >> 
> >> wrote:
> >>>
> >>> One other suggestion: It was stated in the past that the concurrent
> >>> classes are also a bit out of scope for [lang], especially the
> >>> circuit
> >>> breaker implementations. Would it make sense to move those into a
> >>> new
> >>> module, and could this be a home for the watch classes, too?
> >>>
> >>
> >> Considering the amount of retry libraries there are out there, I
> >> think it
> >> makes perfect sense for circuit breaker libraries to be their own
> >> thing,
> >> too. See Hysterix for example.
> >>
> >> --
> >> Matt Sicker 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@common

Re: [DISCUSS] new component for timing?

[Otto Fowler]

If we can come to consensus on the way forward, I’ll be happy to do the
work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)




On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org) wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the ‘core’
> classes
> without needing to bring in all of what sirota ended up being, which
> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]

> commons-monitoring or commons-timing seem to be the correct thing
> however,
> but I would like to think that there would be more impetus

I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather than "distribute" more uniformly according to subject
matters. When scarce human resources ("community") disappear,
cruft accumulates, sometimes up to stifle clean-up, maintenance,
improvement, and even development.]

> to do this than
> thinking StackWatch is ‘too big’ for lang.time.

It isn't any more than many other functionalities that were
introduced but shouldn't have been.
Depending on what the "Commons" PMC wants to favour ("code"
*or* "community"?), the choice is between continuing with the
accumulation, or back-pedaling through the creation of as
many *real* components as they are developers willing to
maintain them.

> It really isn’t that complicated a thing.

Sure.
The issue is somewhere else.
Note that, personally, I hadn't imagined that there would
be an issue for regular developers of [Lang] (or I wouldn't
have spent time reviewing the "details" ;-).
But I of course agree that the question should be asked; the
more so that, with [Math], we've a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

> On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
>> -1 to "commons-misc". It feels to me like a copout and unfocused
>> like
>> SomethingUtils.
>> We need a proper home.
>
> +1
>
>> How about the idea of commons-measure.
>
> Just because the first feature would happen to be a timer?
> What other content do you foresee?
>
>> Then there
>> still the idea of resurrecting other Apache projects. Kind of going
>> in
>> circles...
>
> Indeed, IIRC the questions were asked (whether the feature could
> be contributed to ex-Sirona and whether that project would be
> repatriated to "Commons") but not answered (unless I'm mistaken)...
>
> Best,
> Gilles
>
>
>> Gary
>>
>> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
>>
>> So, could think about commons-misc or something?
>> I don’t think we are going to come up with a perfect module for
>> these
>> things.
>>
>> Maybe the way it can work is:
>>
>> commons-misc exists.
>>
>> It is the landing place for things that seem to be outside the scope
>> of
>> commons-, but don’t justify
>> a new module or sandbox effort.
>>
>> Things in misc can be reevaluated for inclusion in new modules at
>> things
>> go, and at that point @Depricated
>> out of misc.
>>
>> ?
>>
>>
>>
>> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
>>
>> On 2 March 2018 at 13:31, Oliver Heger
>> 
>> wrote:
>>>
>>> One other suggestion: It was stated in the past that the concurrent
>>> classes are also a bit out of scope for [lang], especially the
>>> circuit
>>> breaker implementations. Would it make sense to move those into a
>>> new
>>> module, and could this be a home for the watch classes, too?
>>>
>>
>> Considering the amount of retry libraries there are out there, I
>> think it
>> makes perfect sense for circuit breaker libraries to be their own
>> thing,
>> too. See Hysterix for example.
>>
>> --
>> Matt Sicker 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] new component for timing?

[Gilles]

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
I think bringing back commons-monitoring/sirota would only be 
possible if
it were to be modular enough that you could bring in the ‘core’ 
classes
without needing to bring in all of what sirota ended up being, which 
was an

end to end solution.


Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]

commons-monitoring or commons-timing seem to be the correct thing 
however,

but I would like to think that there would be more impetus


I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather than "distribute" more uniformly according to subject
matters.  When scarce human resources ("community") disappear,
cruft accumulates, sometimes up to stifle clean-up, maintenance,
improvement, and even development.]


to do this than
thinking StackWatch is ‘too big’ for lang.time.


It isn't any more than many other functionalities that were
introduced but shouldn't have been.
Depending on what the "Commons" PMC wants to favour ("code"
*or* "community"?), the choice is between continuing with the
accumulation, or back-pedaling through the creation of as
many *real* components as they are developers willing to
maintain them.


It really isn’t that complicated a thing.


Sure.
The issue is somewhere else.
Note that, personally, I hadn't imagined that there would
be an issue for regular developers of [Lang] (or I wouldn't
have spent time reviewing the "details" ;-).
But I of course agree that the question should be asked; the
more so that, with [Math], we've a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org) 
wrote:


On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
-1 to "commons-misc". It feels to me like a copout and unfocused 
like

SomethingUtils.
We need a proper home.


+1


How about the idea of commons-measure.


Just because the first feature would happen to be a timer?
What other content do you foresee?


Then there
still the idea of resurrecting other Apache projects. Kind of going
in
circles...


Indeed, IIRC the questions were asked (whether the feature could
be contributed to ex-Sirona and whether that project would be
repatriated to "Commons") but not answered (unless I'm mistaken)...

Best,
Gilles



Gary

On Mar 8, 2018 08:58, "Otto Fowler"  wrote:

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for 
these

things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope
of
commons-, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at
things
go, and at that point @Depricated
out of misc.

?



On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:

On 2 March 2018 at 13:31, Oliver Heger 


wrote:


One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the
circuit
breaker implementations. Would it make sense to move those into a
new
module, and could this be a home for the watch classes, too?



Considering the amount of retry libraries there are out there, I
think it
makes perfect sense for circuit breaker libraries to be their own
thing,
too. See Hysterix for example.

--
Matt Sicker 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] new component for timing?

[Otto Fowler]

I think bringing back commons-monitoring/sirota would only be possible if
it were to be modular enough that you could bring in the ‘core’ classes
without needing to bring in all of what sirota ended up being, which was an
end to end solution.

commons-monitoring or commons-timing seem to be the correct thing however,
but I would like to think that there would be more impetus to do this than
thinking StackWatch is ‘too big’ for lang.time.

It really isn’t that complicated a thing.


On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org) wrote:

On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
> -1 to "commons-misc". It feels to me like a copout and unfocused like
> SomethingUtils.
> We need a proper home.

+1

> How about the idea of commons-measure.

Just because the first feature would happen to be a timer?
What other content do you foresee?

> Then there
> still the idea of resurrecting other Apache projects. Kind of going
> in
> circles...

Indeed, IIRC the questions were asked (whether the feature could
be contributed to ex-Sirona and whether that project would be
repatriated to "Commons") but not answered (unless I'm mistaken)...

Best,
Gilles


> Gary
>
> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
>
> So, could think about commons-misc or something?
> I don’t think we are going to come up with a perfect module for these
> things.
>
> Maybe the way it can work is:
>
> commons-misc exists.
>
> It is the landing place for things that seem to be outside the scope
> of
> commons-, but don’t justify
> a new module or sandbox effort.
>
> Things in misc can be reevaluated for inclusion in new modules at
> things
> go, and at that point @Depricated
> out of misc.
>
> ?
>
>
>
> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
>
> On 2 March 2018 at 13:31, Oliver Heger 
> wrote:
>>
>> One other suggestion: It was stated in the past that the concurrent
>> classes are also a bit out of scope for [lang], especially the
>> circuit
>> breaker implementations. Would it make sense to move those into a
>> new
>> module, and could this be a home for the watch classes, too?
>>
>
> Considering the amount of retry libraries there are out there, I
> think it
> makes perfect sense for circuit breaker libraries to be their own
> thing,
> too. See Hysterix for example.
>
> --
> Matt Sicker 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] new component for timing?

[Gilles]

On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:

-1 to "commons-misc". It feels to me like a copout and unfocused like
SomethingUtils.
We need a proper home.


+1


How about the idea of commons-measure.


Just because the first feature would happen to be a timer?
What other content do you foresee?


Then there
still the idea of resurrecting other Apache projects. Kind of going 
in

circles...


Indeed, IIRC the questions were asked (whether the feature could
be contributed to ex-Sirona and whether that project would be
repatriated to "Commons") but not answered (unless I'm mistaken)...

Best,
Gilles



Gary

On Mar 8, 2018 08:58, "Otto Fowler"  wrote:

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for these
things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope 
of

commons-, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at 
things

go, and at that point @Depricated
out of misc.

?



On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:

On 2 March 2018 at 13:31, Oliver Heger 
wrote:


One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the 
circuit
breaker implementations. Would it make sense to move those into a 
new

module, and could this be a home for the watch classes, too?



Considering the amount of retry libraries there are out there, I 
think it
makes perfect sense for circuit breaker libraries to be their own 
thing,

too. See Hysterix for example.

--
Matt Sicker 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] new component for timing?

[Gary Gregory]

-1 to "commons-misc". It feels to me like a copout and unfocused like
SomethingUtils.

We need a proper home. How about the idea of commons-measure. Then there
still the idea of resurrecting other Apache projects. Kind of going in
circles...

Gary

On Mar 8, 2018 08:58, "Otto Fowler"  wrote:

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for these
things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope of
commons-, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at things
go, and at that point @Depricated
out of misc.

?



On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:

On 2 March 2018 at 13:31, Oliver Heger 
wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

--
Matt Sicker 

Re: [DISCUSS] new component for timing?

[Otto Fowler]

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for these
things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope of
commons-, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at things
go, and at that point @Depricated
out of misc.

?


On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:

On 2 March 2018 at 13:31, Oliver Heger 
wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

-- 
Matt Sicker 

Re: [DISCUSS] new component for timing?

[Matt Sicker]

On 2 March 2018 at 13:31, Oliver Heger  wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

-- 
Matt Sicker 

Re: [DISCUSS] new component for timing?

[Bruno P. Kinoshita]

We could perhaps move some classes from the concurrent package too I think. 
Like the circuit breakers. That'd solve our current issue with java.desktop 
dependency and java9

Sent from Yahoo Mail on Android 
 
  On Sat, 3 Mar 2018 at 3:45, Gary Gregory wrote:   On 
Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler  wrote:

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

Something like that. For my money, I'd like this into a (probably new)
component that is not [lang] since it feels out of scope. StopWatch would
move to this new place (deprecate it in [lang] and copy it.)

Gary


>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler :
>
> > My understanding is that sirona was/is a complete system, as opposed to a
> > collection of utilities.
> > If StackWatch is too big for LANG it seems too small for sirona.  Along
> > with sirona being retired etc.
> >
> >
> >
> > On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> > rmannibu...@gmail.com) wrote:
> >
> > Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
> >
> > This sounds almost like a sort of Commons Metrics type project. See <
> > http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> > project called Commons Monitoring which may be similar.
> >
> >
> > Sirona started from commons-monitoring ;)
> >
> >
> >
> > On 28 February 2018 at 10:56, Gilles 
> wrote:
> >
> > > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> > >
> > >> 2018-02-28 17:11 GMT+01:00 Gilles :
> > >>
> > >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> Hi guys,
> > 
> >  On that topic we can keep in mind we retired not a lot time ago
> Apache
> >  Sirona which was a perf framework industrializing a stopwatch to
> >  summarize
> >  it.
> >  We can make it live again and would probably be a better fir than
> >  commons
> >  cause you quickly need more than just some time measurement when you
> >  start
> >  to work on these topics.
> > 
> > 
> > >>> Why was the project terminated?
> > >>>
> > >>>
> > >> Community didn't grow enough and activity was not that high - the
> > project
> > >> went stable pretty quickly. I forked it on github for now
> > >> https://github.com/rmannibucau/sirona
> > >>
> > >
> > > Does it contain a feature similar to the "StackWatch"
> > > proposed in
> > > https://issues.apache.org/jira/browse/LANG-1373
> > > ?
> > >
> > > If so, do you suggest that Otto's project should depend
> > > on Sirona?
> > >
> > > If not, do you suggest that Otto should submit the PR
> > > to Sirona (and then depend on it)?
> > >
> > >
> > > Gilles
> > >
> > >
> > >>>
> > >>> Just my 2 cts
> > 
> > 
> >  Romain Manni-Bucau
> >  @rmannibucau  | Blog
> >   | Old Blog
> >   | Github
> >   |
> >  LinkedIn  | Book
> > 
> >   >  high-performance>
> > 
> > 
> >  2018-02-28 16:56 GMT+01:00 Gary Gregory :
> > 
> >  On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
> gil...@harfang.homelinux.org
> > >
> > 
> > > wrote:
> > >
> > > > Hello.
> > > >
> > > > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> In the course of working through my pull request for adding new
> > LANG
> > > >> functionality on top of the StopWatch class, the issue has been
> > > raise
> > > as
> > > >> to
> > > >> if this functionality is ‘common’ or should
> > > >> be placed in a more specialized commons- component.
> > > >>
> > > >> We would like to take the discussion to the list for this, and
> see
> > > what
> > > >> everyone thinks.
> > > >>
> > > >> The StackWatch provides for tracking nested timings backed by
> > > StopWatch.
> > > >> You can start the watch, and start and stop multiple timings
> > through
> > > the
> > > >> call stack. Each timing is named and tag an

Re: [DISCUSS] new component for timing?

[Oliver Heger]

Am 02.03.2018 um 15:45 schrieb Gary Gregory:
> On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler  wrote:
> 
>> I don’t understand the options that we are discussing here.  Can we
>> clarify?
>>
>> * create a new component from sirota, bringing it into commons ( resurrect
>> commons-monitoring ) and put StackWatch there?
>>
> 
> Something like that. For my money, I'd like this into a (probably new)
> component that is not [lang] since it feels out of scope. StopWatch would
> move to this new place (deprecate it in [lang] and copy it.)

IMHO StackWatch does not fit very well into [lang] and into the testing
project neither.

One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the circuit
breaker implementations. Would it make sense to move those into a new
module, and could this be a home for the watch classes, too?

Oliver

> 
> Gary
> 
> 
>>
>> On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
>> wrote:
>>
>> This i right but it started as just a few utilities and interception
>> modules, then it grows as any performance related project. We also have
>> skywalking which is quite big but can host all that utility part @asf.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>>
>> 2018-03-02 14:45 GMT+01:00 Otto Fowler :
>>
>>> My understanding is that sirona was/is a complete system, as opposed to a
>>> collection of utilities.
>>> If StackWatch is too big for LANG it seems too small for sirona.  Along
>>> with sirona being retired etc.
>>>
>>>
>>>
>>> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
>>> rmannibu...@gmail.com) wrote:
>>>
>>> Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
>>>
>>> This sounds almost like a sort of Commons Metrics type project. See <
>>> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
>>> project called Commons Monitoring which may be similar.
>>>
>>>
>>> Sirona started from commons-monitoring ;)
>>>
>>>
>>>
>>> On 28 February 2018 at 10:56, Gilles 
>> wrote:
>>>
 On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:

> 2018-02-28 17:11 GMT+01:00 Gilles :
>
> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>
>> Hi guys,
>>>
>>> On that topic we can keep in mind we retired not a lot time ago
>> Apache
>>> Sirona which was a perf framework industrializing a stopwatch to
>>> summarize
>>> it.
>>> We can make it live again and would probably be a better fir than
>>> commons
>>> cause you quickly need more than just some time measurement when you
>>> start
>>> to work on these topics.
>>>
>>>
>> Why was the project terminated?
>>
>>
> Community didn't grow enough and activity was not that high - the
>>> project
> went stable pretty quickly. I forked it on github for now
> https://github.com/rmannibucau/sirona
>

 Does it contain a feature similar to the "StackWatch"
 proposed in
 https://issues.apache.org/jira/browse/LANG-1373
 ?

 If so, do you suggest that Otto's project should depend
 on Sirona?

 If not, do you suggest that Otto should submit the PR
 to Sirona (and then depend on it)?


 Gilles


>>
>> Just my 2 cts
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  | Blog
>>>  | Old Blog
>>>  | Github
>>>  |
>>> LinkedIn  | Book
>>>
>>> >> high-performance>
>>>
>>>
>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory :
>>>
>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
>> gil...@harfang.homelinux.org

>>>
 wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new
>>> LANG
>> functionality on top of the StopWatch class, the issue has been
 raise
 as
>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons- component.
>>
>> We would like to take the discussion to the list for this, and
>> see
 what
>> everyone thinks.
>>
>> The StackWatch provides for tracking nested timings backed by
 StopWatch.
>> You can start the watch, and start and sto

Re: [DISCUSS] new component for timing?

[Gary Gregory]

On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler  wrote:

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

Something like that. For my money, I'd like this into a (probably new)
component that is not [lang] since it feels out of scope. StopWatch would
move to this new place (deprecate it in [lang] and copy it.)

Gary


>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler :
>
> > My understanding is that sirona was/is a complete system, as opposed to a
> > collection of utilities.
> > If StackWatch is too big for LANG it seems too small for sirona.  Along
> > with sirona being retired etc.
> >
> >
> >
> > On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> > rmannibu...@gmail.com) wrote:
> >
> > Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
> >
> > This sounds almost like a sort of Commons Metrics type project. See <
> > http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> > project called Commons Monitoring which may be similar.
> >
> >
> > Sirona started from commons-monitoring ;)
> >
> >
> >
> > On 28 February 2018 at 10:56, Gilles 
> wrote:
> >
> > > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> > >
> > >> 2018-02-28 17:11 GMT+01:00 Gilles :
> > >>
> > >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> Hi guys,
> > 
> >  On that topic we can keep in mind we retired not a lot time ago
> Apache
> >  Sirona which was a perf framework industrializing a stopwatch to
> >  summarize
> >  it.
> >  We can make it live again and would probably be a better fir than
> >  commons
> >  cause you quickly need more than just some time measurement when you
> >  start
> >  to work on these topics.
> > 
> > 
> > >>> Why was the project terminated?
> > >>>
> > >>>
> > >> Community didn't grow enough and activity was not that high - the
> > project
> > >> went stable pretty quickly. I forked it on github for now
> > >> https://github.com/rmannibucau/sirona
> > >>
> > >
> > > Does it contain a feature similar to the "StackWatch"
> > > proposed in
> > > https://issues.apache.org/jira/browse/LANG-1373
> > > ?
> > >
> > > If so, do you suggest that Otto's project should depend
> > > on Sirona?
> > >
> > > If not, do you suggest that Otto should submit the PR
> > > to Sirona (and then depend on it)?
> > >
> > >
> > > Gilles
> > >
> > >
> > >>>
> > >>> Just my 2 cts
> > 
> > 
> >  Romain Manni-Bucau
> >  @rmannibucau  | Blog
> >   | Old Blog
> >   | Github
> >   |
> >  LinkedIn  | Book
> > 
> >   >  high-performance>
> > 
> > 
> >  2018-02-28 16:56 GMT+01:00 Gary Gregory :
> > 
> >  On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
> gil...@harfang.homelinux.org
> > >
> > 
> > > wrote:
> > >
> > > > Hello.
> > > >
> > > > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> In the course of working through my pull request for adding new
> > LANG
> > > >> functionality on top of the StopWatch class, the issue has been
> > > raise
> > > as
> > > >> to
> > > >> if this functionality is ‘common’ or should
> > > >> be placed in a more specialized commons- component.
> > > >>
> > > >> We would like to take the discussion to the list for this, and
> see
> > > what
> > > >> everyone thinks.
> > > >>
> > > >> The StackWatch provides for tracking nested timings backed by
> > > StopWatch.
> > > >> You can start the watch, and start and stop multiple timings
> > through
> > > the
> > > >> call stack. Each timing is named and tag and has it’s own time.
> > > >> You can visit all the timings, perhaps using the tags to filter
> > when
> > > you
> > > >> are done. Please see the PR/Jira for more details. You should
> > look
> > > at
> > > >> both, since the review has been s

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

2018-03-02 15:31 GMT+01:00 Otto Fowler :

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

I would more push to have a performance project, either we reuse one we
already have or we create back another one but commons will not fit very
well very long IMHO.


>
>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler :
>
>> My understanding is that sirona was/is a complete system, as opposed to a
>> collection of utilities.
>> If StackWatch is too big for LANG it seems too small for sirona.  Along
>> with sirona being retired etc.
>>
>>
>>
>> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
>> rmannibu...@gmail.com) wrote:
>>
>> Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
>>
>> This sounds almost like a sort of Commons Metrics type project. See <
>> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
>> project called Commons Monitoring which may be similar.
>>
>>
>> Sirona started from commons-monitoring ;)
>>
>>
>>
>> On 28 February 2018 at 10:56, Gilles 
>> wrote:
>>
>> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>> >
>> >> 2018-02-28 17:11 GMT+01:00 Gilles :
>> >>
>> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>> >>>
>> >>> Hi guys,
>> 
>>  On that topic we can keep in mind we retired not a lot time ago
>> Apache
>>  Sirona which was a perf framework industrializing a stopwatch to
>>  summarize
>>  it.
>>  We can make it live again and would probably be a better fir than
>>  commons
>>  cause you quickly need more than just some time measurement when you
>>  start
>>  to work on these topics.
>> 
>> 
>> >>> Why was the project terminated?
>> >>>
>> >>>
>> >> Community didn't grow enough and activity was not that high - the
>> project
>> >> went stable pretty quickly. I forked it on github for now
>> >> https://github.com/rmannibucau/sirona
>> >>
>> >
>> > Does it contain a feature similar to the "StackWatch"
>> > proposed in
>> > https://issues.apache.org/jira/browse/LANG-1373
>> > ?
>> >
>> > If so, do you suggest that Otto's project should depend
>> > on Sirona?
>> >
>> > If not, do you suggest that Otto should submit the PR
>> > to Sirona (and then depend on it)?
>> >
>> >
>> > Gilles
>> >
>> >
>> >>>
>> >>> Just my 2 cts
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau  | Blog
>>   | Old Blog
>>   | Github
>>   |
>>  LinkedIn  | Book
>> 
>>  >  high-performance>
>> 
>> 
>>  2018-02-28 16:56 GMT+01:00 Gary Gregory :
>> 
>>  On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
>> gil...@harfang.homelinux.org>
>> 
>> > wrote:
>> >
>> > > Hello.
>> > >
>> > > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> In the course of working through my pull request for adding new
>> LANG
>> > >> functionality on top of the StopWatch class, the issue has been
>> > raise
>> > as
>> > >> to
>> > >> if this functionality is ‘common’ or should
>> > >> be placed in a more specialized commons- component.
>> > >>
>> > >> We would like to take the discussion to the list for this, and
>> see
>> > what
>> > >> everyone thinks.
>> > >>
>> > >> The StackWatch provides for tracking nested timings backed by
>> > StopWatch.
>> > >> You can start the watch, and start and stop multiple timings
>> through
>> > the
>> > >> call stack. Each timing is named and tag and has it’s own time.
>> > >> You can visit all the timings, perhaps using the tags to filter
>> when
>> > you
>> > >> are done. Please see the PR/Jira for more details. You should
>> look
>> > at
>> > >> both, since the review has been split between the two.
>> > >>
>> > >> If not LANG, then where? The commons-testing component has been
>> > >> mentioned. But this code is not ‘test’ code explicitly. I

Re: [DISCUSS] new component for timing?

[Otto Fowler]

I don’t understand the options that we are discussing here.  Can we clarify?

* create a new component from sirota, bringing it into commons ( resurrect
commons-monitoring ) and put StackWatch there?


On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

This i right but it started as just a few utilities and interception
modules, then it grows as any performance related project. We also have
skywalking which is quite big but can host all that utility part @asf.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-03-02 14:45 GMT+01:00 Otto Fowler :

> My understanding is that sirona was/is a complete system, as opposed to a
> collection of utilities.
> If StackWatch is too big for LANG it seems too small for sirona.  Along
> with sirona being retired etc.
>
>
>
> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> rmannibu...@gmail.com) wrote:
>
> Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
>
> This sounds almost like a sort of Commons Metrics type project. See <
> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> project called Commons Monitoring which may be similar.
>
>
> Sirona started from commons-monitoring ;)
>
>
>
> On 28 February 2018 at 10:56, Gilles  wrote:
>
> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> >
> >> 2018-02-28 17:11 GMT+01:00 Gilles :
> >>
> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> Hi guys,
> 
>  On that topic we can keep in mind we retired not a lot time ago Apache
>  Sirona which was a perf framework industrializing a stopwatch to
>  summarize
>  it.
>  We can make it live again and would probably be a better fir than
>  commons
>  cause you quickly need more than just some time measurement when you
>  start
>  to work on these topics.
> 
> 
> >>> Why was the project terminated?
> >>>
> >>>
> >> Community didn't grow enough and activity was not that high - the
> project
> >> went stable pretty quickly. I forked it on github for now
> >> https://github.com/rmannibucau/sirona
> >>
> >
> > Does it contain a feature similar to the "StackWatch"
> > proposed in
> > https://issues.apache.org/jira/browse/LANG-1373
> > ?
> >
> > If so, do you suggest that Otto's project should depend
> > on Sirona?
> >
> > If not, do you suggest that Otto should submit the PR
> > to Sirona (and then depend on it)?
> >
> >
> > Gilles
> >
> >
> >>>
> >>> Just my 2 cts
> 
> 
>  Romain Manni-Bucau
>  @rmannibucau  | Blog
>   | Old Blog
>   | Github
>   |
>  LinkedIn  | Book
> 
>    high-performance>
> 
> 
>  2018-02-28 16:56 GMT+01:00 Gary Gregory :
> 
>  On Wed, Feb 28, 2018 at 6:35 AM, Gilles  >
> 
> > wrote:
> >
> > > Hello.
> > >
> > > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > >
> > >> Hi,
> > >>
> > >> In the course of working through my pull request for adding new
> LANG
> > >> functionality on top of the StopWatch class, the issue has been
> > raise
> > as
> > >> to
> > >> if this functionality is ‘common’ or should
> > >> be placed in a more specialized commons- component.
> > >>
> > >> We would like to take the discussion to the list for this, and see
> > what
> > >> everyone thinks.
> > >>
> > >> The StackWatch provides for tracking nested timings backed by
> > StopWatch.
> > >> You can start the watch, and start and stop multiple timings
> through
> > the
> > >> call stack. Each timing is named and tag and has it’s own time.
> > >> You can visit all the timings, perhaps using the tags to filter
> when
> > you
> > >> are done. Please see the PR/Jira for more details. You should
> look
> > at
> > >> both, since the review has been split between the two.
> > >>
> > >> If not LANG, then where? The commons-testing component has been
> > >> mentioned. But this code is not ‘test’ code explicitly. In my use
> > case (
> > >> I wrote this for the Apache Metron project and thought it might be
> > useful
> > >> here) it would not be test code, in the sense that it would be
> used
> > in
> > >> ‘test’ scope in mvn. Rather it would be deployed in production, in
> > a
> > >> REPL,
> > >> and perhaps in other runtime components.
> > >>
> > >
> > > Part of what makes a 

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

This i right but it started as just a few utilities and interception
modules, then it grows as any performance related project. We also have
skywalking which is quite big but can host all that utility part @asf.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-03-02 14:45 GMT+01:00 Otto Fowler :

> My understanding is that sirona was/is a complete system, as opposed to a
> collection of utilities.
> If StackWatch is too big for LANG it seems too small for sirona.  Along
> with sirona being retired etc.
>
>
>
> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> rmannibu...@gmail.com) wrote:
>
> Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :
>
> This sounds almost like a sort of Commons Metrics type project. See <
> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> project called Commons Monitoring which may be similar.
>
>
> Sirona started from commons-monitoring ;)
>
>
>
> On 28 February 2018 at 10:56, Gilles 
> wrote:
>
> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> >
> >> 2018-02-28 17:11 GMT+01:00 Gilles :
> >>
> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> Hi guys,
> 
>  On that topic we can keep in mind we retired not a lot time ago
> Apache
>  Sirona which was a perf framework industrializing a stopwatch to
>  summarize
>  it.
>  We can make it live again and would probably be a better fir than
>  commons
>  cause you quickly need more than just some time measurement when you
>  start
>  to work on these topics.
> 
> 
> >>> Why was the project terminated?
> >>>
> >>>
> >> Community didn't grow enough and activity was not that high - the
> project
> >> went stable pretty quickly. I forked it on github for now
> >> https://github.com/rmannibucau/sirona
> >>
> >
> > Does it contain a feature similar to the "StackWatch"
> > proposed in
> > https://issues.apache.org/jira/browse/LANG-1373
> > ?
> >
> > If so, do you suggest that Otto's project should depend
> > on Sirona?
> >
> > If not, do you suggest that Otto should submit the PR
> > to Sirona (and then depend on it)?
> >
> >
> > Gilles
> >
> >
> >>>
> >>> Just my 2 cts
> 
> 
>  Romain Manni-Bucau
>  @rmannibucau  | Blog
>   | Old Blog
>   | Github
>   |
>  LinkedIn  | Book
> 
>    high-performance>
> 
> 
>  2018-02-28 16:56 GMT+01:00 Gary Gregory :
> 
>  On Wed, Feb 28, 2018 at 6:35 AM, Gilles 
>
> 
> > wrote:
> >
> > > Hello.
> > >
> > > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > >
> > >> Hi,
> > >>
> > >> In the course of working through my pull request for adding new
> LANG
> > >> functionality on top of the StopWatch class, the issue has been
> > raise
> > as
> > >> to
> > >> if this functionality is ‘common’ or should
> > >> be placed in a more specialized commons- component.
> > >>
> > >> We would like to take the discussion to the list for this, and
> see
> > what
> > >> everyone thinks.
> > >>
> > >> The StackWatch provides for tracking nested timings backed by
> > StopWatch.
> > >> You can start the watch, and start and stop multiple timings
> through
> > the
> > >> call stack. Each timing is named and tag and has it’s own time.
> > >> You can visit all the timings, perhaps using the tags to filter
> when
> > you
> > >> are done. Please see the PR/Jira for more details. You should
> look
> > at
> > >> both, since the review has been split between the two.
> > >>
> > >> If not LANG, then where? The commons-testing component has been
> > >> mentioned. But this code is not ‘test’ code explicitly. In my use
> > case (
> > >> I wrote this for the Apache Metron project and thought it might
> be
> > useful
> > >> here) it would not be test code, in the sense that it would be
> used
> > in
> > >> ‘test’ scope in mvn. Rather it would be deployed in production,
> in
> > a
> > >> REPL,
> > >> and perhaps in other runtime components.
> > >>
> > >
> > > Part of what makes a good component is that it does not dictate
> > > how and where applications should use it.
> > > The name "Testing" does not imply that its contents must be used
> > > within "test" scope.
> > >
> > > A utility such as "StackWatch" could be another tool

Re: [DISCUSS] new component for timing?

[Otto Fowler]

My understanding is that sirona was/is a complete system, as opposed to a
collection of utilities.
If StackWatch is too big for LANG it seems too small for sirona.  Along
with sirona being retired etc.



On February 28, 2018 at 15:06:52, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.


Sirona started from commons-monitoring ;)



On 28 February 2018 at 10:56, Gilles  wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles :
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,

 On that topic we can keep in mind we retired not a lot time ago Apache
 Sirona which was a perf framework industrializing a stopwatch to
 summarize
 it.
 We can make it live again and would probably be a better fir than
 commons
 cause you quickly need more than just some time measurement when you
 start
 to work on these topics.


>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the
project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
> https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts


 Romain Manni-Bucau
 @rmannibucau  | Blog
  | Old Blog
  | Github
  |
 LinkedIn  | Book

 


 2018-02-28 16:56 GMT+01:00 Gary Gregory :

 On Wed, Feb 28, 2018 at 6:35 AM, Gilles 

> wrote:
>
> > Hello.
> >
> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >
> >> Hi,
> >>
> >> In the course of working through my pull request for adding new
LANG
> >> functionality on top of the StopWatch class, the issue has been
> raise
> as
> >> to
> >> if this functionality is ‘common’ or should
> >> be placed in a more specialized commons- component.
> >>
> >> We would like to take the discussion to the list for this, and see
> what
> >> everyone thinks.
> >>
> >> The StackWatch provides for tracking nested timings backed by
> StopWatch.
> >> You can start the watch, and start and stop multiple timings
through
> the
> >> call stack. Each timing is named and tag and has it’s own time.
> >> You can visit all the timings, perhaps using the tags to filter
when
> you
> >> are done. Please see the PR/Jira for more details. You should
look
> at
> >> both, since the review has been split between the two.
> >>
> >> If not LANG, then where? The commons-testing component has been
> >> mentioned. But this code is not ‘test’ code explicitly. In my use
> case (
> >> I wrote this for the Apache Metron project and thought it might be
> useful
> >> here) it would not be test code, in the sense that it would be
used
> in
> >> ‘test’ scope in mvn. Rather it would be deployed in production, in
> a
> >> REPL,
> >> and perhaps in other runtime components.
> >>
> >
> > Part of what makes a good component is that it does not dictate
> > how and where applications should use it.
> > The name "Testing" does not imply that its contents must be used
> > within "test" scope.
> >
> > A utility such as "StackWatch" could be another tool to integrate
> > in a unit test suite (e.g. to generate a more fine-grained timing
> > report than Junit does). Hence the module in which "StackWatch"
> > will belong is to become a dependency of modules that target
> > specific test framework (and that is true whether the former is
> > defined within "Testing" or in another component).
> >
> > I would not want to pull in junit
> >> or other dependencies with any component containing it.
> >>
> >
> > +1
> > Must be ensured by proper granularity of the modular design.
> >
> > If we put it in commons-testing ( which already has sub-modules
which
> are
> >> geared towards junit ) it may be confusing, even if the module is
> explicit
> >> about purpose and keeping out junit dependent code ( or other
> testing
> >> code).
> >>
> >

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

Le 28 févr. 2018 19:27, "Matt Sicker"  a écrit :

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.


Sirona started from commons-monitoring ;)



On 28 February 2018 at 10:56, Gilles  wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles :
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,

 On that topic we can keep in mind we retired not a lot time ago Apache
 Sirona which was a perf framework industrializing a stopwatch to
 summarize
 it.
 We can make it live again and would probably be a better fir than
 commons
 cause you quickly need more than just some time measurement when you
 start
 to work on these topics.


>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
>   https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts


 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github
  |
 LinkedIn  | Book

 


 2018-02-28 16:56 GMT+01:00 Gary Gregory :

 On Wed, Feb 28, 2018 at 6:35 AM, Gilles 

> wrote:
>
> > Hello.
> >
> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >
> >> Hi,
> >>
> >> In the course of working through my pull request for adding new
LANG
> >> functionality on top of the StopWatch class, the issue has been
> raise
> as
> >> to
> >> if this functionality is ‘common’ or should
> >> be placed in a more specialized commons- component.
> >>
> >> We would like to take the discussion to the list for this, and see
> what
> >> everyone thinks.
> >>
> >> The StackWatch provides for tracking nested timings backed by
> StopWatch.
> >> You can start the watch, and start and stop multiple timings
through
> the
> >> call stack. Each timing is named and tag and has it’s own time.
> >> You can visit all the timings, perhaps using the tags to filter
when
> you
> >> are done.  Please see the PR/Jira for more details.  You should
look
> at
> >> both, since the review has been split between the two.
> >>
> >> If not LANG, then where?  The commons-testing component has been
> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
> case (
> >> I wrote this for the Apache Metron project and thought it might be
> useful
> >> here) it would not be test code, in the sense that it would be used
> in
> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in
> a
> >> REPL,
> >> and perhaps in other runtime components.
> >>
> >
> > Part of what makes a good component is that it does not dictate
> > how and where applications should use it.
> > The name "Testing" does not imply that its contents must be used
> > within "test" scope.
> >
> > A utility such as "StackWatch" could be another tool to integrate
> > in a unit test suite (e.g. to generate a more fine-grained timing
> > report than Junit does).  Hence the module in which "StackWatch"
> > will belong is to become a dependency of modules that target
> > specific test framework (and that is true whether the former is
> > defined within "Testing" or in another component).
> >
> > I would not want to pull in junit
> >> or other dependencies with any component containing it.
> >>
> >
> > +1
> > Must be ensured by proper granularity of the modular design.
> >
> > If we put it in commons-testing ( which already has sub-modules
which
> are
> >> geared towards junit ) it may be confusing, even if the module is
> explicit
> >> about purpose and keeping out junit dependent code ( or other
> testing
> >> code).
> >>
> >
> > Why would it be confusing?  The module will stand out on its own
> > (artefact/description/doc/web site) and be more visible than yet
> > another class in the already too large "Commons Lang".
> >
> > Also, besides the StackWatch, what else would go into 

Re: [DISCUSS] new component for timing?

[Matt Sicker]

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.

On 28 February 2018 at 10:56, Gilles  wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles :
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,

 On that topic we can keep in mind we retired not a lot time ago Apache
 Sirona which was a perf framework industrializing a stopwatch to
 summarize
 it.
 We can make it live again and would probably be a better fir than
 commons
 cause you quickly need more than just some time measurement when you
 start
 to work on these topics.


>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
>   https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts


 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github
  |
 LinkedIn  | Book

 


 2018-02-28 16:56 GMT+01:00 Gary Gregory :

 On Wed, Feb 28, 2018 at 6:35 AM, Gilles 

> wrote:
>
> > Hello.
> >
> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >
> >> Hi,
> >>
> >> In the course of working through my pull request for adding new LANG
> >> functionality on top of the StopWatch class, the issue has been
> raise
> as
> >> to
> >> if this functionality is ‘common’ or should
> >> be placed in a more specialized commons- component.
> >>
> >> We would like to take the discussion to the list for this, and see
> what
> >> everyone thinks.
> >>
> >> The StackWatch provides for tracking nested timings backed by
> StopWatch.
> >> You can start the watch, and start and stop multiple timings through
> the
> >> call stack. Each timing is named and tag and has it’s own time.
> >> You can visit all the timings, perhaps using the tags to filter when
> you
> >> are done.  Please see the PR/Jira for more details.  You should look
> at
> >> both, since the review has been split between the two.
> >>
> >> If not LANG, then where?  The commons-testing component has been
> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
> case (
> >> I wrote this for the Apache Metron project and thought it might be
> useful
> >> here) it would not be test code, in the sense that it would be used
> in
> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in
> a
> >> REPL,
> >> and perhaps in other runtime components.
> >>
> >
> > Part of what makes a good component is that it does not dictate
> > how and where applications should use it.
> > The name "Testing" does not imply that its contents must be used
> > within "test" scope.
> >
> > A utility such as "StackWatch" could be another tool to integrate
> > in a unit test suite (e.g. to generate a more fine-grained timing
> > report than Junit does).  Hence the module in which "StackWatch"
> > will belong is to become a dependency of modules that target
> > specific test framework (and that is true whether the former is
> > defined within "Testing" or in another component).
> >
> > I would not want to pull in junit
> >> or other dependencies with any component containing it.
> >>
> >
> > +1
> > Must be ensured by proper granularity of the modular design.
> >
> > If we put it in commons-testing ( which already has sub-modules which
> are
> >> geared towards junit ) it may be confusing, even if the module is
> explicit
> >> about purpose and keeping out junit dependent code ( or other
> testing
> >> code).
> >>
> >
> > Why would it be confusing?  The module will stand out on its own
> > (artefact/description/doc/web site) and be more visible than yet
> > another class in the already too large "Commons Lang".
> >
> > Also, besides the StackWatch, what else would go into the new target
> >> component?  Would StopWatch move as well for example?
> >>
> >
>

Re: [DISCUSS] new component for timing?

[Gilles]

On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:

2018-02-28 17:11 GMT+01:00 Gilles :


On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:


Hi guys,

On that topic we can keep in mind we retired not a lot time ago 
Apache
Sirona which was a perf framework industrializing a stopwatch to 
summarize

it.
We can make it live again and would probably be a better fir than 
commons
cause you quickly need more than just some time measurement when 
you start

to work on these topics.



Why was the project terminated?



Community didn't grow enough and activity was not that high - the 
project

went stable pretty quickly. I forked it on github for now
https://github.com/rmannibucau/sirona


Does it contain a feature similar to the "StackWatch"
proposed in
  https://issues.apache.org/jira/browse/LANG-1373
?

If so, do you suggest that Otto's project should depend
on Sirona?

If not, do you suggest that Otto should submit the PR
to Sirona (and then depend on it)?

Gilles





Just my 2 cts


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github
 |
LinkedIn  | Book




2018-02-28 16:56 GMT+01:00 Gary Gregory :

On Wed, Feb 28, 2018 at 6:35 AM, Gilles 


wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new 
LANG
>> functionality on top of the StopWatch class, the issue has been 
raise

as
>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons- component.
>>
>> We would like to take the discussion to the list for this, and 
see

what
>> everyone thinks.
>>
>> The StackWatch provides for tracking nested timings backed by
StopWatch.
>> You can start the watch, and start and stop multiple timings 
through

the
>> call stack. Each timing is named and tag and has it’s own time.
>> You can visit all the timings, perhaps using the tags to filter 
when

you
>> are done.  Please see the PR/Jira for more details.  You should 
look

at
>> both, since the review has been split between the two.
>>
>> If not LANG, then where?  The commons-testing component has 
been
>> mentioned.  But this code is not ‘test’ code explicitly.  In my 
use

case (
>> I wrote this for the Apache Metron project and thought it might 
be

useful
>> here) it would not be test code, in the sense that it would be 
used in
>> ‘test’ scope in mvn.  Rather it would be deployed in 
production, in a

>> REPL,
>> and perhaps in other runtime components.
>>
>
> Part of what makes a good component is that it does not dictate
> how and where applications should use it.
> The name "Testing" does not imply that its contents must be used
> within "test" scope.
>
> A utility such as "StackWatch" could be another tool to 
integrate
> in a unit test suite (e.g. to generate a more fine-grained 
timing

> report than Junit does).  Hence the module in which "StackWatch"
> will belong is to become a dependency of modules that target
> specific test framework (and that is true whether the former is
> defined within "Testing" or in another component).
>
> I would not want to pull in junit
>> or other dependencies with any component containing it.
>>
>
> +1
> Must be ensured by proper granularity of the modular design.
>
> If we put it in commons-testing ( which already has sub-modules 
which

are
>> geared towards junit ) it may be confusing, even if the module 
is

explicit
>> about purpose and keeping out junit dependent code ( or other 
testing

>> code).
>>
>
> Why would it be confusing?  The module will stand out on its own
> (artefact/description/doc/web site) and be more visible than yet
> another class in the already too large "Commons Lang".
>
> Also, besides the StackWatch, what else would go into the new 
target

>> component?  Would StopWatch move as well for example?
>>
>
> +1
> But creating a new component for two small classes can 
reasonably

> be argued as overkill.
> FTR: I was asked to collect the sampling utilities within a
> module of "Commons RNG" even though it could have warranted its
> own component (being a plain "client" of the core functionality
> of [RNG]).  In the present case, "StackWatch" would belong to
> "core" utilities of "Testing" that are pulled (along with other
> dependencies by the more specific modules.
>

I would ask all of us to step back for a moment and consider the 
big

picture.

Specifically, what do you consider the mandate or guidelines for 
Commons
Lang to be? For me, this is code that should or could have been in 
the

JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang 
should

likely only depend on java.base (it does today but this should be
enforced
with the Maven JDeps Plugin IMO.

Re: [DISCUSS] new component for timing?

[Gilles]

On Wed, 28 Feb 2018 08:56:07 -0700, Gary Gregory wrote:
On Wed, Feb 28, 2018 at 6:35 AM, Gilles 


wrote:


Hello.

On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:


Hi,

In the course of working through my pull request for adding new 
LANG
functionality on top of the StopWatch class, the issue has been 
raise as

to
if this functionality is ‘common’ or should
be placed in a more specialized commons- component.

We would like to take the discussion to the list for this, and see 
what

everyone thinks.

The StackWatch provides for tracking nested timings backed by 
StopWatch.
You can start the watch, and start and stop multiple timings 
through the

call stack. Each timing is named and tag and has it’s own time.
You can visit all the timings, perhaps using the tags to filter 
when you
are done.  Please see the PR/Jira for more details.  You should 
look at

both, since the review has been split between the two.

If not LANG, then where?  The commons-testing component has been
mentioned.  But this code is not ‘test’ code explicitly.  In my use 
case (
I wrote this for the Apache Metron project and thought it might be 
useful
here) it would not be test code, in the sense that it would be used 
in
‘test’ scope in mvn.  Rather it would be deployed in production, in 
a

REPL,
and perhaps in other runtime components.



Part of what makes a good component is that it does not dictate
how and where applications should use it.
The name "Testing" does not imply that its contents must be used
within "test" scope.

A utility such as "StackWatch" could be another tool to integrate
in a unit test suite (e.g. to generate a more fine-grained timing
report than Junit does).  Hence the module in which "StackWatch"
will belong is to become a dependency of modules that target
specific test framework (and that is true whether the former is
defined within "Testing" or in another component).

I would not want to pull in junit

or other dependencies with any component containing it.



+1
Must be ensured by proper granularity of the modular design.

If we put it in commons-testing ( which already has sub-modules 
which are
geared towards junit ) it may be confusing, even if the module is 
explicit
about purpose and keeping out junit dependent code ( or other 
testing

code).



Why would it be confusing?  The module will stand out on its own
(artefact/description/doc/web site) and be more visible than yet
another class in the already too large "Commons Lang".

Also, besides the StackWatch, what else would go into the new target

component?  Would StopWatch move as well for example?



+1
But creating a new component for two small classes can reasonably
be argued as overkill.
FTR: I was asked to collect the sampling utilities within a
module of "Commons RNG" even though it could have warranted its
own component (being a plain "client" of the core functionality
of [RNG]).  In the present case, "StackWatch" would belong to
"core" utilities of "Testing" that are pulled (along with other
dependencies by the more specific modules.



I would ask all of us to step back for a moment and consider the big
picture.


+1

Specifically, what do you consider the mandate or guidelines for 
Commons
Lang to be? For me, this is code that should or could have been in 
the JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang 
should
likely only depend on java.base (it does today but this should be 
enforced

with the Maven JDeps Plugin IMO.)


+1

If you look at StringUtils, you can then see how this class has grown 
into

a giant. You can also then see why other related code like a fancier
String.replace() could creep in as StrSubstitutor and friends. Should
variable interpolation have been in the JRE? Debatable, but it would 
be
useful on top of Properties and ResourceBundle, one might argue; also 
handy
for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- 
rightly IMO
-- have deprecated StrSubstitutor in Commons Lang in favor or its new 
home

in Commons Text, where is has evolved further.


Package "java.text" is in module "java.base".
Revise the naming? ;-)


In my view, StopWatch and now StackWatch, do not belong in the JRE or
Commons Lang. It should sit slightly above that level.


I agree, but to be consistent, many things should be deprecated
before the next release of [Lang].


Where, is the
question.


It depends on the intended use-cases. Currently, I lack imagination
and see it fitting in [Testing].

Commons Testing for Stop/StackWatch does not seen quite right to me. 
I

could see a new Commons Timing


Tentative description/scope?


or a more general Commons Measurement;


Too vague and/or too broad:
  https://en.wikipedia.org/wiki/Measurement


with
a mandate NOT to overlap with Joda-Time and java.time.


Feature at hand is more about timer[1] than about date and
time manipulation.

The discussion should avoid implicit meanings. [We've been
there with opinions about "math" or "random" purely based

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

2018-02-28 17:11 GMT+01:00 Gilles :

> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>
>> Hi guys,
>>
>> On that topic we can keep in mind we retired not a lot time ago Apache
>> Sirona which was a perf framework industrializing a stopwatch to summarize
>> it.
>> We can make it live again and would probably be a better fir than commons
>> cause you quickly need more than just some time measurement when you start
>> to work on these topics.
>>
>
> Why was the project terminated?
>

Community didn't grow enough and activity was not that high - the project
went stable pretty quickly. I forked it on github for now
https://github.com/rmannibucau/sirona


>
> Gilles
>
>
>> Just my 2 cts
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  |
>> LinkedIn  | Book
>>
>> > high-performance>
>>
>>
>> 2018-02-28 16:56 GMT+01:00 Gary Gregory :
>>
>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles 
>>> wrote:
>>>
>>> > Hello.
>>> >
>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> In the course of working through my pull request for adding new LANG
>>> >> functionality on top of the StopWatch class, the issue has been raise
>>> as
>>> >> to
>>> >> if this functionality is ‘common’ or should
>>> >> be placed in a more specialized commons- component.
>>> >>
>>> >> We would like to take the discussion to the list for this, and see
>>> what
>>> >> everyone thinks.
>>> >>
>>> >> The StackWatch provides for tracking nested timings backed by
>>> StopWatch.
>>> >> You can start the watch, and start and stop multiple timings through
>>> the
>>> >> call stack. Each timing is named and tag and has it’s own time.
>>> >> You can visit all the timings, perhaps using the tags to filter when
>>> you
>>> >> are done.  Please see the PR/Jira for more details.  You should look
>>> at
>>> >> both, since the review has been split between the two.
>>> >>
>>> >> If not LANG, then where?  The commons-testing component has been
>>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
>>> case (
>>> >> I wrote this for the Apache Metron project and thought it might be
>>> useful
>>> >> here) it would not be test code, in the sense that it would be used in
>>> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
>>> >> REPL,
>>> >> and perhaps in other runtime components.
>>> >>
>>> >
>>> > Part of what makes a good component is that it does not dictate
>>> > how and where applications should use it.
>>> > The name "Testing" does not imply that its contents must be used
>>> > within "test" scope.
>>> >
>>> > A utility such as "StackWatch" could be another tool to integrate
>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>> > report than Junit does).  Hence the module in which "StackWatch"
>>> > will belong is to become a dependency of modules that target
>>> > specific test framework (and that is true whether the former is
>>> > defined within "Testing" or in another component).
>>> >
>>> > I would not want to pull in junit
>>> >> or other dependencies with any component containing it.
>>> >>
>>> >
>>> > +1
>>> > Must be ensured by proper granularity of the modular design.
>>> >
>>> > If we put it in commons-testing ( which already has sub-modules which
>>> are
>>> >> geared towards junit ) it may be confusing, even if the module is
>>> explicit
>>> >> about purpose and keeping out junit dependent code ( or other testing
>>> >> code).
>>> >>
>>> >
>>> > Why would it be confusing?  The module will stand out on its own
>>> > (artefact/description/doc/web site) and be more visible than yet
>>> > another class in the already too large "Commons Lang".
>>> >
>>> > Also, besides the StackWatch, what else would go into the new target
>>> >> component?  Would StopWatch move as well for example?
>>> >>
>>> >
>>> > +1
>>> > But creating a new component for two small classes can reasonably
>>> > be argued as overkill.
>>> > FTR: I was asked to collect the sampling utilities within a
>>> > module of "Commons RNG" even though it could have warranted its
>>> > own component (being a plain "client" of the core functionality
>>> > of [RNG]).  In the present case, "StackWatch" would belong to
>>> > "core" utilities of "Testing" that are pulled (along with other
>>> > dependencies by the more specific modules.
>>> >
>>>
>>> I would ask all of us to step back for a moment and consider the big
>>> picture.
>>>
>>> Specifically, what do you consider the mandate or guidelines for Commons
>>> Lang to be? For me, this is code that should or could have been in the
>>> JRE
>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
>>> likely only depend on java.base (it does tod

Re: [DISCUSS] new component for timing?

[Gilles]

On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:

Hi guys,

On that topic we can keep in mind we retired not a lot time ago 
Apache
Sirona which was a perf framework industrializing a stopwatch to 
summarize

it.
We can make it live again and would probably be a better fir than 
commons
cause you quickly need more than just some time measurement when you 
start

to work on these topics.


Why was the project terminated?

Gilles



Just my 2 cts


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github
 |
LinkedIn  | Book



2018-02-28 16:56 GMT+01:00 Gary Gregory :

On Wed, Feb 28, 2018 at 6:35 AM, Gilles 


wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new 
LANG
>> functionality on top of the StopWatch class, the issue has been 
raise as

>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons- component.
>>
>> We would like to take the discussion to the list for this, and 
see what

>> everyone thinks.
>>
>> The StackWatch provides for tracking nested timings backed by 
StopWatch.
>> You can start the watch, and start and stop multiple timings 
through the

>> call stack. Each timing is named and tag and has it’s own time.
>> You can visit all the timings, perhaps using the tags to filter 
when you
>> are done.  Please see the PR/Jira for more details.  You should 
look at

>> both, since the review has been split between the two.
>>
>> If not LANG, then where?  The commons-testing component has been
>> mentioned.  But this code is not ‘test’ code explicitly.  In my 
use

case (
>> I wrote this for the Apache Metron project and thought it might 
be

useful
>> here) it would not be test code, in the sense that it would be 
used in
>> ‘test’ scope in mvn.  Rather it would be deployed in production, 
in a

>> REPL,
>> and perhaps in other runtime components.
>>
>
> Part of what makes a good component is that it does not dictate
> how and where applications should use it.
> The name "Testing" does not imply that its contents must be used
> within "test" scope.
>
> A utility such as "StackWatch" could be another tool to integrate
> in a unit test suite (e.g. to generate a more fine-grained timing
> report than Junit does).  Hence the module in which "StackWatch"
> will belong is to become a dependency of modules that target
> specific test framework (and that is true whether the former is
> defined within "Testing" or in another component).
>
> I would not want to pull in junit
>> or other dependencies with any component containing it.
>>
>
> +1
> Must be ensured by proper granularity of the modular design.
>
> If we put it in commons-testing ( which already has sub-modules 
which are

>> geared towards junit ) it may be confusing, even if the module is
explicit
>> about purpose and keeping out junit dependent code ( or other 
testing

>> code).
>>
>
> Why would it be confusing?  The module will stand out on its own
> (artefact/description/doc/web site) and be more visible than yet
> another class in the already too large "Commons Lang".
>
> Also, besides the StackWatch, what else would go into the new 
target

>> component?  Would StopWatch move as well for example?
>>
>
> +1
> But creating a new component for two small classes can reasonably
> be argued as overkill.
> FTR: I was asked to collect the sampling utilities within a
> module of "Commons RNG" even though it could have warranted its
> own component (being a plain "client" of the core functionality
> of [RNG]).  In the present case, "StackWatch" would belong to
> "core" utilities of "Testing" that are pulled (along with other
> dependencies by the more specific modules.
>

I would ask all of us to step back for a moment and consider the big
picture.

Specifically, what do you consider the mandate or guidelines for 
Commons
Lang to be? For me, this is code that should or could have been in 
the JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang 
should
likely only depend on java.base (it does today but this should be 
enforced

with the Maven JDeps Plugin IMO.)

If you look at StringUtils, you can then see how this class has 
grown into

a giant. You can also then see why other related code like a fancier
String.replace() could creep in as StrSubstitutor and friends. 
Should
variable interpolation have been in the JRE? Debatable, but it would 
be
useful on top of Properties and ResourceBundle, one might argue; 
also handy
for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- 
rightly IMO
-- have deprecated StrSubstitutor in Commons Lang in favor or its 
new home

in Commons Text, where is has evolved further.

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

Hi guys,

On that topic we can keep in mind we retired not a lot time ago Apache
Sirona which was a perf framework industrializing a stopwatch to summarize
it.
We can make it live again and would probably be a better fir than commons
cause you quickly need more than just some time measurement when you start
to work on these topics.

Just my 2 cts


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-28 16:56 GMT+01:00 Gary Gregory :

> On Wed, Feb 28, 2018 at 6:35 AM, Gilles 
> wrote:
>
> > Hello.
> >
> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >
> >> Hi,
> >>
> >> In the course of working through my pull request for adding new LANG
> >> functionality on top of the StopWatch class, the issue has been raise as
> >> to
> >> if this functionality is ‘common’ or should
> >> be placed in a more specialized commons- component.
> >>
> >> We would like to take the discussion to the list for this, and see what
> >> everyone thinks.
> >>
> >> The StackWatch provides for tracking nested timings backed by StopWatch.
> >> You can start the watch, and start and stop multiple timings through the
> >> call stack. Each timing is named and tag and has it’s own time.
> >> You can visit all the timings, perhaps using the tags to filter when you
> >> are done.  Please see the PR/Jira for more details.  You should look at
> >> both, since the review has been split between the two.
> >>
> >> If not LANG, then where?  The commons-testing component has been
> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
> case (
> >> I wrote this for the Apache Metron project and thought it might be
> useful
> >> here) it would not be test code, in the sense that it would be used in
> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
> >> REPL,
> >> and perhaps in other runtime components.
> >>
> >
> > Part of what makes a good component is that it does not dictate
> > how and where applications should use it.
> > The name "Testing" does not imply that its contents must be used
> > within "test" scope.
> >
> > A utility such as "StackWatch" could be another tool to integrate
> > in a unit test suite (e.g. to generate a more fine-grained timing
> > report than Junit does).  Hence the module in which "StackWatch"
> > will belong is to become a dependency of modules that target
> > specific test framework (and that is true whether the former is
> > defined within "Testing" or in another component).
> >
> > I would not want to pull in junit
> >> or other dependencies with any component containing it.
> >>
> >
> > +1
> > Must be ensured by proper granularity of the modular design.
> >
> > If we put it in commons-testing ( which already has sub-modules which are
> >> geared towards junit ) it may be confusing, even if the module is
> explicit
> >> about purpose and keeping out junit dependent code ( or other testing
> >> code).
> >>
> >
> > Why would it be confusing?  The module will stand out on its own
> > (artefact/description/doc/web site) and be more visible than yet
> > another class in the already too large "Commons Lang".
> >
> > Also, besides the StackWatch, what else would go into the new target
> >> component?  Would StopWatch move as well for example?
> >>
> >
> > +1
> > But creating a new component for two small classes can reasonably
> > be argued as overkill.
> > FTR: I was asked to collect the sampling utilities within a
> > module of "Commons RNG" even though it could have warranted its
> > own component (being a plain "client" of the core functionality
> > of [RNG]).  In the present case, "StackWatch" would belong to
> > "core" utilities of "Testing" that are pulled (along with other
> > dependencies by the more specific modules.
> >
>
> I would ask all of us to step back for a moment and consider the big
> picture.
>
> Specifically, what do you consider the mandate or guidelines for Commons
> Lang to be? For me, this is code that should or could have been in the JRE
> in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
> likely only depend on java.base (it does today but this should be enforced
> with the Maven JDeps Plugin IMO.)
>
> If you look at StringUtils, you can then see how this class has grown into
> a giant. You can also then see why other related code like a fancier
> String.replace() could creep in as StrSubstitutor and friends. Should
> variable interpolation have been in the JRE? Debatable, but it would be
> useful on top of Properties and ResourceBundle, one might argue; also handy
> for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly IMO
> -- have deprecated StrSubstitutor in Commons Lang in favor or its new home
> in Common

Re: [DISCUSS] new component for timing?

[Gary Gregory]

On Wed, Feb 28, 2018 at 6:35 AM, Gilles 
wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new LANG
>> functionality on top of the StopWatch class, the issue has been raise as
>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons- component.
>>
>> We would like to take the discussion to the list for this, and see what
>> everyone thinks.
>>
>> The StackWatch provides for tracking nested timings backed by StopWatch.
>> You can start the watch, and start and stop multiple timings through the
>> call stack. Each timing is named and tag and has it’s own time.
>> You can visit all the timings, perhaps using the tags to filter when you
>> are done.  Please see the PR/Jira for more details.  You should look at
>> both, since the review has been split between the two.
>>
>> If not LANG, then where?  The commons-testing component has been
>> mentioned.  But this code is not ‘test’ code explicitly.  In my use case (
>> I wrote this for the Apache Metron project and thought it might be useful
>> here) it would not be test code, in the sense that it would be used in
>> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
>> REPL,
>> and perhaps in other runtime components.
>>
>
> Part of what makes a good component is that it does not dictate
> how and where applications should use it.
> The name "Testing" does not imply that its contents must be used
> within "test" scope.
>
> A utility such as "StackWatch" could be another tool to integrate
> in a unit test suite (e.g. to generate a more fine-grained timing
> report than Junit does).  Hence the module in which "StackWatch"
> will belong is to become a dependency of modules that target
> specific test framework (and that is true whether the former is
> defined within "Testing" or in another component).
>
> I would not want to pull in junit
>> or other dependencies with any component containing it.
>>
>
> +1
> Must be ensured by proper granularity of the modular design.
>
> If we put it in commons-testing ( which already has sub-modules which are
>> geared towards junit ) it may be confusing, even if the module is explicit
>> about purpose and keeping out junit dependent code ( or other testing
>> code).
>>
>
> Why would it be confusing?  The module will stand out on its own
> (artefact/description/doc/web site) and be more visible than yet
> another class in the already too large "Commons Lang".
>
> Also, besides the StackWatch, what else would go into the new target
>> component?  Would StopWatch move as well for example?
>>
>
> +1
> But creating a new component for two small classes can reasonably
> be argued as overkill.
> FTR: I was asked to collect the sampling utilities within a
> module of "Commons RNG" even though it could have warranted its
> own component (being a plain "client" of the core functionality
> of [RNG]).  In the present case, "StackWatch" would belong to
> "core" utilities of "Testing" that are pulled (along with other
> dependencies by the more specific modules.
>

I would ask all of us to step back for a moment and consider the big
picture.

Specifically, what do you consider the mandate or guidelines for Commons
Lang to be? For me, this is code that should or could have been in the JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
likely only depend on java.base (it does today but this should be enforced
with the Maven JDeps Plugin IMO.)

If you look at StringUtils, you can then see how this class has grown into
a giant. You can also then see why other related code like a fancier
String.replace() could creep in as StrSubstitutor and friends. Should
variable interpolation have been in the JRE? Debatable, but it would be
useful on top of Properties and ResourceBundle, one might argue; also handy
for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly IMO
-- have deprecated StrSubstitutor in Commons Lang in favor or its new home
in Commons Text, where is has evolved further.

In my view, StopWatch and now StackWatch, do not belong in the JRE or
Commons Lang. It should sit slightly above that level. Where, is the
question.

Commons Testing for Stop/StackWatch does not seen quite right to me. I
could see a new Commons Timing or a more general Commons Measurement; with
a mandate NOT to overlap with Joda-Time and java.time.

Gary




> Gilles
>
>
>> https://issues.apache.org/jira/browse/LANG-1373
>>
>> > atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>> tabpanel&focusedCommentId=16377279#comment-16377279>
>> https://github.com/apache/commons-lang/pull/311
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] new component for timing?

[Gilles]

Hello.

On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:

Hi,

In the course of working through my pull request for adding new LANG
functionality on top of the StopWatch class, the issue has been raise 
as to

if this functionality is ‘common’ or should
be placed in a more specialized commons- component.

We would like to take the discussion to the list for this, and see 
what

everyone thinks.

The StackWatch provides for tracking nested timings backed by 
StopWatch.
You can start the watch, and start and stop multiple timings through 
the

call stack. Each timing is named and tag and has it’s own time.
You can visit all the timings, perhaps using the tags to filter when 
you
are done.  Please see the PR/Jira for more details.  You should look 
at

both, since the review has been split between the two.

If not LANG, then where?  The commons-testing component has been
mentioned.  But this code is not ‘test’ code explicitly.  In my use 
case (
I wrote this for the Apache Metron project and thought it might be 
useful
here) it would not be test code, in the sense that it would be used 
in
‘test’ scope in mvn.  Rather it would be deployed in production, in a 
REPL,

and perhaps in other runtime components.


Part of what makes a good component is that it does not dictate
how and where applications should use it.
The name "Testing" does not imply that its contents must be used
within "test" scope.

A utility such as "StackWatch" could be another tool to integrate
in a unit test suite (e.g. to generate a more fine-grained timing
report than Junit does).  Hence the module in which "StackWatch"
will belong is to become a dependency of modules that target
specific test framework (and that is true whether the former is
defined within "Testing" or in another component).


I would not want to pull in junit
or other dependencies with any component containing it.


+1
Must be ensured by proper granularity of the modular design.

If we put it in commons-testing ( which already has sub-modules which 
are
geared towards junit ) it may be confusing, even if the module is 
explicit
about purpose and keeping out junit dependent code ( or other testing 
code).


Why would it be confusing?  The module will stand out on its own
(artefact/description/doc/web site) and be more visible than yet
another class in the already too large "Commons Lang".


Also, besides the StackWatch, what else would go into the new target
component?  Would StopWatch move as well for example?


+1
But creating a new component for two small classes can reasonably
be argued as overkill.
FTR: I was asked to collect the sampling utilities within a
module of "Commons RNG" even though it could have warranted its
own component (being a plain "client" of the core functionality
of [RNG]).  In the present case, "StackWatch" would belong to
"core" utilities of "Testing" that are pulled (along with other
dependencies by the more specific modules.

Gilles



https://issues.apache.org/jira/browse/LANG-1373


https://github.com/apache/commons-lang/pull/311



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org