Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cataclysm-dda: split off 0.D release branch #70

Closed
wants to merge 2 commits into from

Conversation

l29ah
Copy link
Contributor

@l29ah l29ah commented Feb 6, 2019

No description provided.

@leycec
Copy link
Owner

leycec commented Mar 6, 2019

Awesome. Admittedly, it took me a few minutes to grok the exact intention of this pull request. Assuming you submit future pull requests (...please do!), it'd be useful if you could summarize your changeset with a more human-readable description than merely "split off 0.D release branch". I'm all for brevity, but five lone words is a bit too brief. You know – just sayin'.

Also, I'm unconvinced that I want to permanently maintain two separate Cataclysm: DDA ebuilds as this changeset suggests: e.g., both cataclysm-dda-9999.0d.ebuild and cataclysm-dda-9999.9999.ebuild. Would symlinking the former to the latter instead suffice? I'd like to eliminate any migraine-inducing DRY (Don't Repeat Yourself), if we can.

Also, I'm concerned that end users will fail to understand the obscure versioning conventions we've adopted and then endlessly ridicule me about my awful design choices on our issue tracker.

That said, I love your specific changes to cataclysm-dda-9999.0d.ebuild and admit that most end users probably would prefer to reside on the 0.D branch – especially as that branch finally appears to be stabilizing.

In other words, there's quite a bit for me to meaningfully chew on here. I'll probably tackle the unrelated C:DDA issue #69 first, which is both the low-hanging fruit and shameful. Unfortunately, doing so will probably break this pull request. Fortunately, given the above concerns, I was considering manually integrating only a portion of this changeset anyway. (Don't worry: it was the most meaningful portion. I'm a good man. Really.)

In short, I have no idea what I'm going to do here. It saddens me that the C:DDA codebase has become so bifurcated. They really fell hard into the development hell hole, didn't they?

@l29ah
Copy link
Contributor Author

l29ah commented Mar 6, 2019

Yes, symlinking would do the job, but the main Gentoo tree doesn't use symlinks, so i suppose they don't work for some Gentoo systems.

@leycec
Copy link
Owner

leycec commented Mar 7, 2019

the main Gentoo tree doesn't use symlinks

Yup. It probably should, frankly. Duplication is the death of sanity.

so i suppose they don't work for some Gentoo systems.

...doubtful, but possibly possible. All POSIX-compliant platforms – which is all platforms compatible with Gentoo Prefix – support symlinking. Given that raiagent (that's us) and various other overlays have leveraged ebuild symlinks to reduce DRY for over two decades with no appreciable issues, my lurking suspicion is that there are no rational reasons for Portage not to do so.

Fortunately, we ain't Portage. 😉

Thanks again for your stupendous contribution. You're an excellent human specimen, Sergey! I apologize in advance if I break this changeset by resolving #69 – and promise to patch things back up again. We'll get these welcome improvements integrated in a jiffy. ...where "jiffy" is defined as "in a week or three."

@leycec
Copy link
Owner

leycec commented Apr 24, 2019

Boom! 💥

At long last, #69 has now been resolved. Although this pull request superficially appears to have no conflicts, in actuality pretty much everything has changed and will need to be rethought a bit. Of course, that's my responsibility. </sigh>

I've sat on this depressingly long enough. Now, it's time to see what I can salvage from your most excellent work. I may not necessarily branch the live 9999 ebuild into two separate 9999 ebuilds as you'd prefer. Now that 0.D has been officially released, all development work appears to be confined to the master branch.

However, I will endeavour to manually merge everything else of value into the existing 9999 ebuild – which is quite a lot, actually. Let's see where this dark road leads us...

leycec added a commit that referenced this pull request Apr 25, 2019
The "BACKTRACE=1" option is now unconditionally enabled (regardless of
whether the "debug" USE flag is enabled or not), thereby ensuring that:

* Binaries remain unstripped unless explicitly requested.
* Binaries output crash reports on fatal errors.

This improvement comes courtesy commit 23ff19b of pull request #70.
Thanks, @l29ah!

Unrelatedly, build-time dependencies have been improved to explicitly
require the "sanitize" USE flag on GCC or clang when the "debug" USE
flag is enabled.
@leycec
Copy link
Owner

leycec commented Apr 25, 2019

O.K.! Commit 23ff19b922 is an excellent catch. You're absolutely right. Allowing BACKTRACE=0 would be highly undesirable under Gentoo (and most platforms, frankly), as doing so both strips binaries and entirely disables crash reporting. Luckily, BACKTRACE=1 incurs no performance penalties.

For sanity, I've manually merged the contents of that commit into 6e13178 with attribution to you. Thanks for that, @l29ah. You've made the post-apocalyptic world a better place for disgustingly disfigured mutants.

Sadly, the entirety of commit 255d5c53859 no longer appears to apply. The 0.D branch is 2216 commits behind master and is no longer actively maintained. Since the HEAD of that branch is identical (or at least closely comparable) to the stable 0.D release tarball, there's not much point in explicitly tracking that branch. Unless I'm missing something really obvious? ...I'm probably missing something really obvious.

With grim apologies, I'm reluctantly closing the remainder of this pull request unmerged. You clearly injected a non-trivial syringe full of blood, sweat, and tears into this contribution. I hate rejecting your generous work.

But don't feel bad! It's basically my fault. If I hadn't taken so long to resolve #69, commit 255d5c53859 probably would have been the Right Thing to Do™. I hope this doesn't dissuade you from submitting any future changes. The BACKTRACE=1 catch was excellent – and something I couldn't have caught on my own.

I too now feel like a complete jerk.

@leycec leycec closed this Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants