What is the proposed workflow to merge the develop branch after a new release into PR (or other) branches of your fork (i.e re-basing)? Obviously this is possible by pushing on sync in the web interface or typing gh repo sync USERNAME/sage -b branch in the command line. But how do you resolve conflicts?
BTW: I’m not sure I like this! If a PR is linked to the Issue, you can alternatively comment on the PR. It sounds like wasting time by searching for comments. Can’t we define a preference here? This seems to be a part of the decentralized structure that Travis is criticizing. Matthias Koeppe schrieb am Mittwoch, 14. September 2022 um 23:19:28 UTC+2: > I think for now we only need to describe the process up to the point of > "positive review". > The discussion on how to do release management etc. is best held when > Volker finds the time to join the discussion on these things. > > On Wednesday, September 14, 2022 at 1:58:40 AM UTC-7 tobias...@gmail.com > wrote: > >> I think we need also another branch "merge-queue" which serves as the >> target for pull requests, with branch protection rules linear history, >> require positive review and checks. >> >> Also "Release Manager @vbraun merges positively reviewed tickets into his >> branch https://github.com/vbraun/sage"; should then be replaced by >> "Release Manager @vbraun merges positively reviewed tickets into the branch >> merge-queue". You cannot really "merge" pull requests against one repo into >> another one. >> >> Moreover, I propose to realize "To make a beta or stable release, Release >> Manager merges (fast-forward) his branch into the develop branch and >> creates a tag" by a pull-request from "merge-queue" into "develop". This PR >> could then trigger the corresponding github action checks that should pass >> before a beta is released. >> >> On Wednesday, 14 September 2022 at 07:50:48 UTC+2 Matthias Koeppe wrote: >> >>> On Tuesday, September 13, 2022 at 10:26:04 PM UTC-7 David Roe wrote: >>> >>>> My understanding from the >>>> allowing-changes-to-a-pull-request-branch-created-from-a-fork >>>> documentation >>>> <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork> >>>> is >>>> that only users who have push permission on the repository will be able to >>>> make edits to a pull request. I think the consequence is that we want >>>> active Sage developers to have Write access >>>> <https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization> >>>> >>>> to the repository, and then use branch protection rules >>>> <https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches> >>>> >>>> on develop and master. >>>> >>>>> >>>>> >>> Yes, please take a look at >>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections, >>> >>> where I have started to write something like this. >>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ae0f1f0f-f68a-4169-8c5b-6b66a2937fc9n%40googlegroups.com.
