On Tue, 13 Sep 2022, 04:39 'Travis Scrimshaw' via sage-devel, < sage-devel@googlegroups.com> wrote:
> 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. > Even setting aside the immediate operational problems with trac, which are lingering on for about 3 weeks now, with no end in sight, we still have to move. I don't think we need a formal vote. Holding it is akin to voting on whether to stay 32-bit, or move to 64-bit... Yes, we have some people saying they prefer to stay on trac, but we don't have resources to stay on trac. And trac, as a project, is going away by itself. It is a bug, essentially, that we are still on trac. Do we need a vote to fix a bug, or not? I think we don't. Dima > 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 > <https://groups.google.com/d/msgid/sage-devel/289aebe9-8f62-434a-b190-be5dad1a3b2dn%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/CAAWYfq3wviCsgePJMKJ_09GMrma7RHKqYNLsfmd8e4o3LQJWLw%40mail.gmail.com.
