> > > I really dislike Github's decentralized approach with PR and having to >> have separate clones of the repo within each user. My understanding is if >> two people have different fixes, then they individually submit PRs that are >> not explicitly linked with each other, much less with a specific bug report >> issue. It is not so uncommon that people end up working on competing >> proposals or on the same branch, both of which are not natural using >> Githubs PR system (I am not even entirely sure how I should do this either; >> Do I have to clone from their repo? Is it the same remote? Where is the >> documentation on this? Can I still access the branch if someone deletes >> their account?). How do other projects at the scale of Sage deal with this? > > > It seems you never reviewed a non-trivial PR on GitHub, no? >
Not at the scale of some of the tickets for Sage (most of it has been fairly small patches), and that is the problem. It is not at all clear how I should do that unlike our current setup. > Well, you can go and have a look how e.g. CPython does it, or SciPy. > Thank you for the pointer. You wouldn't happen to have specific cases that would make for good examples of the behaviors I mentioned above? > > The PR process and the underlying structure is very well-documented. > The basics, yes. I didn't see examples of anything beyond "contributor contributes code, then reviewer with project repo permissions reviews and merges it." > A PR creates a branch in the git repo of the "main" > project. This is really not much different from what we do on trac, except > that the branch name > satisfied different rules. > There is a big difference you aren't even mentioning: You need to fork the repo locally to your UN, which has some additional setup that needs to be done. Have a look at > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally > That sure looks like what you do when you are a developer for the project, and you get the PRs. It doesn't talk about what to do with someone else"s repo. The key title words are "*your* repository." > > E.g. using https://github.com/scipy/scipy/pull/14786 as an example, the > underlying branch in the repo of scipy is > named pull/14786. > > To examine it locally on your machine you can use plain git to fetch it, > or you can use GitHub's > tool called cli (its functionality is close to what git-trac does, not > sure if you use or used git-trac, though). > It is not clear that if I can pull the branch from origin. There are lots of technical issues and questions I have that are not documented, or at least that I can easily find after skimming through things for a few minutes. 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. > > Besides, nobody forces you to use a PR to review something. You can open > an issue, and ask for a specific branch somewhere (in a fork, or even in a > completely unrelated git branch hosted outside of GitHub) to be reviewed, > and only do a PR once the branch in question is stabilized. > At the end of the day, all paths lead to PRs. A rose by any other name still has thorns one needs to be careful of. Honestly, I doubt we are loosing that many quality contributors by not >> using Github's system since we can have people with GH login's to access >> trac. >> > > except that this is broken now, (along with automatic management of ssh > keys in general) and one needs > a tricky manual process (modifying a special gitolite git repo used by > trac) by one of trac admins > to add/modify ssh keys. > (and I am not even sure whether this manual process does not lead to an > eventual breakage of the ssh keystore, it's all tied up > with trac in a rather arcane way). > This is a definite problem. > > 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? You haven't said how people use it as any sort of counter argument. I also made a very clear point about git commands. Our workflow won't fundamentally change: (1) make ticket (GH lingo is open issue) (2) make changes (3) test code locally (4) polish code and documentation (5) push for review (6) undertake review (7) give offerings to Volker for his majesty and grace of being a great release manager. A little different interface for someone to learn is not really that hard. > > Some of this could be my lack of experience with Github (and a bit of "get >> off my lawn with your facegrams"), but right now I feel like the move to >> Github is like starting a car to go to the party in the next town without >> learning how to drive, much less knowing the route. >> > > What's the alternative? > You mean beyond spending the time to fix it instead of pushing us into the pool and hoping we swim? > Would you like to contribute your time to do our time-consuming trac etc > devops? > I would be willing, although I expect to be hit by an approximate 3kg (very cute) bus within the next week or two. You need much more of a plan than simply saying "its easy because other people use it". I definitely don't want to be the dog who caught the car. That will be far more painful than what this move already will be. > > Anyway, trac is obsolete software used mainly to maintain legacy projects > which don't even use git, > and we'd have to move sooner or later to something that is robust and > maintained, and is not an endless > timesink to keep working. And trac is only a part of the general Sage > devops nightmare, created largerly by > sticking to semi-obsolete tools for too long. > > I think you have pointed at exactly one question - you didn't know how to > deal with git branches of GitHub's PR. > This is a horrible oversimplication of my post at best. > I hope you see now that it's trivial. Do you have any other objections? > > No, it is not. Quit brushing it aside and saying it is trivial while pointing to a massive stack of pages that doesn't answer any of my questions. I am sorry if my response is coming across harsh, but I don't appreciate a bunch of stawman arguments and condensation as an answer. If it is as easy as you claim it is, then you should be able to actually explain it with examples. When we switched to git from Mg, we spent a week experimenting with a variety of things with trying to find a good approach. We could also experiment with the community during that time to refine our practices. With this potential migration, it is either the Githubway or the highway and there is no way back. 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/74fec0da-dd2b-4e77-b708-c789c2c62e35n%40googlegroups.com.
