There are indeed quite a lot of open PR on bitbucket, and writing a script
to automatically migrate them on GitLab would have taken too much effort.
There are two options:
1 - either the PR author, or anyone else, redo the PRs he/she care about on
gitlab by hand and close the bitbucket PR with a
Another (rather important) thing still using bitbucket is the
auto-generated doxygen at:
http://eigen.tuxfamily.org/dox-devel/
http://eigen.tuxfamily.org/dox/
Where is this running at the moment? Could we run this on a gitlab-CI?
(might be difficult, since it requires storing credentials to
On Thu, Dec 5, 2019 at 12:02 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:
>
> One more place we need to adapt are the changesets for the performance
> benchmark:
>
>
> https://gitlab.com/libeigen/eigen_test1/blob/master/bench/perf_monitoring/changesets.txt
done:
On Thu, Dec 5, 2019 at 4:21 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:
> Another (rather important) thing still using bitbucket is the
> auto-generated doxygen at:
>
> http://eigen.tuxfamily.org/dox-devel/
> http://eigen.tuxfamily.org/dox/
>
> Where is this running at the
On Thu, Dec 5, 2019 at 5:33 PM Joel Holdsworth
wrote:
> Hi Gael!
>
> Thanks for this. It's going to make my work so much easier.
>
> I just wanted to resubmit my int8 ostream patches, but it seems that I
> dodn't have permissions to submit a merge request. Do you need to open
> up the MRs to
That seems OK to me as well.
On Thu, Dec 5, 2019 at 9:08 AM Gael Guennebaud
wrote:
>
>
> On Thu, Dec 5, 2019 at 5:33 PM Joel Holdsworth
> wrote:
>
>> Hi Gael!
>>
>> Thanks for this. It's going to make my work so much easier.
>>
>> I just wanted to resubmit my int8 ostream patches, but it seems
Ok... manual approval sounds tedious. I would recommend figuring out a
way to automate the approval e.g. with a button on the website.
Otherwise, it's just pointless admin for you guys.
Anyway, my username is "jhol", so can you make me reporter?
Joel
On 12/5/19 5:07 PM, Gael Guennebaud
I'm not that familiar (yet) with gitlab, but it looks like you need to
have at least "Reporter" status to make PRs. And you should be able to
request access via a link near the project name (can't confirm this,
since Gael already granted me access):
I don't think that the small amount of admin work to onboard new (and old)
contributors is s problem, considering the added security. The number of
contributors (and especially casual drive-by / one-tie contributors) is
fairly small.
On Thu, Dec 5, 2019 at 9:17 AM Christoph Hertzberg <
@Christoph: What are the requests to "access" Eigen really about? If it is
just to pull a copy of the library, no special access is needed, I think.
On Thu, Dec 5, 2019 at 9:17 AM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:
> I'm not that familiar (yet) with gitlab, but it looks
I should have checked for new mails, before sending my last.
I just granted you Reporter rights (as well as to two other people who
requested access -- I did not grant Developer access, of course).
I think the manual approval of new members won't be as tedious as the
previous procedure of
No idea what the requests are about, I just see a list above the
existing members here (since you are maintainer, you should see that as
well):
https://gitlab.com/libeigen/eigen/-/project_members
Christoph
On 05/12/2019 18.22, Rasmus Munk Larsen wrote:
@Christoph: What are the requests to
Oh, I see. Deven, who works on the AMD ROCM code is requesting access as a
reporter. I approved it.
On Thu, Dec 5, 2019 at 9:30 AM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:
> No idea what the requests are about, I just see a list above the
> existing members here (since you are
I can manually fork the project to my namespace.
If I go to my fork, I can access the Merge requests tab. I tried to open
a Merge request (
Hi Martin,
I would suggest that you request Reporter status, if you want to submit an
MR.
Rasmus
On Thu, Dec 5, 2019 at 9:32 AM Martin Pecka wrote:
> I can manually fork the project to my namespace.
>
> If I go to my fork, I can access the Merge requests tab. I tried to open
> a Merge request
Ok - it's working now. Here is MR #1 !
https://gitlab.com/libeigen/eigen/merge_requests/1
Does it deserve such a momentous designation? You be the judge.
Joel
On 12/5/19 5:27 PM, Christoph Hertzberg wrote:
I should have checked for new mails, before sending my last.
I just granted you
Hahaha thanks, Joel.
On Thu, Dec 5, 2019 at 9:58 AM Joel Holdsworth
wrote:
> Ok - it's working now. Here is MR #1 !
>
> https://gitlab.com/libeigen/eigen/merge_requests/1
>
> Does it deserve such a momentous designation? You be the judge.
>
> Joel
>
> On 12/5/19 5:27 PM, Christoph Hertzberg
And if I go to the fork of jhol/eigen, I can even see a button "New
merge request" on his Merge requests tab.
Dne 05. 12. 19 v 18:27 Christoph Hertzberg napsal(a):
I should have checked for new mails, before sending my last.
I just granted you Reporter rights (as well as to two other people
That's not typical usage in GitLab.
The main reason not to is that it will destroy the information from the MR.
If you do a merge, it will include any text I write in the MR
description, the user who submitted the MR, the comitter, the MR's ID
etc. - which is all useful information for record
We used to have a linear-history policy when we started with mercurial
-- obviously mistakes where made over time (and I'm definitely not happy
with that when browsing through the history, doing bisects, etc)
At least for trivial changes all relevant information should be
contained in the
Hi,
I am developer of YADE, https://gitlab.com/yade-dev and I want to add
high precision support in our entire codebase. Unfortunately I have
been getting eigen segfaults in my tests. More about that in another email.
I want to talk a little about your gitlab migration :)
I use libeigen since
We moved YADE to gitlab about a year ago, and I found that the default
merge request merging with a rebase before (clicking the green
"rebase" button) works the best for us.
Especially important to keep all the commits fully compilable and
working. Which fortunately is possible thanks to CI. Then
Should Eigen be pre-built as a PCH? I would imagine that could speed
things up a lot.
On 12/5/19 6:36 PM, Janek Kozicki (yade) wrote:
Hi,
I am developer of YADE, https://gitlab.com/yade-dev and I want to add
high precision support in our entire codebase. Unfortunately I have
been getting
Joel Holdsworth said: (by the date of Thu, 5 Dec 2019 18:41:05 +)
> Should Eigen be pre-built as a PCH? I would imagine that could speed
> things up a lot.
I experimented with precompiled headers. It is not worth the hassle.
Especially because sometimes gcc does not recognize that
I succeeded creating MR !2 using git-remote hg.
For other people, here are the steps I needed to take on ubuntu. Suppose
I had a PR from branch my_pr_branch to target_branch on bitbucket. My
user account on both bitbucket and gitlab is peci1. These steps require
manually forking the gitlab
Maybe you've already done this, but Gitlab projects can be configured to
only allow merges if they rebase cleanly:
https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
Luke
On Thu, Dec 5, 2019 at 11:12 AM Martin Pecka wrote:
> I succeeded creating MR !2 using
Okay, that seems reasonable. I'll try git-remote-hg and we'll see. One
question though - where's Merge requests menu item? I don't see it on
eigen gitlab...
--
Martin Pecka
smime.p7s
Description: Elektronicky podpis S/MIME
Very nice work indeed!
I'll change my setup today or tomorrow so it does Nightly builds on the
new repository.
One more place we need to adapt are the changesets for the performance
benchmark:
https://gitlab.com/libeigen/eigen_test1/blob/master/bench/perf_monitoring/changesets.txt
28 matches
Mail list logo
