(replies inline) On Mon, 20 Aug 2018, Jesse Glick wrote:
> On Fri, Aug 17, 2018 at 4:28 PM Daniel Beck <m...@beckweb.net> 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
signature.asc
Description: PGP signature
