For those of us that like to upload code for review without having to go to
a website and click buttons, it looks like there's this CLI tool for GitLab:
https://github.com/zaquestion/lab
Unfortunately it's written in Go. But I guess that's an improvement over
PHP :)
Cheers
Simon
On Sat, 3
So IIUC Gitlab features:
- Good multi-platform *hosted* CI or at least workable integration
with other (existing) CI solutions
- Hosted review tool that we don't have to maintain ourselves (though
a little bit less good than Phabricator, allegedly)
- familiar GitHub-like workflow with no
I’ve found that GitHub encourages git commits as a project journal even
though gits originating prject has a very diff / change set oriented
workflow. And The latter is a more useful granularity of contribution for
complex prjects like ghc.
On Sun, Nov 4, 2018 at 10:27 AM Manuel M T Chakravarty
> Am 30.10.2018 um 10:07 schrieb Simon Marlow :
>
> I'm entirely happy to move, provided (1) whatever we move to provides the
> functionality we need, and (2) it's clearly what the community wants
> (considering both current and future contributors). In the past when moving
> to GitHub was
Simon Marlow writes:
> On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel
> wrote:
>
>> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>>
>> > I suppose we can do a squash-merge when committing to keep the history
>> > clean, but then contributors have a choice - either do GitHub-style
Also as part of the silent bystander group, I would definitely be okay with a
swap to GitLab. I don’t have anything particularly against Phab and Trac, but I
recognise the reduction in general friction the swap would create.
_ara
> On 3 Nov 2018, at 13:38, Richard Eisenberg wrote:
>
>
>
> On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote:
>
> As part of the silent bystander grouping, I just want to voice a weak ok for
> switching to gitlab,
+1 to this exact sentiment from me, and for the same reasons Alan voiced. I
have a horse in this race and care about the outcome,
As part of the silent bystander grouping, I just want to voice a weak ok
for switching to gitlab,
especially as a way to eventually bring the code, issues, wiki, etc into
one place.
To me the main benefit is that it is open source, allows own deployments
and is under active
development, which
On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel
wrote:
> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>
> > I suppose we can do a squash-merge when committing to keep the history
> > clean, but then contributors have a choice - either do GitHub-style
> > where you add commits to a PR
Ben Gamari writes:
> Herbert Valerio Riedel writes:
>
...
>> I wonder too how this is represented in GitLab... especially when a MR
>> is comprised of multiple commits, and those individual commits evolve,
>> might get reordered, commits added or removed fromt he stack, or when
>> the whole MR
Imants Cekusins writes:
> Are other alternatives being considered?
>
I generally focused on GitHub and GitLab as these are the two options
that are widely used in the open-source community and received the most
attention in our survey results.
> You may find these examples relevant:
>
> TFS
>
Arian van Putten writes:
> Once you rebase you simply move the branch pointer to a new chain of
> commits (they're rewritten because of the rebase, and thus have different
> hashes), however the old version of the branch still exists in the reflog.
> So locally you can definitely see your
Herbert Valerio Riedel writes:
> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>
>> What about the wiki? Can we migrate that off Trac too?
>
> I worry that it's a lot of work to migrate it away while preserving the
> special markup and features that Trac provides; so the resulting pages
>
Simon Marlow writes:
> What about the wiki? Can we migrate that off Trac too?
>
Yes, we certainly can. As Herbert mentioned, some of the fancier markup
in Trac will require a bit of manual grooming. However, the basic idea
is easily implemented with the migration that I already developed.
>
Once you rebase you simply move the branch pointer to a new chain of
commits (they're rewritten because of the rebase, and thus have different
hashes), however the old version of the branch still exists in the reflog.
So locally you can definitely see your previous versions of your 'commit
stack'
On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
> What about the wiki? Can we migrate that off Trac too?
I worry that it's a lot of work to migrate it away while preserving the
special markup and features that Trac provides; so the resulting pages
will require a significant amount of manual
Are other alternatives being considered?
You may find these examples relevant:
TFS
https://visualstudio.microsoft.com/tfs/ (Git repos is an option)
Atlassian
https://www.atlassian.com/
Atlassian offers rich set of integrated products.
What about the wiki? Can we migrate that off Trac too?
We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
links to tickets and wiki pages from elsewhere.
If we really can do a stacked-diff-style workflow using PRs on GitLab then
that at least for me removes one of the big
Carter Schonwald writes:
> For what it’s worth, I’ve never found phab / arc to be the bottle neck /
> actual time consuming piece of doing anything for ghc
>
> It’s defintely the nicest code review substrate I’ve engaged with
>
> One question I have : how does the llvm org manage / handle their
For what it’s worth, I’ve never found phab / arc to be the bottle neck /
actual time consuming piece of doing anything for ghc
It’s defintely the nicest code review substrate I’ve engaged with
One question I have : how does the llvm org manage / handle their
phabricator instance and or ci
To put my 2¢ – I will be happy with whatever service provides the most
reliable CI.
In terms of workflow, I like Ben's suggestion:
* Consider a PR to be a stack of differentials, with each commit
being an atomic change in that stack.
___
ghc-devs
Michal Terepeta writes:
> Hope you don't mind if I add an opinion of a small/occasional
> contributor to the thread.
>
> Personally, I would prefer a move to GitHub. Mostly due to familiarity
> and network effect (pretty much everyone is on GitHub).
>
> But I would also consider a move to GitLab
"Boespflug, Mathieu" writes:
> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote:
...
>
> The important things are: reducing the maintenance burden (by
> preferring hosted solutions) while still meeting developer
> requirements and supporting a workflow that is familiar to most.
>
Hope you don't mind if I add an opinion of a small/occasional
contributor to the thread.
Personally, I would prefer a move to GitHub. Mostly due to familiarity
and network effect (pretty much everyone is on GitHub).
But I would also consider a move to GitLab a big improvement over the
current
Hi Ben,
On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote:
>
> ...
>
> It occurs to me that I never did sit down to write up my thoughts on
> reviewable. I tried doing a few reviews with it [1] and indeed it is
> quite good; in many ways it is comparable to Differential. [...]
> However, it really
Simon Marlow writes:
> I'm entirely happy to move, provided (1) whatever we move to provides the
> functionality we need, and (2) it's clearly what the community wants
> (considering both current and future contributors). In the past when moving
> to GitHub was brought up, there were a handful
"Boespflug, Mathieu" writes:
> Hi Ben,
>
> On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote:
>>
>> ...
>>
>> Some of the issues I list with GitHub are entirely orthogonal to
>> GitHub's code review tool.
>>
>> While Rust has shown that large open-source projects can use GitHub,
>> they have also
Hi Ben,
On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote:
>
> ...
>
> Some of the issues I list with GitHub are entirely orthogonal to
> GitHub's code review tool.
>
> While Rust has shown that large open-source projects can use GitHub,
> they have also demonstrated that it requires a remarkable
Herbert Valerio Riedel writes:
> On 2018-10-30 at 00:54:42 -0400, Ben Gamari wrote:
>> TL;DR. For several reasons I think we should consider alternatives to
>>Phabricator. My view is that GitLab seems like the best option.
>>
>>
>> Hello everyone,
>>
>> Over the past year I have been
Manuel M T Chakravarty writes:
> Hi Ben,
>
...
>
> Given that large organisations work with large code bases on GitHub, I
> am still puzzled why GHC somehow cannot do that. (I do understand that
> the dev process that has been established within GHC is naturally
> focused around Phabricator and
Andres Löh writes:
> Hi.
>
>> Unfortunately, if I am not mistaken, GitLab also has a big problem. It
>> requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor
>> with it. (At least, that is my current understanding. Please correct me if I
>> am wrong.)
>
> Just a
Hi Ben,
Thanks a lot for the summary of the situation.
As you know, I do dislike Phabricator for the many reasons that you are
listing, and it would be nice to finally move to a better system. In
particular, it is worth emphasising the fact highlighted by the survey, namely
that "Phabricator
Gitlab has built-in CI support. This means it's well-integrated. I would
expect the CI to improve.
On Tue, Oct 30, 2018, 10:08 Simon Marlow wrote:
> I'm entirely happy to move, provided (1) whatever we move to provides the
> functionality we need, and (2) it's clearly what the community wants
>
I'm entirely happy to move, provided (1) whatever we move to provides the
functionality we need, and (2) it's clearly what the community wants
(considering both current and future contributors). In the past when moving
to GitHub was brought up, there were a handful of core contributors who
argued
On 2018-10-30 at 00:54:42 -0400, Ben Gamari wrote:
> TL;DR. For several reasons I think we should consider alternatives to
>Phabricator. My view is that GitLab seems like the best option.
>
>
> Hello everyone,
>
> Over the past year I have been growing increasingly weary of our
>
35 matches
Mail list logo
