OXP maintenance

[hiran]

Looking at the output of OoliteAddonScanner a number of OXPs generate warnings. Some easy things are missing information-urls ox the use of a licence tag where license is expected.

Now I could download an OXP, tweak ir and opload it - likely to a new site that I control. I could also update the expansion catalog. Since I love versioning I'd even keep a copy of this OXP in Github, maybe with automated build scripts that even update the catalog.

But what would prevent someone else from doing the same stunt With different? How can we tell the previous OXP author or even better future OXP authors how to contribute to new versions?

Or more generic: how do we manage to maintain our OXPs?

[hiran]

Noone with an opinion?

Then here is my idea:

I will define one more field in the manifest - in the beginning optional, later mandatory. It's name is 'source' and it will be a URL to where the OXZ originates from.
This is where controbutions should get posted.

Then, one by one and where applicable I'd update OXZs by plcing then in version control and adding a matching source url. Next up would come the intended changes.

And then everybody can contribute a lot easier...

[Switeck]

Or more generic: how do we manage to maintain our OXPs?

I struggle to get anything out, let alone something without bugs.

Getting details correct on license and other files for download on the OXZ updater...I struggle even harder!

I have to say, Switeck's Shipping OXP is dead because maintaining it (read: make it so it will work with Oolite now) is too much trouble for me.
Fortunately, more ship variety have come to the main game without any add-ons.
The station market changes it had is a different can'o-worms!
In short, core game changes have invalidated part of it as well as even its premise.

[phkb]

I have an opinion! Just putting thoughts together.

[hiran]

Or more generic: how do we manage to maintain our OXPs?

I struggle to get anything out, let alone something without bugs.

Getting details correct on license and other files for download on the OXZ updater...I struggle even harder!

I have to say, Switeck's Shipping OXP is dead because maintaining it (read: make it so it will work with Oolite now) is too much trouble for me.
Fortunately, more ship variety have come to the main game without any add-ons.
The station market changes it had is a different can'o-worms!
In short, core game changes have invalidated part of it as well as even its premise.

Well, it does not have to be a one man job. You can publish buggy or work in progress. That would allow others to join up and help.

More important is to have a suitable license. Here the license chooser can help:
https://choosealicense.com/
They also point out why a license is important:

No License
When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), “nobody” starts including you.

And looking at my post this is exactly why I put up this thread. If someone created an expansion and moved on today we have nobody to maintain it. And holding those back who went creative and contributed sounds like a penalty.

[phkb]

This is a big topic, and I suspect every OXP developer will have a slightly different take.

I think it’s important to remember that Oolite was designed to be *easily* modifiable. That is, you don’t need to be a software engineer or a modelling master in order to make changes to the game.

We want to attract the widest group of users into this development environment. With only simple tools, and a fairly basic understanding of what’s going on with each file, you can launch into creating your own mod.

Now, I love GitHub, and how easy it makes the process of versioning software. But I write software for a living. GitHub is primarily a tool for people who write software for a living. And while GitHub may market itself as “The place for anyone from anywhere to build anything”, once you start digging into it you have to learn a lot about software development practices, and a whole new vocabulary (pull requests, branches, diffs, sub modules, etc), new software to install and learn and update, new user accounts to create and add 2FA to. That is a massive learning curve.

Which is why I think having all OXP projects pushed into GitHub, and have updates pushed out from it, is not necessarily a good thing by default. If someone wants to do that with their OXP, and they have the skills and understanding to make it work, that’s fine. But it should not be the default way we publish and maintain OXPs. That pushes the learning curve for modding Oolite into stratospheric heights. I mean, we have people here who are put off by the thought of editing a text file! Pushing the full GitHub process on them would, I think, limit the range of people we have contributing to our mod ecosystem.

In fact, I would go so far as to say having OXP projects in GitHub would ultimately stifle contributions. But happy to bat this around some more. What do others think?

[another_commander]

100% agree with phkb here.

[hiran]

Why should the availability of one or another OXP with versioning negatively impact other OXP development?
Actually this fact has already happened - I know about one OXP that is in Github.

Just because one, several or many of them are hosted in version control should create visibility but not stop anyone from brewing their own stew at home.

Yet the concept is more important to code where the creator moved on and the community would take over maintenance.

[phkb]

