Forgot to attach screenshot. On Tue, Aug 21, 2018 at 10:43 AM Erik Bray <erik.m.b...@gmail.com> wrote: > > Hi all, > > Earlier this spring Julian Rüth and I sat down and created a mirror of > Sage's repository over at GitLab: > > https://gitlab.com/sagemath/sage > > This is in addition to the existing mirror at GitHub, for which we > have no immediate plans except to have it link to the GitLab mirror. > > The reasons for this are several--in particular, Julian has put > considerable work into a new advisory continuous integration system > for Sage built on top of GitLab's CI pipeline system. It's quite > nice, as the result of each built is a Docker image which can be run > and tested in mybinder.org. With the exception of testing on unusual > platforms, this means that proposed changes in tickets--if they indeed > build successfully--will be easy to manually try out and play with > without having to build them one's self. > > I will let Julian say more about that when he's ready to. I am > bringing up the GitLab mirror for a different, but related reason, > which is that I would like to start allowing submissions to Sage to be > made via "merge requests" on GitLab (a.k.a. pull requests in GitHub > parlance). > > Why GitLab? In short, we felt it would likely be more acceptable to > most members of the Sage community; this was a feeling we had even > before the Microsoft's acquisition of GitHub was announced. First of > all, GitLab is open-core, meaning that the majority of their software > is open source, but for paying customers there are additional features > that are not made open source. This, in addition to providing higher > level of support to paying customers, is the basis of their business > model. But IMO it is more inherently open source-friendly than, say, > GitHub. > > Second of all, while we are currently using the free hosting providing > by gitlab.com, which frees us from both the cost in money and time of > having to maintain our own GitLab server, GitLab makes it quite easy > (I have done it myself) to self-host a GitLab server. So should > anything ever go awry with gitlab.com, we can always export the > project to a self-hosted server as we do currently with Trac. > > A second clarification to make is that we are not currently proposing > to do away with Trac for Sage's ticket database, and we do not intend > to open up the full issue tracker on GitLab. Instead, we only want to > be able to accept merge requests, as we believe that enabling the > popular "GitHub-style workflow" will make it easier and friendlier for > new contributors to submit changes to Sage. For an immediate use case > of this that I have in mind, I would like to make it easier for users > to submit documentation fixes: https://trac.sagemath.org/ticket/25914 > > In order that this does not overly disrupt the existing workflow, I > have created a bot that automatically syncs GitLab merge requests to a > Trac ticket, including synchronization of the branch being proposed > for merging. This would allow Volker to continue merging positively > reviewed tickets as usual, and (in theory) never even have to touch > GitLab. You can see an example of any auto-generated ticket attached. > If there are suggestions as to how exactly the auto-generated tickets > are formatted I'm open to them--I know it's not exactly perfect as-is. > But those are details. > > The only major downside I see is fragmentation of the discussion of a > merge request: Comments can be made either on GitLab itself, or in the > auto-generated Trac ticket. I do not yet have a specific > recommendation for that in mind, and we may need to experiment. I > considered having the bot synchronize comments as well, but that could > get even more confusing. One thing I will say though, is that GitLab > merge requests will give us superior code-review tools, such as the > ability to leave comments inline with the diff. I'd like to just try > it and see how it goes, but I'm also open to suggestions. > > There is also precedent for this model in other projects with legacy > issue trackers. Most notably, of late, CPython itself, which started > accepting pull requests through GitHub. I haven't seen too much > complaint about the discussion being fragemented. For the most part > discussions about the details of issues and what to do about them stay > on the issue tracker, while discussions about code details (i.e. code > review) stay on GitHub, though this is not cut-and-dry. A recent > informal poll of the CPython developers as to how this workflow is > going was almost entirely positive: > https://mail.python.org/pipermail/python-dev/2018-February/152200.html > > Some of you may remember this is not a first for Sage either: some > time ago there was a similar experiment done with GitHub, but it fell > unmaintained. If anyone has any lessons learned from that time, > please add them. > > What does everyone think? Is there anyone opposed to going ahead and > opening up merge requests?
-- 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.
