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

[pranavkm]

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]

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

[half-ogre]

Where does this surface outside the package details page?

[badmotorfinger]

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.

[badmotorfinger]

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?

[badmotorfinger]

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?

[badmotorfinger]

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: https://github.com/NuGet/NuGetGallery/issues/518#issuecomment-6351179

[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]

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]

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/

[badmotorfinger]

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]

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.

[badmotorfinger]

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.

[analogrelay]

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]

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

[badmotorfinger]

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

[analogrelay]

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