On Friday, 30 January 2015 03:30:55 CEST, Kevin Kofler wrote:
Unfortunately, file level strikes me as a less than helpful default. Can
this be changed to line-level merges in our instance? (I think the ideal
would be to use git's native merging algorithm(s), but I expect some
limitations due
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122330/
---
(Updated Jan. 31, 2015, 6:48 p.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/
---
Review request for kde-workspace, Bhushan Shah and David Faure.
On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]
Excuse me, but if KDE developers will have to follow
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/#review75101
---
thumbnail/thumbnail.cpp
On 01/31/2015 08:37 PM, Christoph Feck wrote:
Excuse me, but if KDE developers will have to follow equivalent steps
as described at http://qt-project.org/wiki/Setting-up-Gerrit to
contribute, then I predict another big loss of developers.
This information could be pared down considerably and
On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
hmm, looking back at our switch to git, I don't consider our standards for
documentation of the developer workflow as very high unfortunately. :-/
Considering I wrote the majority of
https://community.kde.org/Sysadmin/GitKdeOrgManual I guess
2015-01-31 19:37 GMT+00:00 Christoph Feck cf...@kde.org:
On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]
On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
hmm, looking back at our switch to git, I don't consider our standards for
documentation of the developer workflow as very high unfortunately. :-/
Considering I wrote the majority of
https://community.kde.org/Sysadmin/GitKdeOrgManual I
On Saturday, January 31, 2015 21:11:19 Eike Hein wrote:
On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
hmm, looking back at our switch to git, I don't consider our standards for
documentation of the developer workflow as very high unfortunately. :-/
Considering I wrote the majority of
On 01/31/2015 10:37 AM, Jan Kundrát wrote:
About the we could vs. we will in general, I have to admit I'm
slightly confused by that. The proposal is careful to describe what is
available today, and to make a clear difference in saying what needs to
be done in future. Maybe some part needs
On Saturday 31 January 2015 20:37:31 Christoph Feck wrote:
On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]
On Saturday, January 31, 2015 20:52:44 Eike Hein wrote:
On 01/31/2015 08:37 PM, Christoph Feck wrote:
Excuse me, but if KDE developers will have to follow equivalent steps
as described at http://qt-project.org/wiki/Setting-up-Gerrit to
contribute, then I predict another big loss of
On Sat, 31 Jan 2015, Christoph Feck wrote:
On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]
Excuse me, but
On 01/31/2015 09:25 PM, Boudewijn Rempt wrote:
In short, Qt uses gerrit is a bogus argument in favor of gerrit.
The argument isn't so much that gerrit is working well
for Qt, but more that there's a certain simplicity in
using the same tooling across the KDE/Qt stack, and
that KDE benefits
On Saturday, January 31, 2015 20:07:42 Eike Hein wrote:
On 01/31/2015 10:37 AM, Jan Kundrát wrote:
I'd like to summarize my current feelings on both proposals.
Here's what I think gerrit's strong points are:
* There's undeniably synergy and cultural alignment with
middleware
... in fact, even if you consider Qt and KDE in symbiosis,
you could say that KDE is the place you can do things that
don't fit the narrower scope of Qt Project, and that calls
for tooling that supports things gerrit doesn't support
well enough. If gerrit is a constraint, then KDE picking
On Samstag, 31. Januar 2015 20:37:31 CEST, Christoph Feck wrote:
On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway
On Samstag, 31. Januar 2015 21:11:19 CEST, Eike Hein wrote:
ReviewBoard already has some screenshot functio-
nality and we actually have policy in place to require
showing screenshots for review requests that change UI
(i.e. this is something gerrit will actually regress us
on afaics)
I don't
On Saturday, 31 January 2015 22:09:36 CEST, Thomas Lübking wrote:
Aside that this is an exhaustive HowTo on git and gerrit*,
there're apparently upload your plain diff webfrontends.
(Though I think the question was brought up and not answered
how follow-up patches are handled - eg. whether
On Saturday, 31 January 2015 21:38:23 CEST, Inge Wallin wrote:
It is one thing if there is one tool that is totally too weak to work for
experienced people and one tool that is awesome but very
difficult to learn.
But that's not the situation we have here. I think we have one
tool that is
Hi,
just a short note (don't want this to become a complete subthread
distracting from the actual proposal-discussion)
On Sat, Jan 31, 2015 at 9:38 PM, Alexander Neundorf neund...@kde.org
wrote:
that KDE still couldn't agree even on a set of git workflows to use, the
wiki page still just
On Samstag, 31. Januar 2015 22:41:36 CEST, Jan Kundrát wrote:
Maybe the newcomers just do not care whether they're learning
about Phabricator, Reviewboard or Gerrit.
Since it's always better to waste CPU time than to waste my time, we could btw.
also provide a bash script that does all the
On Thursday, 29 January 2015 19:31:20 CEST, Eike Hein wrote:
Just for the record: I consider you a KDE sysadmin (you're
administrating infra used by KDE, after all), so I meant the
kde.org more general. Thanks.
I forgot about this mail, and I realize that I am not sure whether my reply
was
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/
---
(Updated Jan. 31, 2015, 11:07 p.m.)
Review request for kde-workspace,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122320/#review75114
---
Looks ok from here.
Martin may be able to tell whether
On Saturday, January 31, 2015 22:52:22 Andreas Pakulat wrote:
Hi,
just a short note (don't want this to become a complete subthread
distracting from the actual proposal-discussion)
On Sat, Jan 31, 2015 at 9:38 PM, Alexander Neundorf neund...@kde.org
wrote:
that KDE still couldn't
On Saturday, January 31, 2015 22:41:36 Jan Kundrát wrote:
On Saturday, 31 January 2015 21:38:23 CEST, Inge Wallin wrote:
It is one thing if there is one tool that is totally too weak to work for
experienced people and one tool that is awesome but very
difficult to learn.
But that's not
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122320/
---
(Updated Jan. 31, 2015, 11:07 p.m.)
Review request for kde-workspace,
On Saturday, January 31, 2015 23:14:01 Ben Cooksley wrote:
About the only point left standing is that it doesn't check individual
subcommits, but we've yet to see whether the KDE project as a whole
sees this as necessary - especially considering that the vast majority
of projects would use CI
On Saturday, 31 January 2015 12:20:15 CEST, Inge Wallin wrote:
Given how few of our community who have participated so far, I think it
borders on pure falsehood to claim clear consensus on *anything*. I would
put more like some people want it, and I can certainly see
the appeal.
Fair enough,
On Thursday, 29 January 2015 22:57:33 CEST, Ben Cooksley wrote:
Given that upstream has had multiple attempts now at an improved
interface, I would question whether they would be willing to accept a
user interface which is suitable for our needs. It appears that they
are quite comfortable with
On Saturday, January 31, 2015 10:37:26 Jan Kundrát wrote:
On Thursday, 29 January 2015 21:03:32 CEST, Eike Hein wrote:
I think it's a real concern, and I'm wary of we can patch
it away because carrying a huge custom patch delta for UI
mods is what kept us from upgrading Bugzilla for
On Thursday, 29 January 2015 21:03:32 CEST, Eike Hein wrote:
I think it's a real concern, and I'm wary of we can patch
it away because carrying a huge custom patch delta for UI
mods is what kept us from upgrading Bugzilla for multiple
years. I think is it realistic that we can maintain this
and
On Sat, Jan 31, 2015 at 10:53 PM, Jan Kundrát j...@kde.org wrote:
On Thursday, 29 January 2015 22:57:33 CEST, Ben Cooksley wrote:
Given that upstream has had multiple attempts now at an improved
interface, I would question whether they would be willing to accept a
user interface which is
On Saturday, 31 January 2015 11:14:01 CEST, Ben Cooksley wrote:
Fixing a usability glitch and accepting a radical redesign of your
interface are completely different.
Your mail suggested that they apparently do not care about improving their
UI, because if they did, they would have solved
On Thursday, 29 January 2015 23:11:29 CEST, Eike Hein wrote:
Maybe, but this is actually something I like from the
Phabricator proposal: It provides an impression of our
relationship with Phabricator upstream, which it says
is a good and constructive one.
I believe that our relation with the
On Saturday, 31 January 2015 13:08:07 CEST, Inge Wallin wrote:
Well, all of the above and more. Hosting, electricity, networking,
I'm including all of the above as HW costs in my proposal. We (KDE) do
not have our own datacenter after all.
manual work as the number of physical machines
38 matches
Mail list logo
