OXP maintenance

[Stormrider]

My questions should then read:

So what do we do with unsupported expansions?

Seems like this would include a majority of them. I would say leave them alone unless there is a real issue.

By the time an OXZ is available to everyone, it should have passed a couple tests beyond whether it works by itself.

Who gets to decide if an OXP is worthy?
How do you know if one of those you restrict from accessing it is not the one who has the skills and time available to fix a problem if it might arise?
I believe the more users with access to OXPs the more likely we are to discover bugs and conflicts and, ultimately, more likely to address any problems we discover.
I think a simple disclaimer when opening the manager would be enough, something like:

Expansion available here are created by community volunteers and are not officially tested and therefore may have bugs or conflicts with other expansions. When possible bugs and conflicts are documented. Install at your own risk.
Continue

And on the subject of categories, "Depreciated/Broken/Hopelessly Buggy" needs to be at least one, and not show by default.

Brilliant but broken
We do have this page. A link to it could be shown in the expansion manager if a selected oxp has a known issue so players worried about such issues could be well enough informed to decide if it is something they want to avoid.

Instead we could create different lists of OXZs that are stable/compatible, another one that is less stable/unfinished and a third called experimental
Then users can switch on/off their preferences and know what to expect.

The recommendation could be to add only one experimental to a set of stables for constructive testing. And if we can collect metrics like amount of bugs reported vs installations/flight hours we could promote OXPs into ghe next list.

The first part might be a good idea but the question is, as I asked above, who gets to decide when something is considered stable?
I am also quite concerned about how you would go about collecting metrics about something like flight hours. I am not at all comfortable with Oolite tracking me, I believe there is already to much of that kind of thing going on.

[hiran]

I think a simple disclaimer when opening the manager would be enough, something like:

Expansion available here are created by community volunteers and are not officially tested and therefore may have bugs or conflicts with other expansions. When possible bugs and conflicts are documented. Install at your own risk.
Continue

Ummm - this applies to all of Oolite, doesn't it? If it refuses to work or does not meet expectations, ask for your money back!

Instead we could create different lists of OXZs that are stable/compatible, another one that is less stable/unfinished and a third called experimental
Then users can switch on/off their preferences and know what to expect.

The recommendation could be to add only one experimental to a set of stables for constructive testing. And if we can collect metrics like amount of bugs reported vs installations/flight hours we could promote OXPs into ghe next list.

The first part might be a good idea but the question is, as I asked above, who gets to decide when something is considered stable?
I am also quite concerned about how you would go about collecting metrics about something like flight hours. I am not at all comfortable with Oolite tracking me, I believe there is already to much of that kind of thing going on.

True. But how would we get feedback? If no problems are reported it could mean noone is using it at all. Hence I would have liked something like flight hours - and you are right.

Would it help if Oolite, after being installed would ask whether such tracking is ok as it supports the community? Also I have not thought this through fully since today there is no location where such tracking data could be stored.

[hiran]

Just let me have a moment before I write an update as it seems we are going to discuss the current process again.

Thank you,

I updated the Packaging and distribution section with Cim's scripts and a comparison of the publishing processes.
Hopefully that helps for the time being and is a base for discussing improvements.

[Cody]

[rant deleted] No tracking!

[Switeck]

I'm not recommending tracking people to find hidden bugs, and I'm against that too both from a privacy standpoint and because lots of people may be running Oolite on marginal hardware and adding tracking will not help.
15 minutes of serious testing can equal hours of "random" play by random people.

The players that are big enthusiasts for particular OXPs are the most likely people to find and report bugs with that OXP.
You want a particular OXP and you request that someone make it, then you probably should be one of the people to test it!
Mentioning your OXP list is helpful, but just knowing in general if someone uses no other OXPs, a few, many, or crazy amounts of OXPs is "good to know!" for others trying to duplicate a possible bug.

(I am picky about which OXPs I use, but don't always test the ones I run with. For instance, I've been adding almost every station I could find, but then dialing them back to only spawn under more limited circumstances to avoid Tech Level 13-15 systems having a lot of them. I have enough to give those system more individuality even if the same stations are used elsewhere.)

