Replies: 1 comment
-
|
A first attempt: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Contributors create merge requests because they encounter a problem or finding a feature making their working methods easier while thinking others can also benefit from their work.
Usually they did some more testing on their machines before submitting and their patches should be "safe".
I often see merge requests labelled then "triage", "internal" or "internal-effort" and nothing happens for months or even years on them by core developers.
People cannot really benefit from this work for a long time.
So sometimes people think "subject sounds good - apply it on my own stack" but don't really know whether patches are required anymore to do their originally intention, are useless because of new code flows or even mess up things.
Esp. together with other patches there can be merge conflicts or other problems. So people must always control their patchsets on their own.
Also contributors may be discouraged from further contribution by the slow nature of the work.
Wine has a staging project this: https://github.com/wine-staging/wine-staging
Ghidra has about 170 open merge requests atm so it should also have such a feature/project to provide bleeding edge "safely" to end users.
Maintainer(s) should know most parts of Ghidra which I sadly don't have.
So I am searching for volunteer(s) to maintain such a project ...
Beta Was this translation helpful? Give feedback.
All reactions