[sage-devel] Re: Enabling Merge Requests from GitLab
On Mon, Sep 3, 2018 at 3:53 PM Erik Bray wrote: > > On Tue, Aug 21, 2018 at 10:43 AM Erik Bray 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
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Tue, Sep 4, 2018 at 3:02 PM Daniel Krenn wrote: > > On 09/04/2018 02:33 PM, Jeroen Demeyer wrote: > > Let me make one important comment (something that I've said before > > though): a large part of what makes the current workflow work is not so > > much Trac itself but our git server and the "git trac" scripts. > > > > For example, I very much like the fact that we have a single git repo > > where all pull requests appear. Checking out a pull request for > > reviewing is so much easier with Sage than it is with typical GitHub > > projects. If we ever move to GitLab, we really should keep this workflow. > > This should not be a problem (i.e. adapting git-trac to a git-gitlab) as > Gitlab has a convenient API. > > See, for example, > https://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr > which provides all information needed. Here's a real world sample of using the GitLab API from the GitLab<->Trac bot. In particular, linked is the method that closes a merge request if the associated Trac ticket is closed. It's fairly simple: https://github.com/sagemath/sage_trac_plugin/blob/master/sage_trac/gitlab.py#L416 And it would be even simpler if I were using the Python API that exists for GitLab; here I was just lazy about it, and wanted to get more direct experience with the HTTP API directly (since it was only for a few simple cases) before switching over to the higher-level Pythonic API. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
Keeping in mind that this is still sort of off-topic, in my mind, from the subject at hand which is allowing merge request submissions from GitLab, which still get turned into Trac tickets... On Tue, Sep 4, 2018 at 2:33 PM Jeroen Demeyer wrote: > > Let me make one important comment (something that I've said before > though): a large part of what makes the current workflow work is not so > much Trac itself but our git server and the "git trac" scripts. Which is in no way unique to Trac. In fact they're part of the custom cobbled-together way we use git + trac. For GitHub there is the very popular "hub" CLI which does the same thing. For GitLab the options are a bit more scattered. This program called "lab" (which mysteriously is hosted on GitHub) purports to wrap "hub" to add GitLab support: https://github.com/zaquestion/lab Admittedly I have not tried it. Even if you love the "git trac" command it would be easy to adapt to GitLab's API. In either case I'm all for having easy to use command-line tools but that is in no way particular to Trac. > For example, I very much like the fact that we have a single git repo > where all pull requests appear. Checking out a pull request for > reviewing is so much easier with Sage than it is with typical GitHub > projects. If we ever move to GitLab, we really should keep this workflow. I don't like it. I think it's a mess; especially since people don't delete their branches after they're merged (I have not been as good about that myself as I would like). But that's also why we set up https://gitlab.com/sagemath/dev/sage , which mirrors all the trac branches, and that anyone granted write access can create branches on, and create merge requests from those branches. I find it odd that you put these two issues side-by-side, since having a good CLI tool also makes it trivial to check out a branch from a remote fork *shrug* -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On 09/04/2018 02:33 PM, Jeroen Demeyer wrote: > Let me make one important comment (something that I've said before > though): a large part of what makes the current workflow work is not so > much Trac itself but our git server and the "git trac" scripts. > > For example, I very much like the fact that we have a single git repo > where all pull requests appear. Checking out a pull request for > reviewing is so much easier with Sage than it is with typical GitHub > projects. If we ever move to GitLab, we really should keep this workflow. This should not be a problem (i.e. adapting git-trac to a git-gitlab) as Gitlab has a convenient API. See, for example, https://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr which provides all information needed. Daniel -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Tue, Sep 4, 2018 at 2:33 PM Jeroen Demeyer wrote: > > Let me make one important comment (something that I've said before > though): a large part of what makes the current workflow work is not so > much Trac itself but our git server and the "git trac" scripts. > > For example, I very much like the fact that we have a single git repo > where all pull requests appear. Checking out a pull request for > reviewing is so much easier with Sage than it is with typical GitHub > projects. Why? A GitHub pull request at a repo X is, internally, a branch on the repo X. So you can change the branch on your clone of X, just as you do on a single git repo workflow. See https://help.github.com/articles/checking-out-pull-requests-locally/ (or https://hub.github.com/hub-checkout.1.html - if you want to use their command line tool 'hub') Dima > If we ever move to GitLab, we really should keep this workflow. > > -- > 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. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
Let me make one important comment (something that I've said before though): a large part of what makes the current workflow work is not so much Trac itself but our git server and the "git trac" scripts. For example, I very much like the fact that we have a single git repo where all pull requests appear. Checking out a pull request for reviewing is so much easier with Sage than it is with typical GitHub projects. If we ever move to GitLab, we really should keep this workflow. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Mon, Sep 3, 2018 at 5:04 PM Jeroen Demeyer wrote: > > On 2018-09-03 15:53, Erik Bray wrote: > > P.S. If anyone has additional comments, positive or negative, on > > https://trac.sagemath.org/ticket/25914 they would be most appreciated > > That doesn't seem the right ticket. No, that's the right one. It's the ticket that motivates enabling merge requests in the first place. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Mon, 3 Sep 2018, 16:54 Erik Bray, wrote: > On Tue, Aug 21, 2018 at 10:43 AM Erik Bray 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,
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On 2018-09-03 15:53, Erik Bray wrote: P.S. If anyone has additional comments, positive or negative, on https://trac.sagemath.org/ticket/25914 they would be most appreciated That doesn't seem the right ticket. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
The unfamiliar trac workflow was a barrier of entry for me, definitely delaying my first contribution. It has some advantages but having gitlab as an option for newcomers would be nice. +1 from me. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Mon, Sep 3, 2018 at 9:54 AM Erik Bray wrote: > On Tue, Aug 21, 2018 at 10:43 AM Erik Bray wrote: > > What does everyone think? Is there anyone opposed to going ahead and > > opening up merge requests? > > 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) > +1 from me as well. David -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
On Tue, Aug 21, 2018 at 10:43 AM Erik Bray 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
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Wed, Aug 22, 2018 at 10:25 PM Simon King wrote: > > Hi Erik, > > On 2018-08-22, Erik Bray wrote: > > Really the workflow is meant to be you create an issue first, and then > > you create one or more pull requests to resolve that issue. I am also > > a fan of being able to "elevate" an issue to a pull request. This is > > possible to do on GitHub through the web API and I have a script I use > > for it, but they're trying to discourage that, and I think even > > deprecate the ability to do so. I'm mystified as to why. > > I'd need A LOT more explanations. > > What is an "issue"? > What is a "pull request"? > > What exactly is the expected workflow on gitlab? Right now there isn't one. That's mostly outside the scope of this discussion because right now we are not enabling issue creation on GitLab. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On 08/23/2018 11:15 AM, Dima Pasechnik wrote: > github has a command line tool, called hub, allowing one to e.g. create pull > requests and issues, without using a browser. > https://hub.github.com/hub-pull-request.1.html > https://hub.github.com/hub-issue.1.html > > I don't know whether gitlab has something akin to hub. FWIW Gitlab has an API which allows doing stuff via e.g. a Python library; this is quite convenient for doing batch-jobs etc. [1] https://docs.gitlab.com/ee/api/ [2] https://github.com/python-gitlab/python-gitlab -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Simon, a very quick correspondence between trac and github/lab terms is as follows: trac ticket, no git branch - issue trac ticket, with a git branch - pull (merge, on gitlab) request github has a command line tool, called hub, allowing one to e.g. create pull requests and issues, without using a browser. https://hub.github.com/hub-pull-request.1.html https://hub.github.com/hub-issue.1.html I don't know whether gitlab has something akin to hub. -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Hi Erik, On 2018-08-22, Erik Bray wrote: > Really the workflow is meant to be you create an issue first, and then > you create one or more pull requests to resolve that issue. I am also > a fan of being able to "elevate" an issue to a pull request. This is > possible to do on GitHub through the web API and I have a script I use > for it, but they're trying to discourage that, and I think even > deprecate the ability to do so. I'm mystified as to why. I'd need A LOT more explanations. What is an "issue"? What is a "pull request"? What exactly is the expected workflow on gitlab? Best regards, Simon -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Wed, Aug 22, 2018 at 11:08 AM Simon King wrote: > > Tue 2018-08-21 08:43:19 UTC, Erik Bray: > > What does everyone think? Is there anyone opposed to going ahead and > > opening up merge requests? > > Is the plan to successively reduce the usage of our current trac system > and completely move to gitlab? In that case I would be rather reluctant. If I'm to be honest, that is *my* plan, but that is not the immediate plan for integrating with GitLab. At a certain point it makes little sense to maintain two parallel systems. But porting our existing database of Trac issues to another system would still be a massive undertaking and not trivial to get right. I say this as a former developer of Trac and someone who is generally a big proponent of it. I would still argue that its ticket and wiki systems are far superior to those offered by either GitHub or GitLab (Bitbucket tops both IMO but that's a controversial opinion). So I'm not in any hurry to move totally off of Trac, but in the long-term it makes little sense to me not to. This is a subject of controversy in the python-devel as well. Most people have been happy with using GitHub for pull requests, but there are still those who are hesitant to take the next step. There is, as of recently a draft PEP for migrating their issues to GitHub, but it is by no means settled: https://www.python.org/dev/peps/pep-0581/ Many of the arguments for and against apply for us as well, just s/Python/Sage/; s/bpo/trac/; s/GitHub/GitLab/. Though not all arguments apply--I would argue that what we have with Trac currently is much better than Python's old Roundup-based issue tracker. In the meantime I'm happy to take things one step at a time and reassess as we go. I am not 100% sold on moving entirely away from Trac, even if I believe it's inevitable. -- 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.
Re: [sage-devel] Re: Enabling Merge Requests from GitLab
On Tue, Aug 21, 2018 at 6:47 PM Eric Gourgoulhon wrote: > > Hi, > > Le mardi 21 août 2018 10:43:19 UTC+2, Erik Bray a écrit : >> >> >> 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. >> > > > +1 for privileging GitLab over Microsoft's GitHub. One thing I should make clear: This choice should not be taken as an opportunity for Microsoft bashing (which I am *not* accusing you of doing, but this wording made me think I should make a disclaimer). Prior to OpenDreamKit, Microsoft was one of the first, if not the first, organizations to provide direct funding for Sage development. At the time it was not nearly enough for what needed to be done. But I would certainly welcome more such funding, or other resources, such as donated resources on Azure for continuous integration / builds on Windows. There are also areas where I think Microsoft could really help Cygwin development by opening up more documentation on how the WSL works (an for those wondering, the WSL is as yet not a full replacement for Cygwin, or vice-versa). Of course, in the off chance I or anyone else are able to get some support from Microsoft again, if they placed certain conditions on it--such as using GitHub--we would be forced to decline. >> 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 > > > This sounds very nice! > >> >> >> What does everyone think? Is there anyone opposed to going ahead and >> opening up merge requests? > > > > A big +1 for going ahead! and many thanks for your work. Thanks! -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
No, I don't think this is the plan. Note also that "moving to gitlab" might mean two rather different things (on the surface they might look similar) * using gitlab's servers * self-host gitlab The latter case this would mean replacing trac, which does not age too well, as we see, with something much more modern and designed for using git from ground up. -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Tue 2018-08-21 08:43:19 UTC, Erik Bray: > What does everyone think? Is there anyone opposed to going ahead and > opening up merge requests? Is the plan to successively reduce the usage of our current trac system and completely move to gitlab? In that case I would be rather reluctant. Best regards, Simon -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Tue 2018-08-21 08:43:19 UTC, Erik Bray: > What does everyone think? Is there anyone opposed to going ahead and > opening up merge requests? Big +1 to going ahead with this. -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Hi, Le mardi 21 août 2018 10:43:19 UTC+2, Erik Bray a écrit : > > 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. > > +1 for privileging GitLab over Microsoft's GitHub. 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 This sounds very nice! > > What does everyone think? Is there anyone opposed to going ahead and > opening up merge requests? > A big +1 for going ahead! and many thanks for your work. Eric. -- 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.
[sage-devel] Re: Enabling Merge Requests from GitLab
Forgot to attach screenshot. On Tue, Aug 21, 2018 at 10:43 AM Erik Bray 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
