-
Notifications
You must be signed in to change notification settings - Fork 308
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
Is there a policy for C/Elisp patches? #225
Comments
My preference would certainly be to get them merged upstream. We do sync with upstream periodically, and C/elisp patches increase the chance of conflicts. We do have some elisp patches, such as teaching Emacs to find definitions of primitive functions in Rust. We also have some C patches, to help interoperation (e.g. removing If it's an unambiguous optimisation or bug fix, then we would preserve the property that Remacs is a drop-in replacement for GNU Emacs trunk. I suppose we could do that if we wanted. I think C patches would be less problematic, because user lisp is less affected. Did you have any specific patches on mind? Do you have copyright assignment sorted out? |
I have the CA but so far I couldn't get anything into Emacs :D Of all the patches I submitted they never even shown up in the list, so I gave up. I don't have anything in mind yet, but just philosophically I was thinking about it and how this project could/should/would evolve. There are people who might contribute quality features but are simply unwilling for their own reasons to work with FSF, and I was thinking what would happen if this project tried to accommodate them. Basically creating a less-bullshit contribution environment. I suppose, what I'm saying is if there is a want to become XEmacs 2.0. So some light policy note somewhere wouldn't hurt. |
If you have a patch, do open a PR, and we can discuss :) (As an aside: In my experience, the best way to contribute to GNU Emacs is to ask for commit access. If you get access to GNU ELPA, you can commit to Emacs itself too. For uncontroversial patches, just commit them directly to master. My understanding of the mailing list etiquette is that you post to the list, consider people's opinions wherever possible, and then commit. You don't (or often can't) have to make everyone happy.) |
Say I want to fix a bug in C or Elisp, do you accept these patches or are they generally avoided?
For obvious reasons it would be much simpler to get them merged here than upstream :/
But if we decide to go that route it might eventually lead to bigger split from GNU Emacs than just "replacing C with Rust" as the features themselves would start to split.
The text was updated successfully, but these errors were encountered: