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 <ottobackwa...@gmail.com>
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" <ottobackwa...@gmail.com> 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 <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
> >
>
