kill project-usage-process.php and raw/daily db tables

I'm kinda mixed, personally I'd love to see both of these go away and something based on sampler added instead, but I don't know what our obligation is to anyone that still uses the old method (if anyone else ever did).

I don't know if we should try to do anything to solicit info from anyone else using project_usage module or not.

-1 to this. A requirement on Mongo and varnish is a huge PITA for mere mortals. I know for sure of at least one D6 Project* site using project_usage, and they're very happy with how simply it Just Works(tm). Maybe it's wrong to do a lot of work just for them, but if they're using it, others might be, too. And if all that stuff exists and works now, I don't see the huge problem in just porting it. It seems pretty straight-forward to port to D7. Am I missing a big piece of the puzzle here?

Question #1, do we use project-usage-process.php on d.o?
Question #2, do we know if *anyone* else uses this code?
Question #3, why would we port something into D7 that's crufty, old, and possibly decrepit which would force us to continue to maintain it as we have done in the past?

@hunmonk in #4, "...i'm opposed to wasting valuable developer time on something that barely benefits anybody. There are dozens of other things we could spend that time on that would be more beneficial for more people." THIS.

1) No.

2) Yes.

3) This isn't about hard-coded legacy field crap. This is about the two ways you can process usage stats on a site running project module. One is that as requests come in, we insert a row into a DB table, and then occasionally we go through and process that table. That's what has been provided by default in project_usage. We out grew that approach with the scale of Drupal.org, so we have our own custom thing that requires MongoDB and parsing varnish logs. Personally, I think it's an awfully high barrier to make people climb to use this functionality. This isn't about crufty/old vs. shiny/new, it's about simple/slow vs. complicated/fast.

But whatever. I agree this isn't worth spending much time on, and we've already spent more meta time on this debate than we'd save by ripping this out. It is fairly edge-case functionality, and if people want it, I guess they can jump through all the hoops to use MongoDB to get it.

So, that means we're ripping it out.

To summarize hunmonk:
* kill project-usage-process.php
* kill the {project_usage_raw} and {project_usage_day} tables
* kill all variables and UI that relate to either one of first two.

Is the patch in #1 good to go?

Tagging.