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