A fair point made: an "exit strategy" from Github should exist and should ideally take into account that this exit may need to happen at a time where github is no longer able/willing to cooperate in this exit: in other words, we should ideally *back up* our issues and pull-request histories. The APIs are there; writing the scripts to pull this stuff (incrementally?) would be quite a bit of work, but then running it shouldn't be so bad.
This is just common sense data security policy: to us github is a single point-of-failure. You want to store with some frequency snapshots of the data there. On Tuesday, 27 September 2022 at 14:45:51 UTC-7 tobias...@gmail.com wrote: > Okay, fair enough! Then it's a bit more work to get tickets into PRs (for > devs) but maybe its a good idea to start with a clean slate. > > On Tuesday, 27 September 2022 at 22:31:57 UTC+2 dim...@gmail.com wrote: > >> >> >> On Tue, 27 Sep 2022, 21:12 Tobias Diez, <tobias...@gmail.com> wrote: >> >>> Just to make sure we are talking about the same thing. Imagine a >>> currently open ticket with a linked branch. How is this going to be >>> migrated? My assumption has been that this will create a PR from >>> sagemath/sagetrac-mirror/branch into sagemath/sage. >>> >> >> No, there will be an issue on sagemath/sage, no PR. There will be a link >> to a branch on sagetrac-mirror (which will be readonly). >> >> To proceed, just push this branch to your personal fork of sagemath/sage >> and make a PR from there. >> At this point it becomes a usual github workflow. >> >> >>> If thats indeed the plan (which I find is a good plan), then there are >>> the following issues: >>> - sagetrac-mirror is not a fork of sage, thus it might not be possible >>> to create a PR from it (at leas from the web interface its not possible, >>> not sure about the API) >>> - sagetrac-mirror cannot be archived otherwise it will be readonly (this >>> is taken care of my Matthias recent edit to the migration wiki page) >>> - devs might not have the permission to push to sagetrac-mirror >>> (currently there is a branch protection rule in place that prevents any >>> direct commits, but even if that's removed I'm not sure if everyone can >>> just push to it) >>> >> >> all this is avoided if done as I described above >> >> Dima >> >> >>> On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote: >>> >>>> >>>> >>>> On Tue, 27 Sep 2022, 14:08 Tobias Diez, <tobias...@gmail.com> wrote: >>>> >>>>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but >>>>> the source will be sagemath/sagetrac-mirror, right? >>>> >>>> >>>> >>>> Hmm, I might have missed something - what is the need to have 2 repos >>>> here, if 1 is sufficient? >>>> >>>> Any fork of sagemath/sage may be a source of a PR, not only >>>> sagetrac-mirror >>>> >>>> >>>> So in order to update the pull request one needs to push the changes to >>>>> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to >>>>> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is >>>>> archived (and thus readonly), the only way to work on existing >>>>> tickets/branches would be to checkout the existing branch (from either >>>>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, >>>>> create a new PR, close the old PR (essentially the workflow >>>>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally >>>>> ). >>>>> >>>>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com >>>>> wrote: >>>>> >>>>>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez <tobias...@gmail.com> >>>>>> wrote: >>>>>> > >>>>>> > One more question: The current plan is to use the sagetrac-mirror >>>>>> repo as the base for creating PRs but also to archived it. However, if >>>>>> I'm >>>>>> not mistaken, that makes all branches in sagetrac-mirror readonly and >>>>>> thus >>>>>> one cannot continue working on existing PRs by pushing to the >>>>>> corresponding >>>>>> branch in sagetrac-mirror. >>>>>> >>>>>> IMHO the plan is to create new PRs in sagemath/sage, not in >>>>>> sagemath/sagetrac-mirror >>>>>> There won't be "existing" PRs, only issues, pointing to branches on >>>>>> sagetrac-mirror >>>>>> >>>>>> >>>>>> >>>>>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb....@gmail.com >>>>>> wrote: >>>>>> >> >>>>>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 >>>>>> UTC+2: >>>>>> >>> >>>>>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 >>>>>> wrote: >>>>>> >>>> >>>>>> >>>> Is it possible to choose the issue numbers in GH when making a >>>>>> migration? Then, setting a redirect of the form " >>>>>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> >>>>>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make >>>>>> the lion's share of the links still relevant. >>>>>> >>> >>>>>> >>> >>>>>> >>> Yes, to map it like this is the plan. >>>>>> >>> >>>>>> >>>> >>>>>> >>>> This does not preserve fragments like "#comment:7", which is >>>>>> useful in long ticket discussions. >>>>>> >>> >>>>>> >>> >>>>>> >>> Thanks, I've opened >>>>>> https://github.com/sagemath/trac-to-github/issues/7 for this. >>>>>> >> >>>>>> >> Don’t we need an issue for the first point, as well? The example >>>>>> #26 corresponds to #34110 which is not easy to recover from the migrated >>>>>> information. >>>>>> >> >>>>>> >> Furthermore, it isn’t still clear to me how dependencies between >>>>>> PRs will be visible (like in the Trac dependencies field). In the above >>>>>> example you have to recover this from the history of commit messages >>>>>> (which >>>>>> may not be clear enough in general). Shouldn’t the migration put >>>>>> something >>>>>> into the header fields milestone, assignees, …, as well (if possible)? >>>>>> How >>>>>> will authors and reviewers be visible? >>>>>> > >>>>>> > -- >>>>>> > 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+...@googlegroups.com. >>>>>> > To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/sage-devel/d815783e-fd5c-4aa3-ab27-7024b18b299dn%40googlegroups.com. >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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+...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/sage-devel/6df40198-0d1a-45f4-ac1f-2bee6e07d313n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/sage-devel/6df40198-0d1a-45f4-ac1f-2bee6e07d313n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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+...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sage-devel/cb7d6705-09e1-41ee-9f9a-1543c4b097a9n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/sage-devel/cb7d6705-09e1-41ee-9f9a-1543c4b097a9n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/d7905bca-fd59-4511-baa4-ac04b85383cdn%40googlegroups.com.
