phoenix_ca

CKAN Discussion Continutation

Recommended Posts

29 minutes ago, technicalfool said:

If it does, point people at the fork thread. If they refuse to take no for an answer, hit the report button. Give your friendly neighbourhood philanthropists something to do.

This is the issue modders have, though. Having to point people at another thread is the complaint being made here.

Share this post


Link to post
Share on other sites

To me this module manager thing is probably the strongest argument I've seen for keeping the old policy. I was on the mod-author's side before, now I'm not so sure, if a dependency can just be yanked without notice, without clearing out dangling dependencies. Is the point you are trying to prove the opposite of what you are saying? I don't get it . . . 

Edited by bos

Share this post


Link to post
Share on other sites
1 minute ago, bos said:

To me this module manager thing is probably the strongest argument I've seen for keeping the old policy. I was on the mod-author's side before, now I'm not so sure. Is the point you are trying to prove the opposite of what you are saying? I don't get it . . . 

This is the result of ... a very long argument.  The point being made here is that mod developers have no obligation to support CKAN.  Zero.  None.  And - it really can't work without their support. 

Share this post


Link to post
Share on other sites

The mod developers need not support CKAN for it to function.

Share this post


Link to post
Share on other sites
On 6/24/2016 at 3:49 AM, kiwi1960 said:

CKAN is nothing but a lazy persons tool

4 hours ago, Jarin said:

Yes, the time of the mod developers who contribute all the content we are discussing in this thread is indeed more important than random joe shmoe player.

This kind of talk is toxic and has no place here. CKAN users are innocent of this drama and only want a mod managing tool to make enjoying mods easier. Treating them like second-class citizens because mod authors are upset with CKAN itself is repugnant.

Share this post


Link to post
Share on other sites
2 hours ago, Papa_Joe said:

I by no means mean any disrespect to anyone here, but mod installs are by nature pretty simple things.

Install is quiet easy. Update 60 mod install is pretty hard. And time consuming.

51 minutes ago, blu3wolf said:

This is the issue modders have, though. Having to point people at another thread is the complaint being made here.

Maybe moderators should ban users who don't read first post in a thread? They are source of issue, not CKAN and mod devs don't care about them anyway.

Share this post


Link to post
Share on other sites

To be honest thats probably taking it a bit far IMO. Still, I think modders shouldnt be supporting those folks anyway, so theres that.

Share this post


Link to post
Share on other sites
2 minutes ago, Met said:

This kind of talk is toxic and has no place here. CKAN users are innocent of this drama and only want a mod managing tool to make enjoying mods easier. Treating them like second-class citizens because mod authors are upset with CKAN itself is repugnant.

Well, remember that the expressed reason that modders are upset is because some CKAN users post on their forum threads when those modders would prefer they not do so. So while most of us indeed just want tools to help with updates, dependencies, etc., those other "users" are in fact central to the drama, structurally speaking.

Share this post


Link to post
Share on other sites
2 hours ago, blu3wolf said:

You can of course write your own CKAN files to install ModuleManager that way. That makes it almost as much hassle as a manual install, though.

Ive been keeping quiet in all this, mostly because Ive never used CKAN... but implying manually installing mods is a large hassle is just silly.

3 minutes ago, TeddyDD said:

Install is quiet easy. Update 60 mod install is pretty hard. And time consuming.

Maybe moderators should ban users who don't read first post in a thread? They are source of issue, not CKAN and mod devs don't care about them anyway.

No. It isnt hard, especially if its a mod that uses AVC, because that provides you a link to download the update. Updating installs with large amounts of mods is not hard. It is only mildly time consuming...

 

~~~

 

Personally, Im on the side of the mod authors... and really I dont think CKAN should accept listing from anyone other than the author or primary maintainer of the mod. If a mod author doesnt care enough to list his or her mod on CKAN, thats too bad.

Share this post


Link to post
Share on other sites
6 minutes ago, Met said:

This kind of talk is toxic and has no place here. CKAN users are innocent of this drama and only want a mod managing tool to make enjoying mods easier. Treating them like second-class citizens because mod authors are upset with CKAN itself is repugnant.

