JEP draft for review at: https://github.com/jenkinsci/jep/pull/192
> On 21. Aug 2018, at 23:57, R. Tyler Croy <[email protected]> wrote: > > (replies inline) > > On Mon, 20 Aug 2018, Jesse Glick wrote: > >> On Fri, Aug 17, 2018 at 4:28 PM Daniel Beck <[email protected]> wrote: >>> When I first brought up this idea with Tyler a few months ago, IIRC the >>> response (from him and/or Baptiste) was there's nothing we can >>> realistically share. >> >> OK. I hope that changes at some point. > > > There are a couple key differences in requirements between what Evergreen is > doing, and what Daniel seeks: > > * Storage requirements: I have no intention on making promises around data > expiration with telemetry necessary for Evergreen. Some of the feature > development questions I would like to answer require data over a long > timeline in order to properly answer. My understanding of what Daniel is > proposing would be much more targeted and specific. > > * Point of observation: with Evergreen all telemetry collection, thus far, is > done intentionally from an _external_ point of view. In essence the > evergreen-client is what is observing a Jenkins instance outputs or makes > availalble to it, or to other consumers, like a standard monitoring tool. > This principle is fairly important to me, as I'm wary of a Schroedinger's > Jenkins problem, where instrumenting Jenkins causes differing behavior from > what other users of Jenkins core/plugins might encounter, thereby reducing > the value of the feedback we can provide to developers. > > My understanding of what Daniel seeks to do is a fairly tight integration > into some fairly key aspects of Jenkins core and related tooling. > Instrumentation which I doubt would ever be accessible to anything but the > innards of Jenkins itself. > > > Personally, I think both approaches are necessary for different reasons and > are > independently valid. > > I suggest keeping the scope for internal instrumentation small for now without > attempting to come up with the one-global-instrumentation-approach to solve > all > imaginable use-cases. I trust Daniel to implement something which can grow in > the future, and may provide a foothold for future instrumentation requirments. > > We have a tendency to imagine new requirements any time sommething like this > comes up, and ultimately burden the contributor with heaps of scope, leading > to > nothing ultimately being done. > > IMHO the scope here is narrow enough, so from my perspective, go for it > Daniel! > > > > Cheers > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/20180821215738.GA2292%40grape.lasagna.io. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/80C59548-858C-4502-9464-6D8C8F71D09E%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
