3.0 release

[Joel Koshy]

Hi - any estimate of when metrics-core 3.* will be released and made available in maven central?

Thanks,

Joel

[Coda Hale]

Sorry, no.

---
Coda Hale
http://codahale.com

[Joel Koshy]

I see - we are mainly interested in some CSV reporter fixes that went in (https://github.com/codahale/metrics/pull/225). Is HEAD stable? If not, is there a specific revision in 3.0.0 after that fix that you would recommend as being stable for production use?

Thanks,

Joel

[Erik van Oosten]

To ask it more broadly: what are your future plans for Metrics?

Kind regards,
Erik.

Op 04-10-12 05:03, Coda Hale schreef:

--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

[Coda Hale]

I don't have a roadmap, sorry.

---
Coda Hale
http://codahale.com

[Otis Gospodnetic]

Coda,

But would you say you will release when enough resolved issues accumulate?

Otis

--

Performance Monitoring - http://sematext.com/spm/index.html

[Erik van Oosten]

I don't mean roadmap, more something like your ambitions.

I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).

Kind regards,
    Erik.


Op 09-10-12 01:11, Coda Hale schreef:

[Coda Hale]

For 3.0.0, I'd like to accomplish the following:

• make JmxReporter not such a special snowflake
• figure out a decent API which doesn't revolve around static MetricsRegistry instances
• swap out the accordion constructors for builders
• fold in Hibernate support
• figure out if there's a simpler/easier naming scheme

---
Coda Hale
http://codahale.com

[Erik van Oosten]

Thanks.

Regarding the first 3 bullets: that is ambitious. I had similar challenges for my Sentries library. I tried to come up with something better as well, but in the end I copied your approach almost exactly.

What I did do differently was hide the naming scheme. Every sentry (the metric equivalent in Sentries) has an 'owner' class, a resource name and a type-name (e.g. "rate-limiter"). The three together uniquely name a sentry and also make up the bean name for JMX.

Kind regards,
    Erik.

On 11-10-12 21:26, Coda Hale wrote:

For 3.0.0, I'd like to accomplish the following:

• make JmxReporter not such a special snowflake
• figure out a decent API which doesn't revolve around static MetricsRegistry instances
• swap out the accordion constructors for builders
• fold in Hibernate support
• figure out if there's a simpler/easier naming scheme

---
Coda Hale
http://codahale.com

On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:

I don't mean roadmap, more something like your ambitions.

[Andrew McDaniel]

Hi,

Sorry to resurrect a fairly old topic, but I have a a couple questions about the timing of the 3.0 release. 

I started work today on a SLF4J report to report metrics values through the SLF4J framework, similar to how the ConsoleReporter and CsvReporter classes work, but I need to use SLF4J calls (instead of just dumping to a PrintStream) for this project I'm working on as part of a log and health aggregation across instances. I think generally this would also be useful as an option for reporting, since the slf4j framework is pretty widely deployed and people might not want to always dump all the metric data to the raw console, so I'm willing to open a pull request if there's interest when I'm done. 

The problem is that the API and public method names are currently incompatible between the last "stable" release of 2.2.0, and the current 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out and/or too unstable to warrant porting the reporter back to the 2.x code as well?

[Alex Rovner]

First of all, I would like to thank all the contributors that created such a great metrics library. 

It would be great to keep the momentum going on this library and I am sure there are good amount of people on this mailing list that are ready to help / contribute. I noticed that there have not been much activity in the code base in the last 3 month or so. Would be great to know what can we do as the community to help merge the outstanding pull requests / contribute to open issues etc.

Thanks

Alex

[Andrew McDaniel]

Go find where Coda is hiding and see if he's still alive. Pull requests have been piling up like an elderly person's mail and newspapers. :)

[Alex Rovner]

Should we fork the repo and continue on our own?

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "metrics-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/metrics-user/bLvMqaXTUM8/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to metrics-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Coda Hale]

Well, careful what you wish for. Metrics now has a lot less open issues.

The good news: I've had some time lately to play with all the various ideas I've had for simplifying the hell out of Metrics. Much of the 2.x line is scar tissue, where I did something weird in order to get something down the line to not suck (looking at you, Ganglia) or merged something without really looking at it, and the metrics-3 branch represents a substantially simpler way of doing things. It requires some compromises, but I think they're worth it.

The bad news: it's definitely not ready yet. Besides still needing to port over and unfuck Ganglia, Graphite, JDBI, Jetty, JVM, Log4j, Logback, and Servlet support, there are still some big issues I need to solve. These aren't really the sorts of problems which do best when crowdsourced, and right now I think it's a better use of my time to jump in and hack this stuff out rather than try to figure out who wants to do what, etc. Which leads me to…

