>>>Can I start a discussion with ASF legal@, infra@ and the rest about how >> an Apache project could get some metrics or add "telemetry". >>Yes go ahead
I've opened https://issues.apache.org/jira/browse/INFRA-15406 I'll also open another issue with legal@ about metrics. >>>>2. Speed of development >>>> [...] >>>> But another thing, did you have a look at the frequency at which user >>>> upgrade ? >>>Where would I see such info? >> >Not that simple, it is more something I see from our work and the answers > we provide on : > - stackoverflow questions > > - the user mailing list > > And also https://jmeter-plugins.org/ => Metrics are better IMO since user > see that upgrades exist I see. It's sad to depend on jmeter-plugins.org, a non-Apache site, for such important information, no? >>>I have to prepare multiple patches from YaMeter. The code is also using >> some NetBeans Platform frameworks so I would have to un-tangle those and >> use simpler things if I have to port it to JMeter as a plugin or something. >> >I'd be happy if you could but anyway good luck with it. I'm not trying to make money off YaMeter, it's all free, no ads, no nothing. In a way, it's how I envision JMeter should look like. Not just as an UI, but as a modular app with a plugin manager, updates, cloud friendly, etc. Preparing individual patches for PRs just takes an ungodly amount of time. >>>This might be an interesting exercise. >>What sub-set of JMeter could we provide in the 1st release of a web UI? >> Just some HTTP request and a visualization would be a great start for users >> (this is where some metrics would help to see what users use most). >> >I don't know about that, what framework would you be using ? What > architecture ? > I think this needs some architectural work to handle Plugins. > How would be provide the 2 UIs together ? > I feel it's a huge piece of work, but I am ready to go for it provided we > have some strong engagement from volunteers for some time. It's huge only if you want to port the entire JMeter to the web in a single release. The 1st web release has to be a super-lite JMeter. It's important to start it and give a direction. If the users like it and it's any good we can grow more rapidly. >>>How about JMeter provides a Plugin Manager out of the box in the next >> release? >> What's so complex about it? >> >Nothing, if you have a plan, go ahead, I'll be happy to merge PRs. OK, I will try to do this. > Very bad thinking IMO, we could for example work on more frequent releases > and an improvements of the release process. I agree. >For me it's not a prioritary problem frankly. I see the current > architecture which is simple provides enough power and this is proven by > the number of plugins in the market. > Unless you have a full backward compat solution, I'm for now not convinced > about the benefit vs the sum of problems we'll face. Backward compatibility seems doable. Even if it's not perfect, it will be a good way to see which plugins the users have :-) > If we go for providing a Cloud solution, I think JCloud should be used. > I don't want to privilege one Cloud provider unless we have some > involvement from that provider of course. I'm unsure about JCloud. Even the official client SDKs are under development sometimes so what are the chances of JCloud being better? OTOH, JCloud seems to just talk to the REST endpoints which is something that sounds logical. So, they are not a wrapper on top of multiple SDKs, just REST clients. --emi
