First off, we need to slow down significantly as we do not have an general clear consensus about doing this move. A few people are yelling we should move to GH, and a lot of the same people are acting like has been decided when it has not. We should make a formal vote once a more concrete proposal has been placed forward.
On Tuesday, September 13, 2022 at 4:36:04 AM UTC+9 Matthias Koeppe wrote: > On Saturday, September 10, 2022 at 7:39:10 AM UTC-7 Travis Scrimshaw wrote: > >> [........] There are lots of technical issues and questions I have that >>> [I cannot] easily find after skimming through things for a few minutes. >>> >> > Everything about GitHub has excellent documentation, and we have an > executive summary now at > https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, with > pointers to the relevant bits. > This is still does not contain much of any details about the collaboration process. It is basically contains the simple single-author--single-reviewer model (that is easy to find) and a thesaurus of terms. What happens when Bob works on a ticket, but then stops (say, it doesn't find a reviewer in time). Now Alice wants to make changes on top of that branch. How does Alice do that? I am particularly thinking about when this is *not* meant to be a PR review commit (say, it is working with a more substantial change or just cherry-picking some of the commits). When she is done, does she do a new PR? After doing quite a bit of digging, I finally found the answer: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally So there is a mechanism for it, but it is not as straightforward as before. How do we deal with the PR pollution? > >> It stays there even if the user GitHub account is closed (the latter >>> triggers an automatic closure of the PR, but the underlying >>> branch remains in the repo, it can be worked on just the same using git) >>> >> >> Which repo? Either way, this seems like a regression compared to our >> current setup, where if a user quits, then branch, ticket, and everything >> remains. >> > > No, this is an imaginary problem. The branch of the pull request persists > in the sagemath repo (see > https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, > which explains the name of the branch) even if the user and their repo > disappears. > Okay, thanks. The extra information clarifies things. > > Getting the login credentials was the biggest barrier; everything else is >>>> mostly straightforward and based on very simple git commands. >>>> >>> >>>> Right now, I find there are way too many practical questions and >>>> barriers for how we develop that make moving to Git**b a much bigger pain >>>> that people will think it is. >>>> >>> >>> Travis, many people nowadays never used git without GitHub or GitLab. >>> For such a person it's a major pain to >>> learn our workflow. >>> >> >> Do you really believe that everyone is using the web interface to make >> edits to the code and not using some form of git locally (either command >> line or GUI based)? >> > The web interface has major problems, such as not being able to run tests >> locally, in addition to being unwieldy with a project on the scale of Sage. >> Honestly, people really don't use "git pull", "git push", "git commit" when >> working with *Git*hub? >> > > Nothing like this is being proposed. No, GitHub is not a replacement for > git. Yes, you will continue to use git commands to pull, push, commit. > > But people nowadays who start with GitHub never have to go through archaic > setup steps such as those that we document at > https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh, > > which --- even when it is working --- is major friction for the project. > I think it has been just far too long since you uploaded your ssh key to GH. The server cannot magically know your ssh public key. Yes, we don't have https support, but other than the most casual of contributors will use that for push/pull. I highly doubt anyone will use that feature with any serious commits. It seems like there are just as many one-time setup costs needing to be done from the proposal document that require more explanation of what they do. I think you are making a distinction without a difference here. > And people can use modern IDEs, in particular VS Code, which have > excellent integration with GitHub: see for example > https://code.visualstudio.com/docs/editor/github > This is a good reason for switching (not that I use any of them). > And yes, there's also a command-line interface to GitHub, see > https://trac.sagemath.org/ticket/34523, which does everything that "git > trac" can do and much more. > That isn't a good argument for me: I have always wanted to throw fire and holy water on those commands. ;) However, they did make it easier for people who were afraid to do https://imgs.xkcd.com/comics/git_2x.png. > > >> You need much more of a plan than simply saying "its easy because other >> people use it". >> > > Available now at > https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b > > Thank you. The downside (that will always remain to me) with GH/GL is anything with their web interface is highly decentralized, whereas with trac, things are highly concentrated on tickets, which are a single point of reference. Using the GH/GL model, we have all of these forks (which we have to tell newbies are not the same as branches and should not be used as such). There is also more manual things we have to type and sync subject to human (typo) error. This is likely manageable to me compared to some of the other benefits (although I will personally experience none of those). Despite this, I still have reservations about the increased pains of development from trying to fit a mostly square peg into a round hole, and subsequently am still opposed to the move (even assuming you are able to move the information on trac over). Best, Travis -- 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/289aebe9-8f62-434a-b190-be5dad1a3b2dn%40googlegroups.com.
