Document how to continue working on a ticket with existing branch after the migration

[mkoeppe]

https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md#proposed-workflow-on-github-with-transition-guide-from-trac

[kwankyu]

What is the how-to?

I suppose the ticket is migrated as an "issue" linked to a branch in sagetrac-mirror. Then the author can use the branch for a new PR for the issue. Is this that how-to?

[mkoeppe]

Yes, I think that's it

[tobiasdiez]

But according to #73, the branches in sagemath/sagetrac-mirror are then readonly, right? So one would need to first create a new copy of the sagetrac-mirror branch it one's own fork and create then a PR from the fork. Or do I miss something?

Alternatively, we could give everyone write-access to sagetrac-mirror.

[mkoeppe]

But according to #73, the branches in sagemath/sagetrac-mirror are then readonly, right? So one would need to first create a new copy of the sagetrac-mirror branch it one's own fork and create then a PR from the fork.

You are right; we had this discussion before.

sagetrac-mirror must be archived so that we don't compromise the links to branches and commits that we create in the migration of the tickets.

[mkoeppe]

I've added instructions to set up a trac remote for the purpose of fetching old branches in 6e55223

[soehms]

What is left to do here?

[mkoeppe]

Need a bullet point on the same level as "For contributing a change that addresses an existing open Issue" in https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md that explains the procedure

[soehms]

Need a bullet point on the same level as "For contributing a change that addresses an existing open Issue" in https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md that explains the procedure

I see! I make a proposal in PR #151.

It is still not clear to me how collaboration on an issue or PR will work. With Trac we use to pull the (user or public) branch shown on the ticket header, modify it, push it back to ones own user or public branch and modify the branch field accordingly. If we want a similar workflow on GitHub the user who created the PR (resp. the first PR of an issue) needs to invite others as collaborator to his fork.

If not, we will get multiple PRs on one issue as it happened for example with issue #18 in this repository. But for Sage development we will have much longer cycles for a PR to be merged. So it can happen that there are more than one PRs for an issue (such that the current one corrects the preceding one, as we do on Trac when we changed the branch field). How shall we treat this situation? How should the preceding PR be marked such that it can be dismissed afterwards?