Enabling Merge Requests from GitLab

[Erik Bray]

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?

[Erik Bray]

Forgot to attach screenshot.

[Daniel Krenn]

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

[Erik Bray]

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).

[William Stein]

On Tue, Aug 21, 2018 at 1:43 AM, Erik Bray <erik....@gmail.com> 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)

[Eric Gourgoulhon]

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.

[Samuel Lelievre]

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.

[Dima Pasechnik]

On Tuesday, August 21, 2018 at 1:36:52 PM UTC+3, Erik Bray wrote:

On Tue, Aug 21, 2018 at 11:21 AM Daniel Krenn <kr...@aon.at> 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 :)

I'm also interested: I'm dimpase on gitlab 

[Simon King]

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

[Dima Pasechnik]

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.

[Erik Bray]

On Tue, Aug 21, 2018 at 5:05 PM William Stein <wst...@gmail.com> wrote:
>
> On Tue, Aug 21, 2018 at 1:43 AM, Erik Bray <erik....@gmail.com> 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.

That was my impression as well, but I still wondered if anyone had any
particular experiences from that that they remembered.

In particular I'm of course interested in Volker's opinion, as release
manager. My "bot" has gone through a few iterations, and the current
version is in fact actually just a Trac plugin, so it integrates
closely with our existing Trac server and git repository. I've tried
to make it explicitly compatible with his current process and to not
get in the way of anything.

Of course, if adjustments are needed in practice, they will be easy
for me to make.

[Erik Bray]

On Tue, Aug 21, 2018 at 6:47 PM Eric Gourgoulhon <egourg...@gmail.com> 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!

[Erik Bray]

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.

[Jeroen Demeyer]

On 2018-08-21 10:43, Erik Bray wrote:
> A second clarification to make is that we are not currently proposing
> to do away with Trac for Sage's ticket database

I find this quite important. I really really really like the Sage Trac
workflow (much more than I like GitHub; I haven't used GitLab so I
cannot comment on that).

My only fear is that this semi-move to GitLab will be an excuse to
gradually make Trac less important. I don't want this to be a first step
on the slippery slope to move completely to GitLab.


Jeroen.

[Erik Bray]

I like Trac too. In particular there are two things I like about Trac
that most popular modern code hosting sites lack (though there are
probably other things I like too, but these are the two that stand
out):

1. Customizable ticket fields: Once can add any number of fields to
tickets and those fields can be different data types (usually either a
text box or select menu of some kind). Built-in examples include
component, type, etc. This is common in most commercial bug tracking
systems, but GitLab and GitHub basically just offer "labels"--just a
single enumeration of tag strings you can attach to an issue (much
like tags on a blog post, say). You can certainly emulate custom
fields by namespacing labels, and this is common. E.g. "type:
defect", "type: enhancement", etc. But this is not as good as having
dedicated fields. Many projects make up for this by having bots which
enforce a selection of labels from various categories (much like how
Volker manually sets a ticket to "needs work" if the reviewer field is
not set, a bot can mark a ticket as "needs work" if someone hasn't
applied a "type" label to an issue.

2. Customized ticket workflows. E.g.
new->assigned->needs_review->needs_work->needs_review->positive_review->fixed

Many Sage developers whose only experience with Trac may not realize
this, but that is *not* the standard default workflow for Trac. It
has been customized specifically to meet the preferred workflow of
Sage's maintainers (it could use a little more tweaking, but I think
it's mostly pretty good).

On GitHub and GitLab, most workflow enforcement is done by bots. And
you can do a *lot* with bots, and this is successful for many
projects. There are also many open source bots for this kind of
purpose that can be used by any project, or easily tweaked to fit
one's one workflow. I do prefer that workflow be more deeply built
into the system, but at least there are workarounds. Again, if you
want a good example, just look at CPython. It's pretty amazing
actually--they have 3 or 4 different bots (all Monty Python and the
Holy Grail themed) running all over the repository doing most of the
repetitive tasks up to the point where all that's left is for a human
to do code review: https://github.com/python/cpython

GitLab in the meantime has added a few nice features that I think in
part make up for the deficiencies in other areas. For example, there
is a dedicated Milestone field on issues, which I think is important
for Sage's workflow; there is also an assignee field (one that gets
used less than it should on Trac as it is). There is also a due date
(nice to have if you are aiming for a particular milestone) and fairly
recently time tracking (less important on the whole for open source
projects, but still nice if you want to know how much time you've
spent on something). Search is also much, much better. It's very
quick and easy to search for issues, and you can also search the code.

So while I share your wariness, I can go either way. Introducing
*some* GitLab into the workflow, if it takes off at all, will give
people an opportunity to make up their own minds from personal
experience, rather than FUD and speculation :)

Best,
E

[Jeroen Demeyer]

