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

Revert commits #613

Closed
wants to merge 16 commits into from
Closed

Conversation

negativeExponent
Copy link
Contributor

The recent PR were suppose to be parts of more PR to get the entire codebase complete, or at least where i want it to be and in a better working state for easier update and maintenance. Ive come to the point that it would take a lot of time and effort to get all PRs done since each one has to be modified to suit the current codebase, causing a few minor but suppose to be fixable conversion errors. The repo have diverted too much from the time i made the original fork, causing each merges conflicts and needing manual intervention. The recent incident, the reluctance to accept the changes, the consideration of issue without details, the need for third-party confirmation didnt help in giving motivation to do so and complete this. I have worked a long time not just this repo, but on other cores fixing shit nobody else wanted to take and it still amazes me that my intention are getting questioned in favour of..... I would just rather continue working on my fork rather than starting over. Reverting this would be more beneficial for everyone. History is kept(i hoped), for reference.

negativeExponent and others added 16 commits September 19, 2024 20:29
- Mapper code rewrite, fixes and updates, additions
- Expansion Audio updates
- update VRC7 sound code (emu2413)
- replace Sunsoft 5B sound code with emu2149 for better accuracy (including envelop and noise emulation)
- Update FDS sound expansion (fds audio code from Mednafen with
  modification for fceumm' use)
- Update NSF support
- Add NSFE support
- others (maybe)
Require for some mappers aka Game Doctor, etc
Adding it as-is
The recent PR were suppose to be parts of more PR to get the entire codebase complete, or at least
where i want it to be and in a better working state for easier update and maintenance.
Ive come to the point that it would take a lot of time and effort
to get all PRs done since each one has to be modified to suit the current codebase, causing
a few minor but suppose to be fixable conversion errors. The repo have diverted too much
from the time i made the original fork, causing each merges conflicts and needing manual intervention.
The recent incident, the reluctance to accept the changes, the consideration of issue without details,
the need for third-party confirmation didnt help in giving motivation to do so and complete this.
I have worked a long time not just this repo, but on other cores fixing shit nobody else wanted to take
and it still amazes me that my intention are getting questioned in favour of.....
I would just rather continue working on my fork rather than starting over.
Reverting this would be more beneficial for everyone.
History is kept(i hoped), for reference.
@LibretroAdmin
Copy link
Contributor

LibretroAdmin commented Sep 23, 2024

I don't understand why you sent this when I told you this in the previous thread -

I said just now that nothing needs to be reverted and that you can send any followup PRs you had prepared already.

I sent an invite for write permissions too immediately after so you don't even have to go the PR route.

I would just rather continue working on my fork rather than starting over

You don't have to. I told you this in the previous thread. I said that you could go ahead with this

The recent PR were suppose to be parts of more PR to get the entire codebase complete, or at least where i want it to be and in a better working state for easier update and maintenance

In fact you can still go ahead with this.

@LibretroAdmin
Copy link
Contributor

LibretroAdmin commented Sep 23, 2024

Alright then, I'll honor the revert.

It seems other people are also running into segfaults and such so I think it's justified to be worried about the refactors.

#614

It's a shame since there were good things in this PR, it should just not have been omnibus'ed like this in one go.

What I'll try to do is cherrypick the parts that don't refactor the core code and just add functionality instead.

I think the commit message also honestly is rather loaded and very divisive and incendiary. I don't think it's necessary to have these spats get added to the git history. I'll just do a git reset --hard instead.

@negativeExponent
Copy link
Contributor Author

Like what I've said, issues are suppose to be fixalble. The last one was just probably the index in core options but who knows. Revert is always a prio instead of fixing stuff and move forward

@LibretroAdmin
Copy link
Contributor

LibretroAdmin commented Sep 23, 2024

I will try to go back to your PR and backport at least all the core options stuff and all those additions.

As it is, I'm sorry all this happened, I wanted all us to work together and I was happy that you decided to return. But honestly I also feel like you need to be more understanding of the situation we're in, when there are multiple ppl reporting issues there is obviously an issue and it was prob not a good idea to make all those core refactors to the core code. And instead of building further on a broken foundation it's better to be more conservative with the PRs and add stuff in a way so that any issues that arise can more easily be traced back. Big omnibus PRs I think are bound to fail like that. Like with any project the need to be able to communicate and shift course and just adapt to the situation without it resulting in catfights or territorial disputes is really important otherwise really no collaborative project can succeed.

I find it sad that you take whatever happens in this codebase as a personal slight against you and it always results in some threat to leave or whatnot, even when me and hunterk always try to be understanding and try to work out solutions with you. But nearly everything we do just gets treated as some kind of personal slight or insult so it seems like the next drama cycle just occurs regardless of how well intentioned we are. I'm not sure how to break that cycle since honestly it doesn't seem like it matters how many concessions we make and no matter how accomodating we are.

@negativeExponent
Copy link
Contributor Author

your missing the whole point. the issues ARE FIXABLE. dunno how much these CN guys is paying but you are more concerned to appeal to complains without details than the one making the refactoring. the first PR ive already warned of a heads up because due to the NEED of conversion issue will occur and its not a complete set of PRs, but its suppose to be fixable and its not a one-time PR.

should have given me the option of a branch or repo to get the refactoring as stable as THEY want it was. but no. REVERT AND IGNORING ALL THE WORK is the priority, also pleasing them gods.

@LibretroAdmin
Copy link
Contributor

LibretroAdmin commented Sep 23, 2024

Re: CN guys, nobody is paying us anything. I doubt they even have any money to spare. TBH I'm getting fed up with him too.

Re: branch -
Again, I sent you an invite for write rights a month ago. It expired. I sent it to you again a few days ago, I keep telling you that I sent you the invite but it seems you are pretending not to read it. So as far as I'm concerned, you can still accept the invite and create a new branch and work there. That way more of these issues could be resolved before it gets merged into master. All of these options are still available and open.

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