From dev-return-166783-archive-asf-public=cust-asf.ponee.io@commons.apache.org Sat Mar 17 16:24:38 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 7D764180652 for ; Sat, 17 Mar 2018 16:24:37 +0100 (CET) Received: (qmail 45949 invoked by uid 500); 17 Mar 2018 15:24:31 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 45937 invoked by uid 99); 17 Mar 2018 15:24:30 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Mar 2018 15:24:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 546801A028E for ; Sat, 17 Mar 2018 15:24:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.88 X-Spam-Level: ** X-Spam-Status: No, score=2.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id N_3bIVsxjMdy for ; Sat, 17 Mar 2018 15:24:26 +0000 (UTC) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id B424E5F2EC for ; Sat, 17 Mar 2018 15:24:25 +0000 (UTC) Received: by mail-yw0-f181.google.com with SMTP id w12so8894969ywa.8 for ; Sat, 17 Mar 2018 08:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EWc3Fnp59S3Vqb4aUqmEUBML59scb35Dx1oXrSM4tWg=; b=nWF3ie0mcrh/ZM9TqANBPs7yCOcY/14DEt5kct3RAMs4rRN05HQUKV7mJlrq/2crSn KD7wEg2xSgOa8k8b8TI5LIBGgCNDkIrmIHczfqVj46XnocyKtAuqXp9O+xw0YYZ9GKeO 7935YJm4sRCMCRkbI5YJrxPmcd0F89v/+6Bd9VvQ7HCTK52nKyInpw5enIDVqJ+IxIgF o2yhHlDPSYRAnickjjbHUlquSwF8couPXJsaGjjGpBXaO5an4uxzDW5NQBVLs1QNFarx 9jZgNW+7ItqI90wcI61/JDnnxa8UtaHqJAgRlZvY9lJS2r+zVyDMEymrEFGHegcA8JZh X34w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EWc3Fnp59S3Vqb4aUqmEUBML59scb35Dx1oXrSM4tWg=; b=pqKmNYMXy1EC2C3TEJo6ut94bd2QUc8U+GSdFNvox2asasH1UIXFWKjyD9IjaqBS8M SPW4nLu8feO6W8omlNhx+yhtByxn7xIMISJCz1t95sZXYTKrZlrWRpBrHTW4OkpIM51a c+TExSxPy5JHI2uVtELTLKvy7jBwhulgPxhOb3YCfBJo5xDw7REUfQbPSx2yvxa7Ywuc Q9Dwo0NF31mbK3CaXbz3Nb6pisEiZCSxFslq57/D4iIPhUbcDQL4u3DvqEL9QEs16CAP fHWM5CejdpXgCn0k9vj88XLsvKcrZPw2dwWa1UkMpflpRooPkjw2G2RB0lFvOIoSh/OC KgzA== X-Gm-Message-State: AElRT7FHE74vd3brtY+n1cHU16rtZHtpetxGKyAWeWB1LH+X0eB6+zdx x/Jk9PklV9DWyv2fgMXf8GUnckNLyjh5iAgNJ0M= X-Google-Smtp-Source: AG47ELsy9rbeRsPmHN5JBU09R8X1+NAEjEFNZw1wwtP1t1vcn9hSljqtRpmLbBHAZxmAZksL46oQ7SS0AP8Uql1cxV0= X-Received: by 2002:a25:bec7:: with SMTP id k7-v6mr3632971ybm.413.1521300258992; Sat, 17 Mar 2018 08:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:6dd4:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 08:24:18 -0700 (PDT) Received: by 2002:a25:6dd4:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 08:24:18 -0700 (PDT) In-Reply-To: <228d9b4ad5891007531fafd7d59b45e9@scarlet.be> References: <4b5f5b5351e493ca4002eb1a101d2c3d@scarlet.be> <8c1e8507-25b0-6cca-6cbb-57c62472161c@oliver-heger.de> <5426fb78f4343cba9cd8c7c2a91d275c@scarlet.be> <228d9b4ad5891007531fafd7d59b45e9@scarlet.be> From: Romain Manni-Bucau Date: Sat, 17 Mar 2018 16:24:18 +0100 Message-ID: Subject: Re: [DISCUSS] new component for timing? To: Commons Developers List Content-Type: multipart/alternative; boundary="00000000000088b84a05679d51f8" --00000000000088b84a05679d51f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A9crit= : > On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote: > >> Le 17 mars 2018 11:49, "Gilles" a =C3=A9c= rit : >> >> 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=E2=80=99ll be happy t= o do the >>> >>>> work ( although I=E2=80=99ll need help of course ). >>>> I guess I=E2=80=99m the straw that broke the camel=E2=80=99s back then= ? ;) >>>> >>>> >>>> >>>> >>>> On March 15, 2018 at 08:09:45, Gilles (gilles@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 =E2=80=98co= re=E2=80=99 >>>> > 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 wor= th >>> 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 fa= il >>> to see. >>> My experience - coming exactly from here - tends to make me think commo= ns >>> will not fit very long or will not bring enough value pretty quickly bu= t >>> 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 =E2=80=98too big=E2=80=99 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=E2=80=99t 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 (gilles@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" wrote= : >>>> >> >>>> >> So, could think about commons-misc or something? >>>> >> I don=E2=80=99t 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 scop= e >>>> >> of >>>> >> commons-xxxx, but don=E2=80=99t 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 (boards@gmail.com) wrote: >>>> >> >>>> >> On 2 March 2018 at 13:31, Oliver Heger >>>> >> >>>> >> wrote: >>>> >>> >>>> >>> One other suggestion: It was stated in the past that the concurren= t >>>> >>> 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-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --00000000000088b84a05679d51f8--