For me, the number 1 thing that our Trac server does better than GitHub
(again, I don't know about GitLab) is that the "branch" field is
mutable: an issue is just a pull request without a branch and I can
change the branch on a pull request to add a reviewer patch (sometimes
it's easier to add a patch myself instead of explaining to the author
what he should do).

And I agree that custom fields are also very useful: I always find using
GitHub labels quite messy. And things like "dependencies" simply cannot
be handled using labels.


Jeroen.

[Erik Bray]

On Wed, Aug 22, 2018 at 8:58 PM Jeroen Demeyer <J.De...@ugent.be> wrote:
>
> For me, the number 1 thing that our Trac server does better than GitHub
> (again, I don't know about GitLab) is that the "branch" field is
> mutable: an issue is just a pull request without a branch and I can
> change the branch on a pull request to add a reviewer patch (sometimes
> it's easier to add a patch myself instead of explaining to the author
> what he should do).

I agree--this is one of my biggest complaints. I'm not sure why this
isn't possible. It might have something to do with tracking comments
but even that can't be the case. On GitHub it's already perfectly
possible to force a push that completely replaces the original branch.
Any source comments that can no longer be associated with a line in
the patch are still visible on the issue's timeline, but just marked
being a comment on outdated code. So if they already do this I'm not
sure why the branch itself isn't mutable.

Interestingly, GitLab allows you to modify the *target* branch of a
merge request, but not the source branch. The opposite would seem
more useful to me.

Anyways, while I also like this aspect of Sage's Trac, it's something
I could live without. If we can express a good use case for it, we
might even be able to get such a feature into GitLab--we'd have a
better chance there than with GitHub at least.

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.

But at the same time pull requests are cheap, and there's no harm in
making them.

> And I agree that custom fields are also very useful: I always find using
> GitHub labels quite messy. And things like "dependencies" simply cannot
> be handled using labels.

GitLab has the ability to add "related issues" to an issue. I haven't
used that feature so I don't know how useful it is by comparison.\

Anyways, I would prefer to leave the rest of this discussion for
another time, and keep this focused just on enabling merge requests /
pull requests. I think that is undeniably a more accessible way for
new contributors to make their first contributions.

[Jeroen Demeyer]

On 2018-08-22 21:18, Erik Bray wrote:
> But at the same time pull requests are cheap, and there's no harm in
> making them.

The harm is that discussion is hard to follow because it's on multiple
pages. 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.

[Simon King]

Hi Erik,

On 2018-08-22, Erik Bray <erik....@gmail.com> 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

[Julian Rüth]

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:

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.

julian

[Dima Pasechnik]

it would suffice to allow the reviewer to push into the ticket's author fork, no need for a global shared git namespace/repo (the latter is causing bad performance, as it grows fast and people tend not to clean after themselves).

Perhaps it's even easier to set up correct access to forks using "teams".

julian

[Dima Pasechnik]

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.

[Daniel Krenn]

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

[Erik Bray]

On Thu, Aug 23, 2018 at 6:13 AM Julian Rüth <julian...@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.

[Erik Bray]

I think GitLab will make it a little bit easier for people to clean up
after themselves. Like on GitHub, when a merge request is merged
there is a big button to delete the source branch. We should
encourage people to push it unless they have some pressing reason not
to. I usually push it instinctively.

[Erik Bray]

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.

[Erik Bray]

On Tue, Aug 21, 2018 at 10:43 AM Erik Bray <erik....@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
>

> 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.

P.S. If anyone has additional comments, positive or negative, on
https://trac.sagemath.org/ticket/25914 they would be most appreciated
P.P.S. See PEP-581 (https://www.python.org/dev/peps/pep-0581/) for an
argument in favor of moving from CPython's legacy Roundup-based issue
tracker entirely to GitHub. With the exception of a few
Roundup-specific issues, I feel that the argument applies largely the
same for Sage/Trac.

[David Roe]

On Mon, Sep 3, 2018 at 9:54 AM Erik Bray <erik....@gmail.com> wrote:

On Tue, Aug 21, 2018 at 10:43 AM Erik Bray <erik....@gmail.com> 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

[Timo Kaufmann]

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.

[Jeroen Demeyer]

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.

[Dima Pasechnik]

make it +1. 

It must be my overt exposure to British English that makes me sound as if I fudge over the decision... ;-)

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.

P.S. If anyone has additional comments, positive or negative, on
https://trac.sagemath.org/ticket/25914 they would be most appreciated
P.P.S. See PEP-581 (https://www.python.org/dev/peps/pep-0581/) for an
argument in favor of moving from CPython's legacy Roundup-based issue
tracker entirely to GitHub.  With the exception of a few
Roundup-specific issues, I feel that the argument applies largely the
same for Sage/Trac.

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Erik Bray]

No, that's the right one. It's the ticket that motivates enabling
merge requests in the first place.

[Jeroen Demeyer]

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.

[Dima Pasechnik]

On Tue, Sep 4, 2018 at 2:33 PM Jeroen Demeyer <J.De...@ugent.be> 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.
>

[Daniel Krenn]

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

[Erik Bray]

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 <J.De...@ugent.be> 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*

[Erik Bray]

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.

[Erik Bray]

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.