Skip to content
This repository

Publishing frequency and recent packages (was: Publishers flooding the package list) #518

Open
pranavkm opened this Issue June 08, 2012 · 19 comments

6 participants

Pranav K Drew Miller Vince Panuccio Howard Dierking Tim Lovell-Smith Andrew Nurse
Pranav K
Collaborator

Continued from http://nuget.codeplex.com/discussions/358799

Hi,

I'm very concerned how package authors have taken it upon them selves to completely flood NuGet with new packages simply for visibility.

I'd like to make a request that packages are somehow grouped by author in the listing based on some timed interval.

Take this for example: http://nuget.org/packages/XAct.Runtime.InteropServices

There may very well be valid reason for having a release cycle like this but it drowns out other packages.

Just a suggestion.

Pranav K
Collaborator

Out of curiosity, why do you flooding affects visibility of packages?

Drew Miller
Vince Panuccio
vincpa commented June 11, 2012

When I visit NuGet and I sort packages by date published, what I'm looking for are new packages or updates to existing ones. Instead what I see is a flood of minor updates from the same publisher.

I'm just suggesting that there should be some sort of limitation or even a grouping so the publisher only appears once per day.

Vince Panuccio
vincpa commented June 14, 2012

I'm happy to close this issue. I just thought I'd make a suggestion to something I considered an "issue" :).

Drew Miller

Don't mean to be dimissive @vincpa, I just want to understand the problem. I'm confused because you should only see a single version of a given package in the results, not a flood of different versions for a given package. Can give us the URL of a search with the bad results?

Drew Miller

Nevermind @vincpa, I just saw there was a link at the top to an example.

Drew Miller

@vincpa That link above (http://nuget.org/packages/XAct.Runtime.InteropServices) is a package details page, so you would expect to see all the versions for that package. That particular package does have a lot of versions (and we should be paging them), but they are sorted by version order so you see the most recent first. They aren't interfering with seeing other packages, because that page only shows data for a single package. Does that make sense?

Vince Panuccio
vincpa commented June 15, 2012

The link I provided illustrates how many times a package is released for this particular publisher. It's not this one package, if you take a look at all their available packages (http://nuget.org/packages?q=XAct) you'll see a listing of items which are pushed to NuGet and usually all on the same day and every two or so days. It pretty much drowns out other packages from the listing.

I'm sure there are good reasons for these updates and I'm not saying this is bad, but I think it would be nice to group all packages psuhed by a publisher in a 24 hours period. Perhaps it appears differently in the listing?

Drew Miller

Gotcha. So, the frequency they update the packages wouldn't change how many results they have in that query; each one of those is a different package. They have lots of packages, but we're only showing the latest version of each in the listing. Even if they had only ever released a single package of each, those results would look the same. So, the problem here isn't so much how often they update, but the fact that they have lots and lots of packages. Just glancing at them, them modularity seems reasonable. We wouldn't want to collapse them, because while these packages are all potentially related, there are plenty of package owners that have lots of unrelated packages. We could potentially give package owners some way to indicate that multiple packages are part of a set, but I'm not sure we have enough people doing this that it would be worth the trouble.

Given that we can't really safely collapse potentially unrelated packages of a single owner, how do you think we might improve this?

Vince Panuccio
vincpa commented June 15, 2012
Howard Dierking

In the instance referenced here, it looks like CI builds are being pushed directly to NuGet.org. Along those lines, we may want to consider whether nuget.org is the right place for directly pushing CI builds like this. Additionally, while we haven't seen it exploited, we should remain aware of a spam-like attack vector on nuget.org.

Tim Lovell-Smith
Collaborator

data point - CI builds are still being pushed directly to nuget.org. For the 'show packages by recentness' option, can we mitigate that for some CI scenarios by ignoring packages which are marked as prerelease?

Tim Lovell-Smith
Collaborator

The prelease idea - maybe not worth it.
Here's an example package where they mark it as prerelease: https://nuget.org/packages/NServiceBus.Unity/
Here's an example package where they don't: https://nuget.org/packages/OxyPlot.WindowsForms/

Vince Panuccio

Here's another example. Take a look at this listing sorted by date. http://nuget.org/packages?q=&prerelease=&sortOrder=package-created

The publisher joliver has pretty much consumed much of the results. What I'm proposing is that we group all of jolivers packages in to a single result and somehow convey the packages in that result.

Makes discovering new packages easier.

Tim Lovell-Smith
Collaborator

I see. That case didn't look like CI, it looked like just one package author doing a bulk update of a set of related packages, which can make sense to do.

Vince Panuccio

Does is need to take up more than half of the search results though? All I'm suggesting is that mass updates like that are grouped in to one result which can be expanded.

Andrew Nurse
Collaborator

Recent it recent. I think that grouping mass updates might be interesting, but it's a low priority. Moving to Unscheduled. PRs would be reviewed.

Tim Lovell-Smith
Collaborator

Did this issue have anything to do with terms of use?

Vince Panuccio
vincpa commented June 03, 2013

Nothing to do with terms of use. Just a suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.