Why should the availability of one or another OXP with versioning negatively impact other OXP development?

Because it sets expectations that, in order to contribute to the OXP ecosystem, you have to do it through GitHub. Which, as mentioned, is going to be too high a bar for some people to clear. So, they won't contribute. Thus we lose out on some people joining.

Actually this fact has already happened - I know about one OXP that is in Github.

Yes, Diplomacy is the one I'm thinking of. It has a bug, which I've reported on GitHub. But I don't have rights to the repository, so I'd have to fork it to put a patch together. Which is getting kind of complicated for what is a simple fix!

Just because one, several or many of them are hosted in version control should create visibility but not stop anyone from brewing their own stew at home.

The point is that GitHub itself is going to be the thing stopping people from doing anything. By making it a requirement, you are sending a message that "only programmers should apply".

Yet the concept is more important to code where the creator moved on and the community would take over maintenance.

I agree, we need solutions in place for maintenance of OXP's that don't have a maintainer. I just don't think using GitHub for that job is the answer.

Our current system is pretty simple: if someone wants to maintain an OXP, they can do so, with the owners permission if they're contactable, but even without it if there is a license in place. And that's it! *How* they go about maintaining that OXP is up to them. But presumably they have already got a copy of the source code, from having it installed. The benefits of this system is that it's super simple. The downside is it's unregulated and there is no version control. But those things aren't the be all and end all of mod development. I would rather keep things as simple as possible, to encourage as many people to join in as possible.

[Stormrider]

From your list of OXPs that need "maintenance":

Code: Select all

Unknown key 'upload_date' at https://wiki.alioth.net/img_auth.php/c/c8/Stormbrewer_2.9.oxz!manifest.plist 

From the manifest.plist in the last version of this that I built:

Code: Select all

"upload_date" = "2016-01-23 01:59:46";

What is the problem?
I used cim's build scripts to generate the manifest.plist so if this was included it seems likely that upload_date was a known key at some point.

As far as using github is concerned I am not at all interested in using it any more than I have to. I am certainly not interested in having to compile OXPs in order to modify them, I've tried to compile oolite dozens of times and have only been successful once.
If you want to upload my OXPs to git to work on that is fine but don't expect me to make any contributions there. Trying to deal with the manager is enough of a pain and I am not interested in dealing with another layer of complexity in order to share what I might create.

[Switeck]

I have to say, Switeck's Shipping OXP is dead because maintaining it (read: make it so it will work with Oolite now) is too much trouble for me.
Fortunately, more ship variety have come to the main game without any add-ons.
The station market changes it had is a different can'o-worms!
In short, core game changes have invalidated part of it as well as even its premise.

Well, it does not have to be a one man job. You can publish buggy or work in progress. That would allow others to join up and help.

When I initially push something small out, I usually set it to public domain "copyright" so others can use it however they want.

Later when it gets more substantial, I go with the tried-and-true...
Creative Commons Attribution - Non-Commercial - Share Alike 3.0

I don't intend to make anything exclusive -- I want to share ideas not hoard them!

Likewise, I do my primitive version-handling just with carefully-named .zip files and .oxp folders.

My personal release methods are initially exclusive testing with a couple people, just to avoid public embarrassment again. There are old message thread examples of that.

At first, my add-ons are sloppy mods that either are in .OXP folder form (.zipped up of course) or just raw files (as was the case with my early oolite-cargo-cargo.js mod).
Sometimes I mention them at this point on the forum in message threads on similar subjects.

Then I make it low-visibility publicly available here:
https://wiki.alioth.net/index.php/Speci ... ns/Switeck

About the same time, I may start an Expansion Pack message thread devoted to a particular OXP still in testing.

Later, if Cholmondely pushes me hard enough, a dedicated page is devoted to my better OXPs. (With him doing most of the work!)

Lastly, my better ones get converted to .OXZ and put in the official automatic expansions list.

Currently my OXZs includes only Auto-ECM, Cargo Contract Mod, and Misjump Inducer -- all 3 work well, best I can tell.
...and Switeck's Shipping, which is thoroughly broken at this point and beyond my desire to fix anytime soon -- since many of the stuff in it was incorporated into the plain vanilla game anyway.

Very rarely do I bother to update them, unless changes in Oolite cause problems with them or new-found bugs (or conflicts with other OXPs/OXZs!) in them appear.