Oh I quite agree, I was merely making the point that the longer this goes on the more harm it would do. HOWEVER.... if you accept that it makes installing mods EASIER.... then you must also accept that it does create many hassles and problems, totally unforeseen AND unwanted for mod authors. Given all that has been said, my "lazy" comment is nothing to be concerned about. I really encourage the CKAN group to sort out the problems fast before we lose to many mod authors in this argument. As far as I can see, if their software was close to perfect then this wouldn't have happened. And by perfect, I don't also mean with the software, I also mean with the licence. It should *ONLY* be modders themselves that can submit a mod to CKAN and not any Jeb, Bill and Bob....

Share this post


Link to post
Share on other sites
2 minutes ago, Avalon304 said:

Ive been keeping quiet in all this, mostly because Ive never used CKAN... but implying manually installing mods is a large hassle is just silly.

No. It isnt hard, especially if its a mod that uses AVC, because that provides you a link to download the update. Updating installs with large amounts of mods is not hard. It is only mildly time consuming...

 

~~~

 

Personally, Im on the side of the mod authors... and really I dont think CKAN should accept listing from anyone other than the author or primary maintainer of the mod. If a mod author doesnt care enough to list his or her mod on CKAN, thats too bad.

For several hundred mods, it actually is a large hassle. Not every mod uses AVC, and on my last KSP install, several modders accidentally screwing up their .version files caused me about as much grief as they claim CKAN causes them.

As far as freedom of speech goes, you are allowed to suggest it shouldnt be a thing, but only because you have it.

Share this post


Link to post
Share on other sites
2 hours ago, blu3wolf said:

You can of course write your own CKAN files to install ModuleManager that way. That makes it almost as much hassle as a manual install, though.

You can also grab ModuleManager.fozen and use netkan.exe to genrate ckan package (Like in Arch AUR). That is what I'm going to do.

Share this post


Link to post
Share on other sites
26 minutes ago, HebaruSan said:

Well, remember that the expressed reason that modders are upset is because some CKAN users post on their forum threads when those modders would prefer they not do so. So while most of us indeed just want tools to help with updates, dependencies, etc., those other "users" are in fact central to the drama, structurally speaking.

The average user is absolutely not being malicious here. Not being literate in mods and bugs and posting about issues in the wrong section is not a crime worth the scorn some people here have been dishing out to them.

Edited by Met

Share this post


Link to post
Share on other sites

Except according to the swamped modders, who are asserting that it is.

Share this post


Link to post
Share on other sites

That seems to be a byproduct of the real issue. So let's not trash the average user. The conversation should be about how mod authors and CKAN can resolve their issue.

Share this post


Link to post
Share on other sites

I, for one, will *never* support 64-bit installs for my ModuleManager configs until Squad fixes it.

Share this post


Link to post
Share on other sites
23 minutes ago, GavinZac said:

I, for one, will *never* support 64-bit installs for my ModuleManager configs until Squad fixes it.

64 bit support has been fixed since 1.1. I know of at least one mod where the author actually doesn't support Win32 builds any more.

Though what this has to do with the thread subject, I have no idea.

Share this post


Link to post
Share on other sites

Maybe CKAN could be more clear within the program itself, or its immediate help files/documentation/FAQ that its installs may not be supported by the mod authors, or even maintained by said authors, and provide some basic troubleshooting steps like starting with a fresh install of KSP and installing manually. If that is somewhere and I missed it I apologize (I've not had problems with CKAN), but taking a glance through the most visible "I need help" locations, I don't really see anything about what to do if a mod doesn't work. It's just left to the user, and the mod "homepage" is the most immediate thing to check. It's not a complete solution, but maybe it would help with volume.

Edited by eriseley
Added a thought.

Share this post


Link to post
Share on other sites

As I see it the CKAN/NetKAN team have currently a few options:

Option A: Amend CKAN policies. In my view this does not require dropping the CKAN principles of respecting the law (dur!) and acting in the interests of users; after all, liquiding off the upstream developers is emphatically not in the interest of the end users.

As for specific changes, I've already advocated for the concept of a responsible maintainer for each piece of metadata. I would also say that CKAN should adopt a presumption in favour of not listing a mod whose author doesn't want it listed. That presumption should be overturnable, chiefly in cases where the mod is a dependency and authors of dependent mods want a CKAN listing.

Option B: Resign. Cease all development and involvement in the CKAN project, or at least quit from the leadership roles, and let someone else take over. Considering the level of antagonism between the CKAN team and the upstream developers, this might be the only way to regain confidence in the CKAN software and thereby improve the situation in a way that provides continuity for end users and delivers more definite change, compared to CKAN being forked or a new mod manager being promoted.

Option C: Do nothing. Stick your head in the sand and hope it blows over. I'd rather this didn't happen, of course, but I can't stop it.

Share this post


Link to post
Share on other sites

I am known for having 'people problems' I have a medical certificate to that effect.

But having read through this thread read through this thread I think that some of you have greater problems than I.

When I am at odds with something or someone I have to consider the logic of the situation to prevent myself from saying something which may cause offence. Understand this, I personally don't care about any of your feelings. I have been instructed that trying to act as though I care is a step in the right direction and will allow me to better 'fit-in.'

So to the point.

Modders do not need CKAN.

Without the modders CKAN has no function.

Therefore CKAN, like myself, must make the effort to 'fit-in' as this is the only way to gain modder support.

If a modder wished a mod to be removed from their system then a method of doing so should be implemented to make the process as simple and effective as possible. This would make life easier for modders and improve relations between both sides.

There is nothing to stop modders from having an open license 'With the exception of ANY automated installation system other than those listed below. Even those listed must remove this mod from their system if asked to do so by the author/s' line in their licence.  Thus permitting and supporting distributors of their choice.

Trust me on this. You do not have to like each-other to get along and be productive and helpful to your users which after all are the most important in all this.

I almost deleted all this a few times because I could care less about any of you however, my trainer says that if I see an opportunity to contribute to a conversation which is heated and do so in such a way that can reduce the heat of that conversation, that I should do so to help me learn to associate better with others and 'fit-in'

Share this post


Link to post
Share on other sites
3 minutes ago, cantab said:

As I see it the CKAN/NetKAN team have currently a few options:

Option A: Amend CKAN policies. In my view this does not require dropping the CKAN principles of respecting the law (dur!) and acting in the interests of users; after all, liquiding off the upstream developers is emphatically not in the interest of the end users.

As for specific changes, I've already advocated for the concept of a responsible maintainer for each piece of metadata. I would also say that CKAN should adopt a presumption in favour of not listing a mod whose author doesn't want it listed. That presumption should be overturnable, chiefly in cases where the mod is a dependency and authors of dependent mods want a CKAN listing.

Option B: Resign. Cease all development and involvement in the CKAN project, or at least quit from the leadership roles, and let someone else take over. Considering the level of antagonism between the CKAN team and the upstream developers, this might be the only way to regain confidence in the CKAN software and thereby improve the situation in a way that provides continuity for end users and delivers more definite change, compared to CKAN being forked or a new mod manager being promoted.

Option C: Do nothing. Stick your head in the sand and hope it blows over. I'd rather this didn't happen, of course, but I can't stop it.

I think option A is the best choice

Except a very critical point: nothing should force  mod on ckan against its creator's will. Not even dependencies. This is a recipe for disaster that will lead to crappy mods being made just to force some other mods onto ckan.

 

I feel Option B is extreme, and it's not required. But I can understand people dropping out if they don't like ckan anymore.

Option C is what I am expecting will happen. Other than pozine I have yet to see the attitude change and I fully expect the team to kick him for not respecting the ckan rules and reinstating all the mods that have been removed. But maybe that's just me being pessimistic.

Share this post


Link to post
Share on other sites
2 minutes ago, Daveroski said:

There is nothing to stop modders from having an open license 'With the exception of ANY automated installation system other than those listed below. Even those listed must remove this mod from their system if asked to do so by the author/s' line in their licence.  Thus permitting and supporting distributors of their choice.

Of course, if its an open and free license, that doesnt stop anyone else from rebuilding it and offering it without such a draconian license. On a per release basis, if thats what it takes.

Seeing as moving install files by 'hand' is the same method that CKAN uses for installing (behind the GUI), you would actually be barring the use of your mod on personal computers.

If thats what it takes...

Share this post


Link to post
Share on other sites

I'v gone through the thread and I'd like to sum up things that could be done to increase CKAN metadata quality (before I open an issue at CKAN)

1. Add "maintainer" field to metadata. This could work similar to maintainers in AUR

2. Split CKAN-meta into two repositories: CKAN-meta and CKAN-testing (or staging, whatever). Those repositories would be opt-out for mod authors of course.

3. Don't accept .netkan without a maintainer. Automatically inflate .netkans provided by mod author to testing repo. Inflate .netkan to staging that is provided by third-party maintainer only after manually checking generated .ckan by human. Eventually create new repo for unsupported netkans that advance users can download and inflate manually.

4. CKAN-meta:

  • only packages with maintainer
  • move packages from testing here after checking they are correct
  • If package lost maintainer then move it back to testing.

5. Point users looking for help to maintainers. This could be by adding "repot a bug" button to CKAN gui.

6.? Create separate bug tracker for communication between users and maintainers. CKAN-meta issues would be used to communication between CKAN maintainers, developers and mod authors.

7. Add fast and reliable mechanism that would allow mod author to nuke specific .ckan (move it back to testing) probably using bot. This is must in case one specific release of mod would cause trouble.

8.? Setup special policy about "core" mods. By core I mean packages which many other packages depend upon (like ModuleManager etc.) This mods should not be pushed back  to staging without warning.

9. Encourage authors to manage metadata about their mods. Who knows better how mod should be installed that the author? Write tutorials how to package mod. Show modders what advantages CKAN gives as package manager. Create easy to use .ckan/.netkan editor that don't require messing with JSON. Provide any help they need to understand how CKAN works and how to package a mod without hassle. This is critically important point! Mod authors providing metadata means that CKAN maintainers could spend more time on testing packages than packaging mods. It would also decrease importance of Netkan witch is good! Netkan as automatic tool is error prone and should be used as helper not as main tool to create metadata.

Imagine this workflow:

  • Author wants to release new version of mod
  • Author have a .netkan file for his mod
  • he/she upload the mod to Spacedock and generate .ckan file using netkan.
  • If file is correct, author is pushing it to testing repo (or even directly to main repo)
  • If generated ckan package is broken is pretty easy to fix it manually since author knows how CKAN works
    • Author edits generated ckan file (5 minutes of work) and sends it to testing repo


In this example .netkan is just a helper. I best case it generates end-user metadata, in the worst case it helps in writing metadata by hand.

 

Any suggestions?

Edited by TeddyDD

Share this post


Link to post
Share on other sites

1. Sounds good.

2. Ive already said my piece (several times, in several places) on having at least three official repositories.

3. Part of 2 really, I think there should be an Unsupported repo - basically equivalent to the current one. This obviously would take such.

4. Looks good, but there would never be a need to move it from Stable. If it is Stable it wont magically stop being so.

5. Sounds good. Possibly linking to the Issues setup, and @tagging the maintainer?

6. Cant hurt.

7. Never should be a position where that needs to happen, files should never have gotten out of Experimentals while unstable.

8. Cant agree. Just because a mod is depended on, doesnt mean it has a different license. Mods like ModuleManager should be treated just like any other mod with the same license.

9. This is already the case. Other than making a custom editor for people (completely unnecessary for people smart enough to make a mod) all that has been done.

Suggested workflow - NetKAN is used to generate .ckan files, which are put into Experimentals repo automatically (The NetKAN files in the first place written by the modder/Maintainer). After a period of testing - say a week or two - those .ckan files are moved to Stable, for general use. The Unsupported repo remains a wild west of edit wars and errors, much like early Wikipedia.

 

Share this post


Link to post
Share on other sites
7 minutes ago, blu3wolf said:

The Unsupported repo remains a wild west of edit wars and errors, much like early Wikipedia.

 

I'd like to have unsupported repo for advanced users but I this one must not be opt-out to make sense. Therefore it should not be part of offical CKAN to not cause controversy.

 

11 minutes ago, blu3wolf said:

9. This is already the case. Other than making a custom editor for people (completely unnecessary for people smart enough to make a mod) all that has been done.

I wouldn't call it done since many modders passionately hate CKAN, and most don't care about it. I agree that manual edition of JSON file is not something that average mod autor cant handle. But for example, looking for deps is tedious since you have to use identifier instead of name. This could be streamlined a bit. Also I know CKAN metadata quiet well but I'd like to have tool that visualize package relationships including provides/conflicts trick and virtual packages.

22 minutes ago, blu3wolf said:

Cant agree. Just because a mod is depended on, doesnt mean it has a different license. Mods like ModuleManager should be treated just like any other mod with the same license.

License don't apply to metadata but I'm not going to suggest that we should force this mod into official repo. I'd rather work closely with authors of such mods to ensure metadata is rock solid.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.