The author/s of the OXP is also who to ask for if/when their OXP is (likely) stable, incomplete, and/or has incompatibilities with other OXPs.
When authors convert their OXP to a OXZ and puts it on the Expansion Manager, they need to choose multiple categories for their OXP anyway.
This also means we NEED to be able to change (mostly ADD) categories for OXZs after they were added to the Expansion Manager, preferably without having to upload the whole OXZ again!

"Newness" of an OXZ can imply a stability risk, but at this point...really old OXPs that were converted to OXZs years ago with only cosmetic changes are probably the most likely to have bugs and incompatibilities now.
A new update of an existing OXZ may be adding new content/graphics...but likely also at least minor bug fixes as well!
Once again, the authors are the ones to know if a recent update of their OXZ is a must-have fix for a known bug, a "hope this fixes it!" bugfix, or new content.

There will have to be a LOT of trust of the authors and testers, because there are precious few of us relative to the number of OXPs and OXZs to maintain and test!

[cim]

I believe as soon as we have the expansion manager promote an expansion and allow easy installation that expansion should have some quality and support.

This is an interesting statement. I originally wrote it to make installation and visibility of OXPs much more available than it previously was (since the download statistics for Oolite itself at the time were hundreds of times greater than those for even the most popular OXPs, suggesting that most people didn't realise they existed).

I had absolutely no desire to get into gatekeeping of "is this expansion deserving of a place in the list?". Oolite was relatively late, among games which encourage expansion development, to get a manager for them, and the others didn't seem to do any more quality control than "have you managed to provide a well-formed file" either. Obviously it's been many years since I've had any right to a say on the direction of Oolite or its community, but I am surprised it's a question now. Not to drag up old drama in detail but has there been some particularly badly-behaved OXPs or authors while I've been away that have made it a significant problem?

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?

To go back to this original question, my expectations would be (assuming of course a license permitting adoption):

- if you're just taking on maintenance of the OXP as a continuation, whoever is/are the primary maintainer can decide how contributions are accepted, which might be by public version control or might be by "send me the code change in a forum post", and how they manage for themselves version control of the source. This doesn't have to be the same way the previous or next maintainer does it. [1]
- if you're forking an OXP, change the manifest IDs, name, etc. enough to make that clear, set a conflict in the manifest on the other version, there's now two similar OXPs and both sets of maintainers can manage them how they see fit

If two people both try to take on maintenance of the same OXP and don't agree, then one or both needs to change the manifest ID. I guess this is a case where the devs might need to step in to require one or the other changes the ID if the two OXP maintainers can't resolve it amicably but that seems pretty unlikely: finding *two* people interested in working on the same OXP at the same time is pretty rare.

If the previous OXP author is about, and you have a suggested change (especially a trivial one like manifest cleanup) then just give them that change to incorporate in whatever way they've indicated is suitable, because that'd be a really silly thing to create a fork of it over. If they're not about but come back later, a quick message of "hey, your OXP broke while you were away because of Blah, I uploaded a fixed version here, here's the changes" should be fine to get things back on track.

But all this is politeness and social stuff rather than anything that particularly needs a technical solution - or it was!


[1] For example: most of my OXPs have the source on Github. If you try to update that code nowadays by submitting pull requests to that source location *that won't work* because except for the most trivial changes I won't have time to review them. So you're going to need to move it to another source control system (whether that's "another repo on Github" or "a folder on your computer, which may or may not be running a local version control tool") anyway to continue development. (And since I'm not maintaining them any more, you can keep the same manifest IDs if you want)

[phkb]

True. But how would we get feedback? If no problems are reported it could mean noone is using it at all.

I don't think adding any sort of monitoring is going to help with finding problems. Almost every time there is an issue it is because of some unexpected OXP interaction. There are too many OXP's to test with, making it unrealistic to expect OXP devs to have tested everything, in every scenario, in every ship and configuration.

However limited it might be, all we have to work with is what users report to the forum, and what information is contained in the log file. I'd much rather spend the effort on making users welcome on these boards, than go down the rabbit hole of trying to get some sort of meaningful set of metrics out of Oolite.

It's probably better for us to focus on getting the most out of what we do have. The manifest file resolves a few of these issues. The issue of abandoned OXP's is something we'll have to deal with on a case-by-case basis. Conflicts, again, case-by-case if the conflict hasn't been noted before.