leycec / raiagent

Third-party Gentoo overlay. Ride the Lagrangian point between awesomeness and volatile compounds.
31 stars 14 forks source link

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

Closed l29ah closed 5 years ago

leycec commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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. :wink:

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 commented 5 years ago

Boom! :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 commented 5 years ago

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 6e1317829195d 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.