Upstreaming Infrastructure Changes

[leezen]

As I'm sure you noticed, we forked gph-site for QoDE. I made a number of changes, primarily around running the application in a containerized way locally and having an option to easily deploy to AWS via Pulumi. Within AWS, it uses ECS Fargate, ALB, and Aurora Serverless to run along with serving static content via S3. Before submitting any PRs, I figured it'd be easier to open up an issue and discuss if you'd be interested in having some (or all) of these changes upstreamed?

There were also a few enhancements and bug fixes I made to the app itself, but I don't know how interested you are in those. For example, we included a time-based unlock mechanism that could be merged back upstream, but I also don't know how much you're trying to keep this repo fairly 'stock' vs. having more bells and whistles for people to turn on/off.

[cesium12]

Hi Lee, thanks for using gph-site! Like I tried to lay out at the start of the README, this repo is in practice more or less a snapshot of the most recent GPH, and we haven't put work into maintaining optional behavior that we isn't going to be used that year, especially for features like unlocking that often involve schema changes and some fiddly logic. That said, it's still a case-by-case decision based more on compatibility and maintainability.

In terms of deployment, if there are code changes you want to upstream that make things smoother on certain platforms without affecting other users, or additions to the documentation in DEPLOY.md, I think we'd be happy to look over them. We don't, however, use those platforms for GPH or have much expertise in them, and we don't have much insight into whether there are other gph-site users who do or who would like to. If the changes are more invasive or touch other parts of the code for platform reasons, then we might be less interested. (Even if it's just configuration for deploying in a container or on AWS, I'm not sure that we'd want to add that to our codebase and take on responsibility for it.) The same goes for unlocking or other feature-type additions that are specific to a particular hunt's rules, for the reasons above. But we'd be happy to take more localized changes or bugfixes.

An alternative might be to make your fork public as a resource for anyone else who might want to run their hunt in a similar way. It would take some cleanup work, of course; also, we don't currently have a way for those people to find these kinds of forks, and if we did I'm not sure how useful it would end up being as time goes on. But it could be something to consider.