[hiran]

From your list of OXPs that need "maintenance":

Code: Select all

Unknown key 'upload_date' at https://wiki.alioth.net/img_auth.php/c/c8/Stormbrewer_2.9.oxz!manifest.plist 

From the manifest.plist in the last version of this that I built:

Code: Select all

"upload_date" = "2016-01-23 01:59:46";

What is the problem?

The expansions are scanned in kind of pedantic mode. The field 'upload_date' is specified but not for OXZs. Probably that needs more of an explanation:
There is a difference in what the OXZ manifest.plist file contains and what the expansion manager sees when it downloads the catalog of all OXZs.
If you look at the specification for the upload_date in manifest.plist:

upload_date
The date when the expansion was uploaded.

This field is actually populated by the expansion management functions on the Oolite website and not expected to be filled by expansion authors. See https://oolite.space/admin/ The format is the number of seconds since midnight of 01JAN1970 (also known as 'the epoch').


Why could this be a problem? The field, if put into manifest.plist is part of the OXZ. Well, for the field file_size it is hard to know the size before the OXZ has been packaged, and similarly it is hard to know the date before the OXZ has been uploaded to a publicly accessible site. Hence these keys should not pop up within an OXZ's manifest but need to be added for the expansion manager when assembling the catalog.

I used cim's build scripts to generate the manifest.plist so if this was included it seems likely that upload_date was a known key at some point.

Noone said you are the bad guy, and now knowing where the field might stem from we may take a look at these build scripts (I haven't seen any so far).

As far as using github is concerned I am not at all interested in using it any more than I have to. I am certainly not interested in having to compile OXPs in order to modify them, I've tried to compile oolite dozens of times and have only been successful once.
If you want to upload my OXPs to git to work on that is fine but don't expect me to make any contributions there. Trying to deal with the manager is enough of a pain and I am not interested in dealing with another layer of complexity in order to share what I might create.

Compiling Oolite is far more spectacular than 'compiling' OXPs. I am putting the second compiling into quotes since all a build script would do is to zip up the repository contents - I would not call that compiling. And it is the exact same step you'd have to do in your home installation anyway. There is not even a reason why it should work on one side and not on the other. If you like we can have a look together.

[hiran]

I think I am getting the point. Several people in this thread now mentioned that version control on expansions is neither asked for, wished or even tolerated.

My point of view is the opposite: I would not touch code without version control in the background. Too many hours of trying to undo a change to get back to the last working state have taught me the hard way. But obviously I am a minority here. Plus, while writing that I remember having had a similar chat some time back.

Thus I will rest my case and not touch any expansions.
Thank you all for participating and saving me from some unwanted effort.

[Switeck]

My point of view is the opposite: I would not touch code without version control in the background. Too many hours of trying to undo a change to get back to the last working state have taught me the hard way. But obviously I am a minority here. Plus, while writing that I remember having had a similar chat some time back.

In my case, I am not even sure where/when/how my OXP causes broken behavior in the game because I may not even be looking/studying that.
So I often only find out when someone who tests my OXP broke something.
And then I have to determine which version they are using and go back through my 20+ intermediate version saves to see if earlier versions also have that problem.
Multi-OXP conflicts that arrive from unexpected directions make that really fun, as I may not even be able to reproduce broken behavior until I get an exact OXP list+setup of whoever told me about the problem/s.

Before I know it, I'm troubleshooting other OXPs I at best barely understand.
(Code Documentation! Does anybody do it?!)
...and I may never fix/eliminate the broken behavior spotted.
I usually have to wait till someone else comes along and fixes it.

It's perhaps useful / important that we all have access to at least some earlier versions of various OXPs/OXZs that have seen major changes.
I am concerned we may lose access to the long list of OXPs completely.
I've already been asked if I have a backup of an OXP or 2 that may have only briefly been released before 2012.

More OXP maintainers are needed, even if for 1-off fixes for old, broken OXPs.

[phkb]

and now knowing where the field might stem from we may take a look at these build scripts (I haven't seen any so far).

I think this was a feature of the previous OXP admin page, where, once you had filled in all the text entry fields and saved the form, it would give you the exact content of the manifest file at the bottom of the page, including things like upload_date and download_url. We don't have this any more with the current system.