Skip to content

[cc0 oot] EnMd - #2820

Open
Dragorn421 wants to merge 2 commits into
zeldaret:mainfrom
Dragorn421:oot_cc0_en_md
Open

Dragorn421 wants to merge 2 commits into
zeldaret:mainfrom
Dragorn421:oot_cc0_en_md

Conversation

@Dragorn421

Copy link
Copy Markdown
Collaborator

No description provided.

@JordanLongstaff

Copy link
Copy Markdown
Contributor

Why would you want to remove documentation?!

@Yanis002

Yanis002 commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Why would you want to remove documentation?!

I agree that it's very weird but I think it makes sense actually, what dragorn did initially was decompiling again those files again to have CC0 friendly stuff (since the original author probably never replied to the licensing issue), and for that they obviously couldn't look at main to avoid getting biased by the current work, so basically there's no way you can know things were documented already if you don't look at current main (and also another reason I can understand is the fact that the current docs were made off of the previous work)

I don't think anyone should panic over this we can always document again at a later time tbh, what's important for now imo is having the repo licensed, I don't think this should be a blocker for merging at least

@Dragorn421

Copy link
Copy Markdown
Collaborator Author

Regressions are not on purpose, they are merely a byproduct of the process and we can address them in reviews.

As I described in #2780 the process for CC0 oot involved rebasing the git history, leaving out changes that were not CC0 and redecompiling in place when necessary.
For example here with EnMd that means I dropped the snablu-authored commit 4e1fc87 (snablu never answered to the CC0 issue) and re-decompiled EnMd in Dragorn421@f810f24
All the differences we see in this PR stem from the differences of these two commits since obviously as Yanis points out I did not reference main to do my EnMd decomp. So some things can be different.

You can help by reviewing: please point out things that should be named.or improved.
Just don't tell "do this like in main" since the whole point is to redo the changes independently or at least in a clean room ish fashion,
Instead tell "this should be named/documented", "this is wrong because ...", "cleanup needed here"...

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.

3 participants