Opt In / Opt Out | Required changes to CKAN.

[VasVadum]

CKAN has officially become a threat to the community because mod author are beginning to change their mods over to All Rights Reserved in order to stop CKAN from listing. This will hurt modding in the long run, and cause potentially permanent damage if this ARR trend kicks on just to get back at CKAN for not allowing choice.

You need to change your de-listing policy immediately because I will not continue to support something that is going to ignore this immediate threat. It has been stated that when CKAN becomes opt in, most of this issue will go away and the people who are angry and wanted to de-list, are likely to no longer want to de-list.

So here is MY personal suggestion which is slightly getting some negative opinions against but I still think it is good for de-listed mods to help us manage everything in one place; If an author de-lists, you can grey their mod out in the program and still show the home page for users to click and go get the mod manually, also showing a version number on it and all that jazz. Instead of checkboxes or dashs where you would click to auto install/update a mod, place an X for a delisted mod. When a mod has an update, turn the "update" column X into a clickable button which brings you to the home page of the mod so that you can find the download URL. Make sure to make a note however for de-listed mods when a user clicks a home page button in one for the first time or an update button on one for the first time that it pops up an un-closable message that lasts for a minimum of 5 seconds; The author has requested that his or her mod not be downloadable via CKAN, so you must do this via his or her page. Please do not pester the mod author to change their listing status, it was their choice to make and they made it for whatever their reason was and they are even less likely to change their mind if people spam them with requests to list on CKAN.

This way I don't need to manage mods via browser bookmark folder, and can still find a mod via CKAN even if I can't install it via CKAN. I think an even better option for this though, is three versions of opt. Opt-In: Your mod is listed and downloadable via CKAN. Opt-List: Your mod is listed in CKAN but not downloadable. It can still notify of updates too. Opt-Out: Your mod is not listed in CKAN unless it is detected in your game install, and then it is marked red in CKAN with only the information found in the meta-data that the author has provided with his mod. (Or don't list at all, I suggest listing if installed because this would allow me to export a list of mods I use easily if I want to share that list with someone, particularly for diagnosing an issue.)

I also suggest that you include a method for authors to write their own meta-data. No more allowing non-authors to submit data to CKAN too. Authors must be the ones to submit their information to CKAN, and a file that comes with mods can correct any meta-data CKAN has on the mod. That's for another topic though I suppose as this one is specifically about opting in and out and the results of you not enabling it.

[TeddyDD]

@janbrohl Even simpler way is to change .ckan extension. CKAN client detects only *.ckan (like all .kerbalstuff packages)

@Blu3wolf You are right I suppose.

[VasVadum]

I very greatly require CKAN to manage my mods because there are just too many mods to manage manually. However, CKAN should not be doing things against an author's will, regardless of a mod's license.

I'm fine with default supporting adding mods that have an open license. But if an author comes by and asks to be de-listed, then his request should be honored regardless of the reasons for wanting to be de-listed.

I still hope for the method of "no installation" listing that I had mentioned "Opt List" so that I can still find mods via CKAN even if I have to go to the author's page to install it. I just don't want to be forced to always check a browser folder of bookmarks to find out if a mod updated or not and Mini AVC is a dumb way to check for updates (because you have to run the game first instead of checking prior to launching the game).

With the current system, authors may end up closing the mods behind an ARR and prevent anyone from sharing and using code to make better mods in the future or should a mod author suddenly disappear, his great work will die too because he had locked it behind ARR to prevent CKAN from touching it.

I'd also still like meta files within the zip file to be able to correct CKAN information about a mod too, instead of trusting whoever added the mod to CKAN in the first place. This includes a "de-list my mod" line which would auto-de-list it if CKAN scans the zip and finds that line in the specified file, preventing people from listing it again after its been de-listed. I'm not sure how people list a mod to begin with but this would make de-listing automatic and in complete control of the author where he doesn't need to contact anyone to get the mod de-listed.

---

I skipped a lot of conversation here because I got a headache and pain in one eye so bleh. I skimmed through though. I had to turn off email notifications too cause I got over 10 emails in less than 10 minutes.. -.-

[godarklight]

I should probably weigh in as a mod developer that generally sits on the CKAN side, all of this has turned into a much bigger deal than it otherwise needed to be. @ferram4 and Mr "Community Friendly Alternative" did the correct thing making their mods ARR as that more accurately reflects their position on licencing.

That should have been the end of this whole issue, but it now seems like enough damage has been done that changing the policy to allow the removal of mods would probably be a good idea at this point.

Modders: I'd still advise against doing so though, all you are doing is annoying players who use your mod. Remember, although CKAN has problems (metadata checking, hanging), it doesn't mess up anywhere near as spectacular as a player installing manually can :P

[DuoDex]

Or use a timebombed license: ARR until X condition is fulfilled, at which point it goes to [FOSS license].

[BobPalmer]

@DuoDex - Which is what I put my assets under.

[Cphoenix]

@Cphoenix "Prohibited" is intended to serve as a way for an author to explicitly say "No, I don't support CKAN at all, please install my mods using my preferred distribution method(s)." There is no technical way to actually enforce it (aside from DRM of some kind, and nobody wants that), but the intent is that the author's preference is made very clear and cannot be disregarded by means of "user is conditioned to just click OK without reading the prompt". I don't like it either, but it seems it a necessary option.

@cphoenix It's not a matter of legal standing, it's a matter of common sense. If a modder asks you to remove your listing as a matter of courtesy, you should do it, otherwise they're likely to come back with an ARR licensed mod, and ARR mods are a pain in the ass for everyone involved.

I wasn't suggesting that mod authors not be allowed to request their mods to be delisted, and whenever possible have that respected. In fact I didn't mention that at all in my post. I was saying that requiring a user to compile CKAN themselves, after forking it and editing-out the prohibit code is an insane imposition to put on anyone. It doesn't actually fix the underlying issues, it just means users are going to make guides to do just that and then do it anyway. And then you have people working around the entire system that you just put in place to supposedly relieve people's headaches over this, except because the "Prohibited" status would be ignored, they would be extremely likely to add listed mods with that status but not get any warning whatsoever. Headache for troubleshooting it, headache for mod authors if the user goes to them first, headache for CKAN if they come here first. More pain and annoyance all around.

There's already a perfectly reasonable "harder than just clicking ok" option: make your own CKAN file. It's a bit out-of-the-way, but it's there. And it should remain an option. Introducing a complete block on managing a given mod with CKAN would do little more than hand mod authors a "Spite users?" button.

Again, what software a user uses to manage mods is up to them, and should be up to them. Whatever solution is reached shouldn't try to enforce those kinds of restrictions. It's a waste of everyone's time (including mod authors). Whatever policy is put in place needs to have a good chance of users actually following it, instead of it being likely they'll try to break it, for it to be effective.

Right off the top of my head, you brought-up DRM. Just think about which DRM schemes have been most successful. Steam comes immediately to mind. Why? Because their DRM doesn't suck (or at least it doesn't anymore, but that's beside the point). Compare that to Ubisoft's checkered past, where legitimate users would download cracks so they could play the game they bought.

I'm only saying this because you brought-up recompiling CKAN oneself as being the only solution. If the solution to the problem were simply to create their own CKAN file, that'd me more reasonable. Though I still worry that will lead to a lot of unofficial .netkans floating around. I'm already putting together my own repo of them for my own use.

Remember that one of the issues here is that various things -- from CKAN metadata breaking an install to "Your mod doesn't work" "Did you read the install instructions and edit the .cfg files?" have led to an increased support load for several mod authors. There has to be some way for them to go "Nope, can't/won't handle that" -- the lack of that option is the crux of the current issue. That said, I still feel the best possible result is to expand the options that CKAN metadata has in such a way where delisting/"Prohibited" becomes the option of last resort in these circumstances, rather than the only option.

Install instructions in the metadata would be nice, but actually I think in that case it would be a great idea to create a standard similar to .fomod . In fact I think that's a rather excellent idea, especially since it could also fold-in KSP-AVC's .version files (for example, if you just had one .kspmod file in the mod archive, KSP-AVC could search that instead; that way authors would still only need to maintain one to two files at most). It's not like that has to be limited to CKAN either; other mod manager apps could be made to support such a thing.

@Cphoenix improving the backend to cover more usage cases and minimize the number of errors is all well and good but these issues have been known for over a year and instead of fixing them this project seems to have instead prioritized keeping up with the metadata.

If you look at the history of users working on CKAN, you'll realize that a lot of contributors (politas mentioned this very thing on the forums) don't actually write code, they help maintain metadata. JSON is relatively easy to understand. C# + Perl and all the moving pieces in maintaining an application and bots to support it is less so.

[Cphoenix]

@BobPalmer

I'm just going to say that all those suggestions (16 hours ago ish, so way up on this thread; sorry, I'm insanely busy this weekend and barely have time to read just this thread) are great. I'm glad we're at least making some progress here. I'd be happy to help the CKAN guys with whatever I can and have time for with this, mostly because through my own faux-pas I saw what can happen when we don't have a list of mod authors who prefer to manage or vet their own metadata, and other checks to make sure that stuff doesn't get merged into the NetKAN master branch, causing frustration for all. Even if that just means having another set of eyeballs on PRs for metadata.

