On Mon, Sep 3, 2018 at 3:53 PM Erik Bray <erik.m.b...@gmail.com> wrote: > > 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? > > Now that the OpenDreamKit reporting period is over (at least to the > extent that I'm responsible for anything), I would like to re-raise > this issue one more time. > > To take a straw poll based on the responses so far, there are: > > 4x +1 (not including myself, which is an additional +1) > 1x +0 (how I am interpreting Dima's response, which did not include > an explicit +1 but seems positive; he can correct me) > 2x -0 (how I am interpreting Jeroen and Simon's responses, pending > some explicit correction from them) > > To answer again some of the concerns that have been raised, if I am to > be honest I am in favor, long term, of moving away from Trac entirely. > However, that is *not* what is being proposed here, and I have no > concrete plan for a full move off of Trac. If this does lead to a > "slippery slope" of more people wanting to move to GitLab from Trac I > see that as a positive thing: For all the advantages of Trac, if > enough people see a net positive to using a new tool, then so be it. > However, it will be hard for the community to even get a feel for > other tools if we don't (optionally) incorporate them into our exiting > workflow at some level. > > I'll leave this open for more comments until the end of this week > before making any moves.
I've been trying to get back to this for a few weeks now. Based on the latest straw poll that's +8 in favor and -2 against (I am counting Simon and Jeroen now as -1 each). Given the general overall favorability of the plan I've gone ahead and enabled it. But I won't advertise it much yet--not until we've tried it out a bit and worked out the kinks. I will try making a few merge requests next time I have some branches to push to Sage. And others are certainly welcome to try it as well. To do so you would fork https://gitlab.com/sagemath/sage and then submit your branch as a merge request back to that repository. If you don't want to make a personal fork, you can also request to be added to the https://gitlab.com/sagemath/dev/sage. There you can also make as many branches as you like, and also submit merge requests to the main repo (sagemath/sage) from there. -- 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.
