Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The "homepage" field in metadata should be a strong recommendation #938

Closed
plague006 opened this issue May 21, 2015 · 9 comments
Closed
Labels
Policy Issues with our policy

Comments

@plague006
Copy link
Contributor

#60 #837 #909 All have suggestions along the lines of "CKAN should inform users when a mod upgrade will break current saves". I agree that in a perfect world that would be a great feature, but we're not in that world. The strength of CKAN is that mod authors don't have to micromanage anything to stay up to date with the system: it's what (imo) allowed for the large adoption it received. Creating a "breaks saves" field would be incredibly burdensome to authors and/or metadata maintainers since they would have to manually check every single mod's changelogs (if documented) and forum threads/support forums (if the save break was undocumented). I don't think that's a reasonable expectation.

My proposal is that we make the "homepage" field a strong recommendation (ideally would be a require but some small libraries don't have homepages) and shift the burden to the end user. I'm not a huge fan of making users do their own work (it's one of the strengths of CKAN), but given that there's no standard whatsoever for changelogs (not even all mods have them), I think it's the best solution.

On the implementation side of things: I'm currently working on getting homepages for existing mods that currently lack them and have integrated homepages into the core steps of https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN

From the more technical side: Maybe if whatever bot checks metadata on CKAN's side could throw up a warning when there's no homepage set so that it can be remedied before hitting the system? And/or a warning on the user side when they first run CKAN (or when CKAN updates) that the program can't detect save-breaks and that users should check the homepages for changelogs?

As I mentioned none of this is ideal, but I think the options are:

  • radically slow down the automated update process while humans manually check forum threads and changelogs and then edit metadata accordingly
  • make some backend changes to ensure users can find the information they need, and inform them that they need to be diligent with updates
@Dazpoet
Copy link
Member

Dazpoet commented May 21, 2015

I have strong doubts any user out there clicks the forum link prior to updating their mods, if such users acctually exist I'd guess they're a very small minority. Even with a warning on startup/update I still don't think many users would check all homepages, I know I wouldn't. The best solution would probably be a unified system where every mod author out there used semver or some other system which easily distinguish breaking changes, but I find that about as plausible as users caring about reading homepages :/

As you mention users have adopted CKAN because it is easy and requires little interaction save from clicking install on chosen mods and updating them. I think this is the reason why earlier suggestions have focused on metadata fixes rather than fixes which require user interaction seeing as the latter is not something the user expects from CKAN. It makes me wonder how other packagemanagers handles this kind of situation, does this kind of problem even exist for other packagemanagers?

As for setting homepages fields in the startup guides I'm not at all a fan of hardcoding anything that doesn't need hardcoding. Why should we hardcode a homepage field, nor even recommend such a thing, into .netkan files pointed towards KerbalStuff where we fetch homepage information supplied by the author? Maybe a note to add it if, and only if, no homepage information is available on kerbalstuff?

@erendrake
Copy link

If i ever know im going to break saves with an update i will use the semver practice of updating the major version of my mod. (eg v0.17.0 to v1.0.0). it seems that maybe CKAN could give us a flag in our config for "semver compliant" and we could manage when the user would get a warning "this update might eat your saves!"

EDIT: what @Dazpoet said :)

@plague006
Copy link
Contributor Author

Fair enough, closing this since other issues address this issue better.

@Dazpoet
Copy link
Member

Dazpoet commented May 21, 2015

I acctually really like the semver compliant field idea. Although I'd guess not many modders use nor even care about such a thing there might be many enough out there that it'd be worth considering? If CKAN keeps growing the existance of such a field might be enough to warrant interest? I think there might be other issues somewhere in the CKAN repositories dealing with semver stuff aswell.

I could agree that manually updating savebreaking stuff is annoying and it wouldn't be humanly possible to properly add it to all mods the second a new version hits but we're already seeing a trend of more and more users helping out with metadata so maybe reports would at least help us point to what needs updating.

I think the major problem with all solutions warning users for savebreaking changes is that if it only cover some mods users are bound to rage when they install a savebreaking update and don't get a warning. A hard question to tackle indeed!

@mgsdk
Copy link
Contributor

mgsdk commented May 21, 2015

I don't have any clear ideas for save-breaking resolutions, it is a difficult issue, but I support changing the wording to strongly suggest people to supply us with homepages. I know that we in many cases scrape them from the metadata source, but there have been cases where they are missing, and it is an easy way to get more information about mods.

Checking for the homepage tag in the bot generated .ckan files before merging would and adding it to the .netkan when it is missing would, in my opinion, be a good idea.

@Dazpoet
Copy link
Member

Dazpoet commented May 21, 2015

Adding it directly to the guide for github and "other hosting solutions" is indeed a good idea, why pet peeve is only with kerbalstuff where we can scrape it (if it exists).

Having the check on the generated .ckan files sounds like a good solution since it could save us from hardcoding unecessary things. How would this be presented to the user though? Can Jenkins (Travis?) present a commit as "we recommend you update X" rather than a hard fail (red x) in a good way since I think hard fails will be confusing to users and might send them looking for missing commas rather than considering that they should add a homepage field, or do I just have way to little trust in contributors?

@Dazpoet Dazpoet reopened this May 21, 2015
@plague006
Copy link
Contributor Author

kerbalstuff where we can scrape it (if it exists)

In cases where no homepage exists in the KS data, can the bots be made to generate the KS link as the homepage?

@pjf
Copy link
Member

pjf commented May 22, 2015

Save-breaking mods

As mentioned in @plague006's opening, #60 is definitely the relevant issue here, and the ability to mark a change as save-breaking is something we've wanted for some time.

However I don't think we can trust humans to read homepages or changelogs, and I think it would be counter-productive to expect them to. One of the reasons for the CKAN being so successful is that it means mods are no longer installed by getting a human to follow the instructions another human has written.

I can think of the following as being particularly useful:

  1. The breaks suggestion in Spec: Indicate when an upgrade will be save-breaking. #60. I'd even be inclined to propose an extension to the KSP-AVC spec which lets authors embed compatibility info, which means our indexing bot can spot when a new release is savegame-breaking.
  2. Automatic backups of the user's save directory whenever their mods change. I've taken this for granted since I manage my KSP installs using git, but this would at least give players a safety-net so they can roll-back if things go wrong.

Of these two, 1. is the most elegant, and I think something which is worth pursuing, especially since KSP-AVC version files are fairly widely used. 2. is a lot harder than it looks; while we'd normally make a save backup before any CKAN transaction, a naive implementation would have us making multiple backup saves which are identical. We'd want to avoid that, and also provide both human and machine readable documents inside the saves that indicate what mods were installed at the time it was made. I can forsee lots of ways we can get this wrong (resulting in us dealing with an increased support load), although I still think automatic save versioning would be good to have.

Homepage recommendations

In a similar way to the CPAN having the CPAN Testing Service (CPANTS) assigning "kwalitee" ratings, I think we could do the same for CKAN metadata. This would ideally be a separate project, but mods which include KSP-AVC support, are auto-indexed by the NetKAN bot, and include rich metadata on things like homepages and bugtrackers can get a higher "score" than those which don't. While this doesn't have any technical impact on the network at all, it gives mod authors and metadata maintainers simple achievements to get up to "full metadata health".

If we (or anyone else) were to do this, I'd try to avoid metadata health being dependent upon a particular upstream provider of metadata. We don't want to push people into using KS or github, although we almost certainly do wish to add greater support for indexing from KSP-AVC and other distributed versioning systems.

@pjf pjf added Policy Issues with our policy ★☆☆ labels May 22, 2015
@plague006
Copy link
Contributor Author

Just want to mention that #1254 basically negates all of my qualms with missing homepages. While it's still possible to have a mod added with no way to get a homepage, it's very rare.

@pjf pjf removed the ★☆☆ label Jul 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Policy Issues with our policy
Projects
None yet
Development

No branches or pull requests

5 participants