[sage-devel] Workflows on GitLab
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 -- 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] Enabling Merge Requests from GitLab
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. -- 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 Wed, Aug 22, 2018 at 8:58 PM Jeroen Demeyer 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. -- 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
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. -- 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 Wed, Aug 22, 2018 at 5:38 PM Jeroen Demeyer wrote: > > 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. 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 -- 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 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. -- 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.
Re: [sage-devel] Enabling Merge Requests from GitLab
On Tue, Aug 21, 2018 at 5:05 PM William Stein wrote: > > 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. 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. > > 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.
[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.
Re: [sage-devel] Enabling Merge Requests from GitLab
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 >
> 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
>
> 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.
[sage-devel] Re: moving tickets forward
It looks that Magma-related failure is caused by changes in Magma; it could be a different Magma version will still be OK. I don't think it should stop #25351 from moving forward. Someone with Magma ought to open a ticket to fix this, if necessary. On Wednesday, August 22, 2018 at 12:04:56 AM UTC+3, Brent W. Baccala wrote: > > 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.
