Addendum... I forgot to also say package maintainers should have review authority. The only reason any of the lead maintainers should act is in their absence.
Please discuss. I believe we should bring this up at our next meeting next weekend. GC On Wed, Sep 3, 2025 at 10:50 PM Gregory Casamento <[email protected]> wrote: > Hugo, > > This is an excellent suggestion... > > I've given this some thought in the past and I've probably been guilty of > this on occasion as well. I agree with this approach as it will protect > against just anything getting into the master branch by mistake. Such an > approach should require an approval from any one of: > > myself, > richard frith-macdonald, > fred kiefer, > riccardo motolla > > since the above are the maintainers of the core packages. This should be > followed up by the package maintainer themselves. > > The issue I have had with taking this approach is the sheer number of > packages included in GNUstep and, up until now, what we have been doing has > been working with minimal interference. > > This is something that needs to be agreed to by the team. My thoughts on > this have been the following: > > - Require PRs from feature branches > - Require CI to pass before merge - This needs to be a hard > requirement even if we don't do this. > - Minimum 1–2 reviews (Code Owners where applicable) > - No force‑push; squash or merge‑commit only - Preserves history > - Reverts for any violations, followed by a short > explaination/retrospective on why > > Whatever workflow we agree on needs to be documented and put into a > CONTRIBUTING.md or other documentation to make the process clear. > > Only code owners should be able to directly commit to their own repo, or > myself, as lead maintainer. > > Yours, GC > > On Wed, Sep 3, 2025 at 12:05 PM Hugo Melder <[email protected]> wrote: > >> Hi, >> >> >> In the past weeks I have seen pushes to the master branch that did not >> go through a proper review process. Some of the commits did not even >> pass the CI. >> >> Can we please move to a sane approach and protect the master branch? All >> work shall be done on feature branches instead, according to best >> practice. We have been doing this in libobjc2 for years now and it works >> great. >> >> I'm mostly concerned about gnustep-base right now. >> >> Best, >> >> Hugo >> >> >> > > -- > Gregory Casamento > GNUstep Lead Developer / Black Lotus, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.patreon.com/bePatron?u=352392 - Become a Patron > https://www.openhub.net/languages/objective_c > https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation > -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://www.openhub.net/languages/objective_c https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation
