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 <ottobackwa...@gmail.com>
> To: Romain Manni-Bucau <rmannibu...@gmail.com>; 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" <gil...@harfang.homelinux.org> a
> écrit :
>
>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>
>>> Le 17 mars 2018 11:49, "Gilles" <gil...@harfang.homelinux.org> 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 <ottobackwa...@gmail.com>:
>>>>
>>>> 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 +0000, 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" <ottobackwa...@gmail.com>
> 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-xxxx, 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
>>>>> >> <oliver.he...@oliver-heger.de>
>>>>> >> 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 <boa...@gmail.com>
>>>>>
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