[Cphoenix]

@TeddyDD

This is really god idea but this could be just first step. CKAN could help with preparing bug reports (for example automatically find all KSP logs and upload them to pastebin on user request?). CKAN should also keep log similar to pacman.log (it looks like this ) and also allow to revert last transaction (so player would be able to get back to working game without hassle)

That's a fantastic idea that has the potential to make everyone's a bit easier. Easier for users to create and submit accurate and useful bug reports (instead of just "your mod doesn't work"), easier for authors to sort them out in a timely fashion, easier for the CKAN team to deal with the same bug reports when it's CKAN's mess to deal with. Slap a button for that feature right on the GUI and make it obvious.

Sorry for the spamming posts guys. Never know how much time I'll get to read these things. >.<

[DuoDex]

@BobPalmer It was more intended as a general suggestion ;)

[politas]

Ok, I've had some sleep so now I can explain my actions. I created PR Allow foss delisting #1795 and have started behaving as though that change were accepted. As a result, I have delisted some mods on request. If there are any delisting requests that I haven't got to, I apologise for that.

Given that ModuleManager is one of the mods I delisted, CKAN is effectively useless for most users now. Sarbian handed me the launch codes, and I fired the nuke.

So why did I do it? Mostly as a wake-up call to my fellow CKAN contributors. Insisting that CKAN is following FOSS ethos by keeping all FOSS mods available was not ultimately in the best interests of either the FOSS community or the KSP community. I have been thinking a lot about this over the last couple of days, and here's what I think is the fundamental problem:

CKAN's policy was all about accessibility, and the rights of users. It was based on the assumption that all CKAN was doing was facilitating the installation of mods. Where it went wrong is in not taking into account the fact that in the minds of many CKAN users, CKAN also implicitly defines a support relationship, by linking to the "homepage" forum thread. We have attempted to disabuse users of that idea, but those efforts have been unsuccessful, and are likely to remain so, because people are people.

It is this expectation of support in the minds of users that has antagonised the modders, as far as I can see (combined with a perception of arrogance from CKAN team members and supporters). As such, I am going to act as though my PR #1795 has been accepted. Either we change the policy, or the CKAN team kick me out of the project.

[passinglurker]

@politas and if they kick you can fork ckan and we can get the forum mods to kick the original arrogant ckan from the forum or at least lose its stickied status so the plan is fool proof either way! ;)

[politas]

I wish I had the talents and connections to be able to fork CKAN, but I'm afraid I don't. Not that I want to fork CKAN, I want to fix CKAN's problems.

[Cphoenix]

For what it's worth @politas, I think you did the right thing. I think it's sad that it has come to this, but still.

and if they kick you can fork ckan and we can get the forum mods to kick the original arrogant ckan from the forum or at least lose its stickied status so the plan is fool proof either way! ;)

Could we maybe keep this sort of posturing out of this? Please? The KSP forums already escalated to an astonishing level of absolute...I don't even know what to call it. Other than absolutely maddening.

Like @politas, I would much rather fix CKAN's problems than see it resigned to the gutter. Let's focus on that.

[BobPalmer]

I agree. Assuming the policy remains in place - and I'd want to see @pjf confirm that first based on the prior discussions in this thread - then I will be re-listing my mods (likely after a version bump, and I have some dependencies to sort).

(For specificity, I agree we need to move on and fix CKAN's problems).

[lamont-granquist]

Is this entire mess due to the fact that the metadata is all distributed via a github repo where the authors of the modules don't have commit access to maintain their own metadata?

All the other package managers I've touched (rubygems, npm, cargo, chef's supermarket, etc) all have model where there's a website that distributes metadata that the author of the package owns and is responsible for keeping up to date. Since CKAN grew organically it was probably necessary to allow community curation of metadata, along with indexing bots, and the CKAN-meta repo was a really easy solution to bootstrap the product. Its pretty clear that its moved beyond that, however, and you really need a way that mod authors can maintain their own metadata and a button that they can push to submit it where the results are nearly instantaneous (barring some cloudfront/cloudflare caches being updated or whatnot, but it should be a matter of seconds or minutes for fixes to go live).

