On Sat, Mar 23, 2019 at 12:42 AM Milian Wolff wrote:
>
> On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote:
> > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote:
> > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> > > > On Wed, 27 Feb 2019 12:12:55 -0700 Eik
On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote:
> On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote:
> > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> > > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote
> > >
> > >
> > > > On 2/27/19 4:38 AM, N
On woensdag 13 maart 2019 09:21:25 CET Eike Hein wrote:
> In this thread there have been some qualms on "is GitLab maybe harder on
> newbie devs", but this doesn't take into account the extremely awkward
> dance we currently do where we ask people if they have dev access or not
> and if they ne
Same. One thing I like very much about GitLab is that it puts the onus
of merging post-review on the *reviewer*.
In this thread there have been some qualms on "is GitLab maybe harder on
newbie devs", but this doesn't take into account the extremely awkward
dance we currently do where we ask
Note that you can still do rebase merge manually. Gitlab can show the
list of commands
that you need to run. In that list just replace git merge with rebase.
But I also prefer to just have a button.
Regards,
Andrius
On 2019-03-12 04:46, Eike Hein wrote:
On 3/12/19 7:46 AM, Albert Astals Cid w
On 3/12/19 7:46 AM, Albert Astals Cid wrote:
I asked for this too, i thought it had been enabled at some point, but i guess
not.
So +1
Seems it's currently being done on-demand, per-repo.
The ticket I linked has a Rails snippet for doing it for all projects,
which sysadmin may find usefu
El dilluns, 11 de març de 2019, a les 22:46:33 CET, Eike Hein va escriure:
> Hi,
>
> I have a request.
>
> In the evaluation lately, I've seen some people unhappy with the merge
> commits created when merging merge requests that can't be
> fast-forwarded, as it clutters the repo history. While
Hi,
I have a request.
In the evaluation lately, I've seen some people unhappy with the merge
commits created when merging merge requests that can't be
fast-forwarded, as it clutters the repo history. While I personally
don't mind much, I can see the point coming from the squash-and-rebase
wo
Implementation details talk seems better suited for #kde-sysadmin :-)
In any case, _automatically_ creating forks doesn't sound wise to me
with my engineering hat on, because it's unnecessary.
To create a fork, kdesrc-build would need authenticated API access. If
it has has that, it can use i
On Fri, 1 Mar 2019, 07:21 Gleb Popov <6year...@gmail.com wrote:
>
>
> On Thu, Feb 28, 2019 at 9:43 PM Ben Cooksley wrote:
>
>> On Fri, Mar 1, 2019 at 3:13 AM Nate Graham wrote:
>> >
>> > On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley <
>> bcooks...@kde.org> wrote
>> > > In terms of
On Thu, Feb 28, 2019 at 9:43 PM Ben Cooksley wrote:
> On Fri, Mar 1, 2019 at 3:13 AM Nate Graham wrote:
> >
> > On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley
> wrote
> > > In terms of server load, it would be nice if the setup of forks was
> > > still something the developer had
On Fri, Mar 1, 2019 at 3:13 AM Nate Graham wrote:
>
> On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley
> wrote
> > In terms of server load, it would be nice if the setup of forks was
> > still something the developer had to initiate rather than being done
> > automatically for every
On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley wrote
> In terms of server load, it would be nice if the setup of forks was
> still something the developer had to initiate rather than being done
> automatically for every repository touched by kdesrc-build (I say this
> mainly a
On Thu, Feb 28, 2019 at 10:23 PM Filipe Saraiva wrote:
>
> Em 24/02/2019 22:25, Filipe Saraiva escreveu:
> >
> > 4. Is there any date to officially start the migration for all projects?
> > How will it be?
> >
>
> Will the migration happen before GSoC? Is it possible to a project
> request for mig
Em 24/02/2019 22:25, Filipe Saraiva escreveu:
>
> 4. Is there any date to officially start the migration for all projects?
> How will it be?
>
Will the migration happen before GSoC? Is it possible to a project
request for migration and set Gitlab in the time for GSoC?
--
Filipe Saraiva
http://
On Thu, Feb 28, 2019 at 11:24 AM Albert Astals Cid wrote:
>
> El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure:
> >
> > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > It's really pretty nice. But Gitlab has a
> > > fork-the-repo-and-submit-a-merge-request workflow, so i
On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote:
>
> On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote
> > > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > > It's really pretty nice. But Gitlab has a
> > fork-the-re
On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote
> > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > It's really pretty nice. But Gitlab has a
> fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4,
>
Hey,
I've been part of the evaluation with KDE Connect. My experience has been
mostly good with a small exception: I personally prefer the push-to-branch
model over the fork model, but when trying it with KDE Connect pushing to a
branch created IRC commit notifications which caused a lot of noi
El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure:
>
> On 2/27/19 4:38 AM, Nate Graham wrote:
> > It's really pretty nice. But Gitlab has a
> > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4,
> > people without commit access won't just be able
On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote
> On 2/27/19 4:38 AM, Nate Graham wrote:
> > It's really pretty nice. But Gitlab has a
> > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4,
> > people without commit access won't just be able to start hac
On 2/27/19 4:38 AM, Nate Graham wrote:
It's really pretty nice. But Gitlab has a
fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people
without commit access won't just be able to start hacking with the source
checkout that kdesrc-build downloads, or else they won't
On Wed, Feb 27, 2019 at 5:18 AM Harald Sitter wrote:
>
> On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt wrote:
> >
> > On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote:
> >
> > > * Is there anything we can have that can replace tasks and workboards? We
> > > usually have some ver
On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein wrote
> How would GitLab impact the kdesrc-build experience?
So this is the current kdesrc-build experience:
1. kdesrc-build [thing]
2. cd ~/kde/src[thing]
3. arc feature my-awesome-patch
4. Start hacking
5. kdesrc-build --no-src --re
On Tue, Feb 26, 2019 at 10:37 AM Eike Hein wrote:
>
>
>
> On 2/26/19 6:26 PM, b...@valdyas.org wrote:
> > * I've seen one workboard per project, that's not ideal, otoh, the Krita
> > community early on went overboard with workboards, so we can make do
> > with that
>
> I consider this one a blocke
On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt wrote:
>
> On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote:
>
> > * Is there anything we can have that can replace tasks and workboards? We
> > usually have some very long-running tasks that get a lot of sub-tasks and
> > that basic
Hello,
On Sat, 23 Feb 2019, at 10:44, Ben Cooksley wrote:
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
Just a small FYI from the migration of the VideoLAN community.
We're moving almost everything from git/gitosis, jenkins, trac, patchwork,
mediawiki, g
On Sat, Feb 23, 2019 at 10:45 AM Ben Cooksley wrote:
>
> Hi all,
>
> [...]
>
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
Good decision. Hopefully the migration will start sooner than later.
Thank you for all your work on that.
On Tue, Feb 26, 2019 at 10:26 PM wrote:
>
> On 2019-02-26 10:13, Ben Cooksley wrote:
>
> > No decision has been made, that's what this thread is about.
> > I may have my personal views on what may be best, but that's all they
> > are - my views.
>
> I might be one of the few KDE contributors who a
On 2/26/19 6:26 PM, b...@valdyas.org wrote:
* I've seen one workboard per project, that's not ideal, otoh, the Krita
community early on went overboard with workboards, so we can make do
with that
I consider this one a blocker, and it's one of the things we've told
GitLab we really want in
On 2019-02-26 10:13, Ben Cooksley wrote:
No decision has been made, that's what this thread is about.
I may have my personal views on what may be best, but that's all they
are - my views.
I might be one of the few KDE contributors who actively likes
phabricator, but I'm all for migrating. I'v
On Tue, Feb 26, 2019 at 5:54 AM Martin Flöser wrote:
>
> Am 2019-02-24 21:03, schrieb Ben Cooksley:
> > On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser
> > wrote:
> >>
> >> Am 2019-02-23 10:44, schrieb Ben Cooksley:
> >> > Hi all,
> >>
> >> > Based on all of the above we'd like to propose migrating
On Tue, Feb 26, 2019 at 10:02 PM Eike Hein wrote:
>
>
>
> On 2/26/19 4:17 AM, Nate Graham wrote:
> > Like you, I have some reservations about Gitlab. I'm not thrilled about
> > losing approve/request changes statuses (that's in the EE edition only
> > right now).
>
> Me too. It's one of the thin
On 2/26/19 4:17 AM, Nate Graham wrote:
Like you, I have some reservations about Gitlab. I'm not thrilled about losing
approve/request changes statuses (that's in the EE edition only right now).
Me too. It's one of the things we're asking to be moved to the CE -- and
so is Gnome. GitLab kno
On Mon, 25 Feb 2019 09:54:26 -0700 Martin Flöser
wrote
> You asked for comments. I gave comment that I'm not pleased about yet
> another transition. Please keep that in mind. It means learning and
> interrupted workflows for every one. If you have already decided and
> don't
Am 2019-02-24 21:03, schrieb Ben Cooksley:
On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser
wrote:
Am 2019-02-23 10:44, schrieb Ben Cooksley:
> Hi all,
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
I'm totally honest here: I'm not happy about yet another
On Monday, 25 February 2019 09:12:47 CET Eike Hein wrote:
> On 2/25/19 4:31 AM, Martin Flöser wrote:
> > Changing the tooling will not solve any of the contribution problems.
>
> I'm aware of several projects who would like to incubate with KDE.org
> (e.g. Kaidan and Spectral, both new-breed Kirig
Personally I would expect these to be migrated. A switch that doesn't preserve
the current task tickets doesn't seem practical to me.
Cheers,
Eike
On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote:
> * Is there anything we can have that can replace tasks and workboards? We
> usually have some very long-running tasks that get a lot of sub-tasks and
> that basically document our development process. One thing I've learned with
On maandag 25 februari 2019 09:12:47 CET Eike Hein wrote:
>
> I'm aware of several projects who would like to incubate with KDE.org
> (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new
> contributor ecosystems) but are waiting for the outcome of this
> decision, because they belie
On 2/25/19 4:31 AM, Martin Flöser wrote:
Changing the tooling will not solve any of the contribution problems.
I'm aware of several projects who would like to incubate with KDE.org
(e.g. Kaidan and Spectral, both new-breed Kirigami apps with new
contributor ecosystems) but are waiting for
El dom., 24 de feb. de 2019 a la(s) 22:29, Filipe Saraiva
(fil...@kde.org) escribió:
> 1. Do KDE developers need to create accounts in Gitlab instance or a
> script will do it for us?
>
> 3. Will gitlab be a replacement to identity?
Gitlab will integrate with the current Identity system. You can
a
Em 23/02/2019 06:44, Ben Cooksley escreveu:
>
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
>
It is nice to see this happening, thanks for sysadmin team, onboarding
team and all the people involved. For the good or not so good reasons,
the repository inte
I use Gitea for my own arm64 server on SoC. In that case it makes sense as it
starts quicker and more importantly consumes less memory. So Gitea definitely
has its uses.
For KDE purposes, I think machine that hosts Gitlab will be more powerful
anyway,
and it's probably more important that there i
On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser wrote:
>
> Am 2019-02-23 10:44, schrieb Ben Cooksley:
> > Hi all,
>
> > Based on all of the above we'd like to propose migrating towards
> > Gitlab. Comments?
>
> I'm totally honest here: I'm not happy about yet another migration. This
> will be the fi
Am 2019-02-23 10:44, schrieb Ben Cooksley:
Hi all,
Based on all of the above we'd like to propose migrating towards
Gitlab. Comments?
I'm totally honest here: I'm not happy about yet another migration. This
will be the fifth reviewing toolkit I use for KDE (reviewboard for svn,
reviewboard
вс, 24 февр. 2019 г. в 00:47, Ben Cooksley :
>
> On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev
> wrote:
> >
> > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley :
> > > Based on all of the above we'd like to propose migrating towards
> > > Gitlab. Comments?
> >
> > Hi,
>
> Hi Alexander,
>
> >
> >
> Perhaps it's unjustified, but whenever someone mentions Gitea the first
thing I
notice is that *its own developers* host their project on GitHub...
> It seems odd to rely on a proprietary service instead of their own
product
that's supposed to be a direct replacement for it, and doesn't imply gr
On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev
wrote:
>
> сб, 23 февр. 2019 г. в 12:44, Ben Cooksley :
> > Based on all of the above we'd like to propose migrating towards
> > Gitlab. Comments?
>
> Hi,
Hi Alexander,
>
> 1. We migrated from github.com to self-hosted GitLab when I worked
> fu
сб, 23 февр. 2019 г. в 12:44, Ben Cooksley :
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
Hi,
1. We migrated from github.com to self-hosted GitLab when I worked
full-time in a team of 4 developers. A major drawback we noticed back
then was slow page loadi
On Saturday, 23 February 2019 21:12:08 GMT Wyatt Childers wrote:
> I'm not an active contributor. I am a developer though, who's employer uses
> gitlab... Not a huge fan. My main complaint is it tends to be slow, and I
> find the UI a little less intuitive. Recently they even broke copy and
> paste
I'm not an active contributor. I am a developer though, who's employer uses
gitlab... Not a huge fan. My main complaint is it tends to be slow, and I
find the UI a little less intuitive. Recently they even broke copy and
paste site wide on their instance -- which was very frustrating.
I recently s
On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt wrote:
>
> On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote:
>
> > "A lot" is probably a bit exaggerated, e.g. I don't really know where to
> > upload patches to Phabricator or create a pull request there, but do
> > understand how G
On Sun, Feb 24, 2019 at 7:28 AM Boudhayan Gupta wrote:
>
> Hi Ben et. al.,
>
> What are our plans regarding integrating with GitLab CI? I see that we have
> the YAML files in some of the repos already, but do we plan to replace
> Jenkins in the long run?
We've been experimenting with it, mostly
On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote:
> "A lot" is probably a bit exaggerated, e.g. I don't really know where to
> upload patches to Phabricator or create a pull request there, but do
> understand how GitLab works.
I was talking about the Krita community, which uses
On Sun, Feb 24, 2019 at 4:56 AM Boudewijn Rempt wrote:
>
> On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote:
>
> > As someone who uses gitlab on a dayjob I can tell it's pretty easy too.
> > With disregard to server interface you do `git push my-fork HEAD`,
> > right? Now, when
Hi Ben et. al.,
What are our plans regarding integrating with GitLab CI? I see that we have
the YAML files in some of the repos already, but do we plan to replace
Jenkins in the long run?
Sincerely,
Boudhayan Gupta
On Sat, 23 Feb 2019 at 11:04, Gleb Popov <6year...@gmail.com> wrote:
>
>
> On S
Hi,
On 23.02.2019 16:56, Boudewijn Rempt wrote:
On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote:
No, you misunderstand me. In the first place, we've got a lot of
people in our community who wouldn't understand a single word of that
paragraph. What they understand is
"A lo
On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote:
> As someone who uses gitlab on a dayjob I can tell it's pretty easy too.
> With disregard to server interface you do `git push my-fork HEAD`,
> right? Now, when you push to gitlab server, you get in the git output a
> link t
Concerning Latte Dock, there is no objection in migrating to Gitlab.
I like it a lot as it reminds me GitHub and it will probably welcome also
new contributors (not only developers but also enthusiast users).
regards,
michail
Στις Σάβ, 23 Φεβ 2019 στις 11:44 π.μ., ο/η Ben Cooksley
έγραψε:
> Hi
В Сб, 23 фев. 2019 в 2:08 ПП (PM), Boudewijn Rempt
написал:
On zaterdag 23 februari 2019 10:44:11 CET Ben Cooksley wrote:
https://notes.kde.org/p/gitlab-evaluation-notes
A few notes on my side:
* Krita has been using the mockup functionality extensively. We would
miss that functionalit
On zaterdag 23 februari 2019 10:44:11 CET Ben Cooksley wrote:
> https://notes.kde.org/p/gitlab-evaluation-notes
A few notes on my side:
* Krita has been using the mockup functionality extensively. We would miss that
functionality, as we actually do UX design for our new features.
* It's ages s
On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley wrote:
> Hi all,
>
> Over the past few months a small group of KDE projects have been
> evaluating Gitlab as a replacement for Phabricator, and we’ve now
> reached the point where we’re ready to have a community wide
> discussion regarding whether we’d
Hi all,
Over the past few months a small group of KDE projects have been
evaluating Gitlab as a replacement for Phabricator, and we’ve now
reached the point where we’re ready to have a community wide
discussion regarding whether we’d like to migrate to Gitlab. We'd like
to start this by thanking t
64 matches
Mail list logo
