On Thu, Aug 23, 2018 at 6:13 AM Julian Rüth <julian.ru...@fsfe.org> wrote: > > Hello Jeroen, > > I agree that fragmentation can be a problem. Then again, I think that > sometimes splitting discussion on the issue and the discussion on an actual > attempt to solve that issue can be useful; at least it doesn't feel unnatural > to me. Also being able to create a new merge request can be nice if you > actually want to start from scratch. But sure, what you described is much > more common:
I would add that in practice I've rarely found this to be too much of a problem. For most issues you will have at most one pull request; maybe two. And discussions on pull requests tend to remain focused on the substance of the code changes, than the substance of the issue itself (except in the case where an issue is raised *and* a fix is proposed simultaneously in a pull request--this can happen frequently which is why I don't like the forced "issue" vs "pull request" distinction). In this case the solution is usually to just open another pull request, if you have an alternative proposal. I think it rarely leads to an overly difficult to follow discussion. Not saying it doesn't happen though. > On Wednesday, August 22, 2018 at 9:24:36 PM UTC+2, Jeroen Demeyer wrote: >> >> [...] Something that regularly happens on the Sage Trac: >> >> 1. Somebody creates an issue >> 2. Somebody (the same or other person) adds a branch >> 3. Somebody else forks that branch and adds a reviewer patch >> >> In the GitHub model, you now have 1 issue and 2 pull requests for >> exactly the same issue. Even if cross-links are added, you still end up >> with spaghetti discussions. > > > In most projects, the reviewers are the people who actually have the power to > merge and so GitHub/GitLab want you to check "allow edit from maintainers" > when creating a Pull/Merge Request to allow reviewer patches. But that won't > work for Sage's development model. One way around this would be to encourage > creation of Merge Requests from a shared namespace such as > https://gitlab.com/sagemath/dev/sage where everybody developing Sage would > have push access. This would be somewhat similar to the current public > namespace in the git repository that is connected to trac. That's a good point, and a use case for that I hadn't considered. Anyone on the sage-devel team can be given write access to sagemath/dev/sage and can create branches there to make merge requests from, rather than from a private fork. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