Since CKAN is only distributing simple metadata blobs and the problem of shipping the mod bits is 'outsourced' to spacedock/curse/github/whatever the bandwidth cost of moving to a real website hosted on something like heroku shouldn't be that onerous or costly. The website would need to get built but you really just need a CRUD interface over the .ckan json files, with some basic account management that nearly every web framework has some kind of plugin for, along with a download point for "the whole tarball of all the metadata". I'd do it, but I'd write it in ruby on rails, which nearly nobody else in the community would be able to support.

[TeddyDD]

Is this entire mess due to the fact that the metadata is all distributed via a github repo where the authors of the modules don't have commit access to maintain their own metadata?

It is possible to do in current system. I don't remember exactly how but you can add reference to netkan so it pull metadata from external source (directly from author).

I don't think writing new website is good option. There is plenty of work with CKAN client itself.

[lamont-granquist]

Is there something broken with that then? Too long of a delay in the scraping bot? Scraping bot broken too often? Just nobody knows enough about that option to use it?

[TeddyDD]

I suppose this works well. Here, I found this option: https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#ckannetkanurl

[Cphoenix]

I suppose this works well. Here, I found this option: https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#ckannetkanurl

That's how @BobPalmer was managing his metadata before this mess. It works alright as long as no-one goes around making metadata for his mods before he does ( :flushed: ) . @politas' proposed opt-out list ( #1795 ) will go far toward alleviating that problem. The benefit of that system is that it very clearly points to who is the real maintainer of the metadata, the mod author in this case, and they've pretty much got complete control (unless someone overwrites the .netkan that's pointing to the metanetkan, which would be rather rude).

For the record, while I know that mess earlier was caused by me, a naive user at the time who didn't know just how much a headache that can cause, I don't think it's a good idea for any policy trying to fix this problem to completely eliminate the possibility of new metadata wranglers. Naive users should still be allowed to pop-in an help-out if they can, just with enough checks to catch these sorts of screw-ups (like not merging their changes until they are very thoroughly checked by someone more experienced; a staging area would help). Many hands make light work, after all. I'd hate to see anyone tied-down feeling like they need to be on here constantly fixing metadata because there's no one else to chip-in, since everyone here is a volunteer. :disappointed:

[lamont-granquist]

It kind of seems like that method has failed to me, and the opt-out list will probably work extremely well for as long as this issue is in the forefront of everyone's minds, but that at some point some relatively new CKAN maintainer will merge a PR without checking the opt-out first and you'll wind up right back here again.

However, if the opt-out list keeps the mod authors in this thread happy for the time being and averts the crisis and the FusterCluck of removing all the ARR mods, including ModuleManager, then it seems like a decent first step. I'd really encourage everyone involved in the conversation to keep considering better technical solutions to the problem, though, since it smells like the ckan has just been kicked down the road...

[BobPalmer]

Best way to solve this. If the submitter is not the original author, just check it against the opt-out list. Or if in doubt, just ping the original author. Do all of this while it is in the staging area. Stuff should not be merged from stage to the live repo unless we're sure (a) the submitter is the project maintainer, and (b) the project is not on the opt-out list.

[BobPalmer]

(The opt out list could even be automated a number of ways - like restricted repos or author names).

[lamont-granquist]

As far as your first comment goes.... I've found that anything repetitive mechanical process involving humans invariably breaks orders of magnitude more often than one that is just backed by code -- "its simple just check the opt-out list" is a recipe for failure.

As far as your second comment goes... Yes, I'd argue that is nearly a requirement.

[Cphoenix]

As far as your first comment goes.... I've found that anything repetitive mechanical process involving humans invariably breaks orders of magnitude more often than one that is just backed by code -- "its simple just check the opt-out list" is a recipe for failure.

The policy change is a band-aid to placate everyone temporarily, no question. (I don't mean that in a "mod authors are chumps" kind of way, to be clear.) A solid solution backed by code as you say and not error-prone meatbags is the end-goal, I think. It's just that that takes time, and comparatively policy changes are far easier to do in the short-term.

[politas]

In the interests of completeness, and in the renewed atmosphere of cooperation, are there any people who are still demanding opt in, before this issue gets closed? I am happy to explain in detail why I am against such a policy (and plan to do so soon, anyway).

[ferram4]

I would prefer @BobPalmer 's suggested approach above:

Ask first. If no reply, go ahead and list it. If a request comes to de-list, do so, Add a staging step to catch some of these common issues.

Which is technically opt-in if you can get in touch with the author, opt-out if you can't. From the author's perspective it means that if you're active you have the chance to say, "hold up, don't index it yet" if something is going to change soon, which avoids a lot of metadata issues that opt-out may still cause. It also means that an active modder's first interaction with CKAN doesn't risk being a metadata issue that they had no idea was coming.

I think I understand the reasons for wanting opt-out rather than opt-in though, which is why I'm alright with it for "no reply." I'd guess that those are as follows:

1. Apathetic modders aren't going to get bothered by CKAN if their stuff is listed
2. Oh God, oh God, if we go opt-in only what do we do about all the mods we've already listed?!

Just make the time to wait for a reply a week before it switches from opt-in to opt-out, make the procedure and time well-known (or as close as possible), and I'd be happy with that.

[Cphoenix]

@ferram4 One scenario that the above doesn't cover is the CKAN PRs from SpaceDock. It's my understanding that those only happen if the whomever is uploading the mod to SD checks a "CKAN" box. I think those should be taken as implicitly meaning that the mod author does want the mod listed and is passing the work off to the metadata wranglers here.

Still, it would be prudent to send them a message, either directly on the forums or whatever other method is listed, to just say "Hey, as requested your mod was listed CKAN [insert link to relevant PR/commit]. If this is in error please let us know." Or something to that effect. That way at least there's a chance to catch the occasional mis-click. And hopefully if that does happen being pro-active about it will help alleviate any frustrations.

[politas]

What I'd like to see in the long run is some integration of the web gui netkan creator being worked on into Spacedock, which would make it more than a single click and we could take those as a definite opt in.

@ferram4: I was planning to write a much clearer procedure for adding mods which would include @bobpalmer's "PM the author" suggestion, along with a message template for gathering information. A week seems a long time, though. Could we say that a week would need to pass between sending the message and the mod exiting staging/being merged?

[ferram4]

@politas Yeah, that sounds good; ideally, the metadata should be sitting in the staging repo marked that it's waiting on author permission / time before being merged. That would allow the .netkan and .ckan to be linked to the author in the request so they can look it over, possibly with instructions for how to get CKAN to install their mod using it while it's in staging so they can test it themselves if they like.

The main reasoning behind a week is that depending on people's schedules, they might not have the time to deal with the PM in a shorter timespan, which then means annoyance when they get to it and find out what happened. A week should give enough time for an entire cycle of the workweek to handle all of that. And if they're gone longer, they'll be less annoyed because you did give them awhile to get back to you.

[politas]

Yep, I know all about life schedules delaying responses. Agreed that delay reasons would need to be made explicit in the staging / release process. Introducing an entire week's delay at the start of the process makes getting the mod into CKAN slower, so some hybrid of 48 hours before going ahead with creating metadata without a response and a week for opt out before release sounds like the way to go.

[Blu3wolf]

You are gonna get a bunch of folks peeved at getting opt outs three days after initial contact XD

[BobPalmer]

Yeah, I think as long as folks have a (reasonable) amount of time to put on the breaks then that is a good thing. tbh an initial delay is probably going to be an edge case. Anything where they click the CKAN box on SpaceDock can of course be fast tracked, and there you just want to do a quick 'Hey, we saw you wanted this on CKAN. Do you want to check out the metadata and make sure we got this right?'

I think the timeframes involved are less important than the basic process. And I also agree with @ferram4 that the the goal sjhould be making sure that the first interaction with CKAN is a positive one.

[Blu3wolf]

In fairness, most mod authors are not going to have any idea if the metadata is right or not.

[BobPalmer]

Most, but not all. And it's those cases that put us where we are today.

Point being that there's a dialog, the modder has an idea of what's going on, and experience has shown us that a bit of proactive prevention goes a very long way in these cases.

[BobPalmer]

Also, it can be as simple as 'It looks like you depend on Firespitter and Module Manager - are there any other dependencies or does that sound right? Let us know if there are any issues, and we can work together to get them resolved for you'. Make the experience positive for those with content, and you're going to start getting a lot more enthusiastic supporters among them.

[dewiniaid]

Re: Spacedock and other submissions of its nature:

If we have information that a mod author most likely intended to submit something to CKAN (I.e. checking the box on Spacedock), is there any real reason not to immediately go ahead with that submission? If they checked it by mistake, they'd most likely be understanding of the issue (and it can still be fixed after the fact).

This is particularly true if we add the staging repository and send the author a message more along the lines of "Per your request on Spacedock, we've added your mod to CKAN. If this request was made in error or you wish to maintain your own CKAN metadata, please [instructions]".

[BobPalmer]

No real debate there. If they explicitly opt-in (i.e. via spacedock) then go right into making metadata. Letting them know it was done and that it's in staging would be a nice courtesy (gives them a chance for an 'oops!').

[Cphoenix]

Letting them know it was done and that it's in staging would be a nice courtesy (gives them a chance for an 'oops!').

For explicit opt-in from SpaceDock and the like, I'd say give it 24hrs or so just to be safe before it gets pushed to the release repo/branch (that's more of a wishy-washy "eh, seems okay" bit regarding the 24hrs; I pulled that out of my...you know). Longer if there is some confusion about what the metadata should say (see#https://github.com/KSP-CKAN/NetKAN/pull/4149 for an example), obviously.

@BobPalmer is right I think that it's more the process that matters, not the timeframe. We can probably just settle for whatever is "close enough ish sorta" for time.

[solarsootysmudge]

TL:DR. Staging area yes but not as we know it. Something else is brewing. Opt out is really an panic button option / debugging tool. Sometimes it really just needs to be there to give us time to think.

After a bit of digging around through my notes....

The stage area idea is correct way to do it but it is also overkill. Initial suggested reason only applies to a few mods. Plus in some edge cases that will not fix some of problems we are seeing. It is possible to submit metadata and have it pass all checks. Even the best of us will not see an error. Then things still go wrong in a tiny number of cases. None the less. We need a staging area anyway. See #1679. Some of this could be bashed out of existing code. Although that is a huge guess on my part. We kind of already have a way to do this but I need more time research the idea.

In short we mark as incompatible and require yoyo style version control. That allows full experimental installs but only for the technical savvy. If it all works out we switch back to GRAS. Then everybody gets the mod. I admit that I am grasping at straws here.

Also ....

The op out policy sometimes needs to be though of as an emergency stop button / debugging tool. Recently I have seen mistakes where metadata is correct and we get temporary problems. Nothing too bad really. This may have been acceptable in the past but numbers of forum users has grown. To the point where a minor problem causes too much spam. Those issues have be captured where we need to fix something. A quick example

Mod A depends on Mod B. Both sets of data good. Thumbs up.

However fails because we forgot Mod B depends on Mod C. Turns out C is out of date.

That's the simple version of the story. If you want to dive deeper into the actual bug report see #1646. Now lets be clear this does not current effect USI mods. As far as I am aware. However it may affect others in the future. So the issue is still alive. At the time this one happened @BobPalmer got error reports. We did not know what was happening. It was pain to tell people just to stop and give us time to investigate the problem. Now an opt out might be overkill here but it nice to know there is a "panic button" procedure when the forum starts to go nuts.

There is also another reason for opt out. Here is the controversial part. Sometimes it has nothing to do with CKAN at all. However we can't sit back do nothing. Sometimes we going to have to delist the mod anyway. Just give us time to think the problem through. Or talk to the mod author through solutions. No I am not going to write an example. It would look like a witch hunt. To error is human. To forgive is just good PR policy. If a mod author calls for it lets accept by default and then try to help resolve the problem.

[BobPalmer]

Sorry, had trouble following all of that. But I'll reinforce my preference for a basic staging process - it solves a lot of woes. There have absolutely been cases where I wish this was handy.

RE opt out - IMO the policy is in a good place. An option that is on the table, no questions asked, for any modder that desires it. Conversations should of course take place, but there are going to be people who do not wish to have a mod be a part of the indexing at this time. And yes, it's also a nice 'kill switch' that lets people withdraw until said conversations take place.

For Explicit opt-in (think SpaceDock) I can go either way - immediate listing into staging or not, and trust the team will make the right call on that specific process (and we can always adjust if people get grouchy).

[Cphoenix]

In terms of specifics, I assume the best option here is just to add two branches to KSP-CKAN/NetKAN called say "staging" and "experimental"? (Having entirely different repos would be needlessly complicated and overkill. Also for anyone interested, this is the workflow that would be required from the people with write access to the NetKAN repo.)

[Blu3wolf]

Well no, it wouldnt be overkill. Just have one repo (experimental) use NetKAN as now, with NetKAN submissions from everyone, screened by the Maintainer for the relevant mod, while the other repo uses only .ckan files that have been declared stable by the Maintainer.

[Cphoenix]

The reason I say it's overkill and complicated is because it would involve splitting the relevant history of each edit among different repos. That means no one would be able to get a complete picture of how new .netkans were added and eventually committed to the master branch without looking at two distinct repos. It'd add a lot of overhead for maintainers.

Edit: An (sorta) alternative workflow is just to cherry-pick commits from staging into a new branch, and then merge that into master. Would probably be a little clearer what's going on that way.

[Blu3wolf]

.netkans would not BE added to the master branch of the stable repository. The stable respository would consist only of .ckan files already confirmed, by usage and testing either by the modder or maintainer, to work properly, having been generated and tested on the experimental repo, which would have the .netkan files and its generated .ckan files.

[solarsootysmudge]

I hate to interrupt again with a question. Why can't we do this on the local client?

The reason I am asking is the following may help. I admit it has nothing to do with staging. I know that. However it sounds like staging to me. It can provide the same function. Plus we already have done a lot of the work. Although it needs tons more work. Here goes.

Right now. I can simply switch off the metadata version controls. To do so requires at the minimum. Knowledge of the system and use of the CMI. The normal GUI does not allow it. So I can do stuff that most people can't. In effect sometimes. I get access to mods before anyone else gets them. Anybody can do that. If fact we had a massive debate on how to control this. Right now it is not fully enabled as far as I am aware.

The key point is some get to install mods in CKAN that others can't. I am guessing there is only a few in relation to the general population of users. I am guessing that perhaps because they had to jump through technical hoops. They hopefully don't send mod authors crap bug reports.

Once that population users is happy. When there is no install bug reports coming back. We then do a minor automated update. Say in the .version file. Suddenly everyone gets the mod.

Here is another way of looking at it. Mods did not actually get deleted. They just got hidden in a place that a tiny number of people know how to access.

Is any of this relevant. If not that is ok. I can bugger off and try again. If it has got some use then I could do more research in this direction.

[solarsootysmudge]

I have another question. On the staging issue. We should be pushing the conversation to #1679. Just so @techman83 sees it in one place. There is also a nice definition of overkill there and how traditional staging is difficult to do.

Back on topic here. I thing we a now all agree that the policy on on opt out is correct. If mod authors have objections to CKAN we need to respect that. Details are irrelevant. It just the right thing do. it does not have to a permanent decision. We can switch it on and off. I think there been a convincing demonstration of this recently.

If there is any way to improve on the methods used to delist at will. Or sort out any other grievances. I sure the CKAN team want to listen.

[Blu3wolf]

You think incorrectly, there. For certain conventional values of 'we', anyway.

[solarsootysmudge]

I am only too painful aware of this and was trying to be diplomatic. I apologize if any offense was caused. Lets be honest here. I am not in any special privileged position here. I am just once guy that reads everyone's side of the story. I am trying to understand the majority whilst not ignoring the minority.

Oh course the words majority and minority are personally subjective.

Here is a bit of information that might change perceptions. I am disliexic disaletic dissalictic....

Oh sod it you all get the point. If I use the wrong words I am sorry.

[Cphoenix]

I have another question. On the staging issue. We should be pushing the conversation to #1679. Just so @techman83 sees it in one place. There is also a nice definition of overkill there and how traditional staging is difficult to do.

Thanks for that; I really have to stop posting things after I've done a bunch of overtime that day. My brain gets all mushy and forgets stuff. >.<

[KSP-CSE]

For whatever communications are to happen between a mod's maintainer and the CKAN indexing team (disallow CKAN install, provide maintainer's metadata to override CKAN repo's metadata), may I suggest that a comparable additional mechanism is provided to communicate the same info inside the mod package itself (e.g. in KSP-AVC format), because:

• this channel of communication is already always available; if the package can't be read then obviously there will be no CKAN install;
• and this channel is already under the maintainer's control, without needing manual intervention from the CKAN team to make changes.