[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] moving tickets forward
Hi - I'd like some guidance on how to move some of my tickets forward, #25351, for example. Once #25351 is closed, then we can move on to #25390, which depends on #25351 and will give us multivariate polynomial factorization over QQbar. Patchbot shows two test failures on #25351 involving magma. I don't think this is due to my changes, but I don't have magma, so how can I be sure? Is there a ticket somewhere that shows patchbot running with magma against 8.4.beta1? If not, it seems like a reasonable feature to have - something that shows any test failures against the current release tag. Other than that, the last comment on the ticket (by mmezzarobba) was positive, but that was six weeks ago. I've updated the ticket's git branch by merging in 8.4.beta1 and have resolved all of the patchbot failures other than the magma issues. Are there any suggestions on what else can I do to encourage forward movement on the ticket? Thanks. agape brent -- 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.
Re: [sage-devel] Enabling Merge Requests from GitLab
On Tue, Aug 21, 2018 at 1:43 AM, Erik Bray wrote: > 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. I think Robert Bradshaw set all of that up during a Sage Days, then went back to his normal fulltime job and basically didn't look at it again. So it was unmaintained just due to lack of time/focus, and not some deeper issue. > What does everyone think? Is there anyone opposed to going ahead and > opening up merge requests? > +1. Thanks!!! -- William (http://wstein.org) -- 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] Enabling Merge Requests from GitLab
On Tue, Aug 21, 2018 at 11:21 AM Daniel Krenn wrote:
>
> On 08/21/2018 10:43 AM, Erik Bray wrote:
> > https://gitlab.com/sagemath/sage
>
> How do I become a member of the SageMath group (or the project) in
> Gitlab? (username: dakrenn)
Just ask, like you just did :)
However, I think until / unless there's been more discussion about
this and how to use it, we will be limiting access for now until there
are processes set up.
For the most part, the main sagemath/sage repository is still going to
be a read only mirror of the git.sagemath.org repository, and will be
open only to merge requests, which must *not* be merged via GitLab;
rather a ticket on Trac would be opened, and once that ticket receives
positive review Volker would just merge as usual. The GitLab<->Trac
bot synchronizes the merge request branch from GitLab to a branch on
git.sagemath.org under the "u/galois/" namespace ("galois" is the name
of the bot). So, if this works correctly (which I've tested on
development servers) there need not be any process changes for the
release manager currently. Also, when the Trac ticket is closed the
GitLab merge request is also closed automatically.
I didn't mention this in my original message, but we have also set up
a sub-project under https://gitlab.com/sagemath/dev This is where
team members, once we start adding them, can play around more freely,
and I don't know if we have an exact plan for how it will be used yet
(Julian has thought harder about this than I have).
--
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] Enabling Merge Requests from GitLab
On 08/21/2018 10:43 AM, Erik Bray wrote: > https://gitlab.com/sagemath/sage How do I become a member of the SageMath group (or the project) in Gitlab? (username: dakrenn) Best 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.
[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
[sage-devel] Enabling Merge Requests from GitLab
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
