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

Closed
pranavkm opened this Issue Jun 8, 2012 · 20 comments

Projects

None yet

6 participants

@pranavkm
Member
pranavkm commented Jun 8, 2012

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.

@pranavkm
Member
pranavkm commented Jun 8, 2012

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

@half-ogre

Where does this surface outside the package details page?

@vincpa
vincpa commented Jun 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.

@vincpa
vincpa commented Jun 14, 2012

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

@half-ogre

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?

@half-ogre

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

@half-ogre

@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?

@vincpa
vincpa commented Jun 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?

@half-ogre

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?

@vincpa
vincpa commented Jun 16, 2012

No not quite. It's not about updating the same package 20 times a day, it's
about a publisher listing several (unrelated or related) packages a day.

It is possible to collapse related and unrelated packages if you group them
all under a publisher within a 24 hour period. Not sure what the UI would
look like, maybe like a stack of cards that expands when it's clicked.

On 15 June 2012 17:48, Drew Miller <
reply@reply.github.com

wrote:

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?


Reply to this email directly or view it on GitHub:
#518 (comment)

@howarddierking

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.

@TimLovellSmith
Member

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?

@TimLovellSmith
Member

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/

@vincpa
vincpa commented Feb 13, 2013

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.

@TimLovellSmith
Member

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.

@vincpa
vincpa commented Feb 13, 2013

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.

@anurse
Member
anurse commented Feb 22, 2013

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.

@TimLovellSmith
Member

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

@vincpa
vincpa commented Jun 4, 2013

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

@anurse
Member
anurse commented May 21, 2014

Closing this, as we haven't heard anything in a while.

@anurse anurse closed this May 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment