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

Project Conventions: Merging Pull Requests #2283

codebrainz opened this issue Aug 31, 2019 · 1 comment


Copy link

commented Aug 31, 2019

This issue is to continue discussion in the comments of #2178 and #2270 regarding the conventions/etiquette of merging a PR, especially one's own.

I suggest we categorize PRs (either using Github labels or own judgment) into the following types which probably will have different "rules" for merging:

  • Obvious bug fix in the code or docs.
  • Code refactoring/cleanup or larger restructuring/rewording the docs.
  • Changes to the public plugin API
  • Small UI change
  • Changing default/original behaviour of something
  • Large UI change
  • Larger more structural changes to the code

Feel free to edit the description and re-word those or add others which are surely missing.

The criteria for a PR being mergeable might include such this as:

  • None
  • Waiting at least N days to see if anyone cares/objects.
  • At least N people must approve the PR explicitly using Github "review" stuff.
  • At least N people must have done a proper code review.
  • At least N people must have actually tested it.
  • It must be tested on X platforms.

Again, feel free to edit/add to this list.

I guess with the above lists, it's just a matter of attaching the criteria to each type of PR, and then codifying that somewhere like HACKING, the wiki, a new CONTRIBUTING file, or wherever. One way to do this association might be to do some simple polls of the contributors.


This comment has been minimized.

Copy link

commented Aug 31, 2019

Continued from #2178 comment.

As noted on #2178 and many other previous issues/PRs etc actually integrating large changes is difficult.

Starting as a small project Geany has many functionalities integrated in code, and they need to be disintegrated 😁 to allow other (probably plugin) code to take them over.

I am afraid I don't have any new insights, just the same as I have said before, git branches, separate these radical makeovers from the stable version until they are ready to replace it, then release Geany to show its a major change.

And (dare I say it) do a GTK and break some stuff, but with plenty of warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.