Discuss usefulness of global /cvs page

+1 to remove the pager here.

I'd absolutely support losing the pager and maybe just showing the most recent 10-15 commits. I have difficulty imagining a serious use case for providing the full dataset here. Statistics gathering by some third party, maybe...but if it's really that important, they can just ask us to run the analytics for them directly against the db.

This page will become even MORE useless after the Git migration. Listing a river of Git commits (that's commits, not pushes) is the very definition of meaningless, chaotic crap. We're preserving it for the sake of 1:1 feature parity, but I'm really hoping to replace it with a snapshot of recent pushes as soon as we can, as that'll be considerably more interesting to look at. Or at the very least, it won't be a storm of indecipherable noise.

I have found it useful on many occasions; for example, recently I have been researching how people do install profiles, so the cvs pages proved invaluable to quickly browse and pinpoint the best examples.

The only other alternative would have been to download all of them.

This is why repos like github have front ends; and have even enhanced them greatly in the recent past.

Victor Kane
http://awebfactory.com.ar

I used to have Yahoo Pipes mining data for cross-project translation (.po file) submission activity. Now that we remove .po files from the project version control space, I don't have a use case for it. Basically, I imagine people mining cross-project activity based on some criteria would need this page/feed, I don't know of any ATM.

Loosing the paging doesn't make the feed useless. The feed only contains the first few commits anyway.

I like the concept of a "what's going on right now" kind of page but I'm not sure that the /cvs page really fits that description in its current incarnation. An alternate example is Redmine's (http://www.redmine.org/projects/redmine/activity) which just shows activity related to the application itself (obviously it is also different because Redmine doesn't have the kind of contrib environment that we have). I think this could give a better feel for what is happening with the core project instead of a stream of a sometimes disjointed hyperactive commits (I'm pointing at myself here) which doesn't have bearing on the quality or direction of Drupal itself.

I could imagine having a Drupal core commits specific landing page with links off to the active contrib modules and active committers but I'm unclear if that addresses either performance or usefulness concerns.

In terms of low hanging fruit, remove the pager if that solves significant performance concerns.

I think that the usefulness of that page is limited to the blocks shown there.
I don't think anybody goes there thinking let's see which projects had commits, recently. It seems more probable somebody wants to compare specific projects, to see which one should be used in a website, for example; checking which project had the most recent commits can help in decide which project to choose (when somebody is undecided between two or more specific projects), but that can be done looking at the data available from the project page.

I agree with most here, in that I don't think the pager is needed. In fact, I didn't know it existed until I saw the cool live map on the front page showing where recent commits where coming from and by whom.

Personally, I have no use for anything at /cvs (even page 1) so long as the project-specific feeds are maintained.

I use it all the time, but certainly don't need the pager.

And the reality is when git happens I won't need it any more. I just use it to get the commit ID after I make a commit, so I can paste it into the issue. When git comes, I'll already have the hash and won't need to get it from here.

I do use that page and the feed quite a bit, but it seems that I'm one of relatively few people who do based on looking at Google Analytics (see attached). If we removed the pager it seems we'd piss off a couple thousand people a month.

Killes clarified in irc that this is really just about /cvs and the /cvs?page= pages. We can still keep /project/cvs/NID and /project/cvs/NID?page= pages.

I think that probably will be OK.

I use it all the time, but could live without the pager. Even better is a pager capped at 100 records or something.

I always use /project/cvs pages, never used /cvs pages.

I've now added anything but the first /cvs page to the disallow list in robots.txt. THis is mainly for testing since thes pages will die anyway when we deploy git instead.

considering this fixed.

I just found this issue. I regularly saw this page, but the pager is not necessary. Now that it it not accessible (or removed?), I miss it, as I am wondering about other's commits.