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.

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)

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+unsubscr...@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.

Reply via email to