The worst news: holy crap is my OSS governance bad. As much as I'd like to just work on Metrics all day (I don't, actually), it's not what I get paid to do. It's a hobby, and as a hobby it cuts into both my professional time and my personal time. This is one of the reasons I'm cutting modules left and right — if I don't directly care about something, it's gonna be way down in the "never get done" section of my to do list. I'm not sure what to do about this; punting Metrics into something like Apache just seems like a great way to kill it, but having it be my -20% project doesn't seem right either. I'm open to suggestions here.

And now, considering I have to wake up in 7 hours, I'm going to bed.

---
Coda Hale
http://codahale.com

--
You received this message because you are subscribed to the Google Groups "metrics-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user...@googlegroups.com.

[Justin Mason]

On Mon, Mar 11, 2013 at 6:23 AM, Coda Hale <coda...@gmail.com> wrote:
> The worst news: holy crap is my OSS governance bad. As much as I'd like to
> just work on Metrics all day (I don't, actually), it's not what I get paid
> to do. It's a hobby, and as a hobby it cuts into both my professional time
> and my personal time. This is one of the reasons I'm cutting modules left
> and right — if I don't directly care about something, it's gonna be way down
> in the "never get done" section of my to do list. I'm not sure what to do
> about this; punting Metrics into something like Apache just seems like a
> great way to kill it, but having it be my -20% project doesn't seem right
> either. I'm open to suggestions here.

Some random suggestions from the sidelines (not that I've been much
better in the past myself anyway! ;) --

* if there's a separate Foo integration library that can be extracted
into its own separate release or project, do it. Keep the core small
and tightly focussed on the stuff you care about (and can use and
test). So for example, break out metrics-ganglia into a separate
project with separate maintainership and a potentially slower release
schedule. Define good APIs for it to integrate against.

* If there's still a chunk of code you don't care about, and it's
logically separable but hard to separate at the code level, it may be
worth creating an API to allow it to be separated. (plugin APIs are a
good example of this)

* don't accept pull requests if they don't have good tests, so that
you can have good confidence that a green unit test run means
something is releasable.

* I'd actually think it'd be very cool to have an "Apache Metrics". ;)
but yeah, it's hard to keep up community momentum with a transfer to
the ASF unless you have a lot of time to get through incubation and a
strong community to start with...

You may already be doing most of these, I haven't been following the
project for long. Thanks for Metrics btw! It's proving to be a great
means of porting my metrics-driven habits to a new company with no
existing metrics infrastructure -- great to not have to reinvent such
a massive wheel...

--j.

[Otis Gospodnetic]

Hi,

7 hours sounds very nice from there I sit.  It's all relative. :)

Re Metrics and ASF - it may actually do well.  I suspect it would have an easy time attracting contributors and committers because it's so popular already and not some niche thing.  This means it could run through the Incubator.  This also means those modules can be on top of somebody else's todo list instead of being rejected for the completely realistic fear of being at the bottom of Coda's todo list.

My 2 sleepy pennies.

Otis

[Mårten Gustafson]

On Mon, Mar 11, 2013 at 7:23 AM, Coda Hale <coda...@gmail.com> wrote:
...

> The bad news: it's definitely not ready yet. Besides still needing to port
> over and unfuck Ganglia, Graphite, JDBI, Jetty, JVM, Log4j, Logback, and
> Servlet support, there are still some big issues I need to solve. These
> aren't really the sorts of problems which do best when crowdsourced, and
> right now I think it's a better use of my time to jump in and hack this
> stuff out rather than try to figure out who wants to do what, etc.

...

> in the "never get done" section of my to do list. I'm not sure what to do
> about this; punting Metrics into something like Apache just seems like a
> great way to kill it, but having it be my -20% project doesn't seem right
> either. I'm open to suggestions here.

I prefer a slow evolving Coda cultivated Github project over an Apache
project any day.

The code is straightforward, generally well written and very easy to
fork and patch for specific needs or use cases that doesn't fit the
Metrics world view. I've run custom, patched, versions in production
from time to time and don't find it all to troublesome.

For the short term, based on what Coda writes regarding the metrics-3
branch, my immediate thought is whether Coda could define the
"framework" and delegate individual components such as Ganglia,
Graphite etc to those willing to help and work with them through PRs.

Further down the road, after version 3, the "obvious" improvement to
me would be if a few people besides Coda had commit access which at
least would allow some higher merge throughput on PRs.



/mårten.

[Erik]

One of the options is to let someone else maintain the 2.x branch. This would ensure that there is still some room for small improvements while you are improving Metrics more fundamentally.

BTW, please no Apache.

Kind regards,
Erik.


Coda Hale <coda...@gmail.com>schreef: