On Tuesday, 3 February 2015 12:37:30 CEST, Martin Sandsmark wrote:
So everyone with a KDE account will be able to push to any KDE project,
bypassing Gerrit?
Yes.
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
On Tue, Feb 03, 2015 at 12:02:40PM +0100, Martin Sandsmark wrote:
Yes, but as I said this doesn't really solve it at all. As I said, for long
discussions it still adds a lot of space and noise into the code, which makes
following the flow of the code extremely hard to do (at least for me
On Sat, Jan 31, 2015 at 02:01:22PM +0100, Jan Kundrát wrote:
Due to the nature of build jobs which constitute a pretty bursty
load, renting VMs sounds like a cost-effective approach for our
scale. I do not expect that it would make financial sense for us to
procure enough physical HW to cover
On Tue, Jan 27, 2015 at 11:08:49AM +0100, Jan Kundrát wrote:
Gerrit will act as a primary repository host. This will be completely
transparent to the users. Developers who do not want to change their
workflow will witness no user-visible changes. All existing clones will
work, and developers
14 messages in 90 minutes on a topic we are discussing for weeks now. Please
realise that that is why people do not engage on this mailing list. It is not
the choice of tools.
Thanks,
Mirko.
On 03 Feb 2015, at 12:23, Martin Sandsmark martin.sandsm...@kde.org wrote:
On Sat, Jan 31, 2015
On Tue, Feb 03, 2015 at 12:40:01PM +0100, Mirko Boehm wrote:
14 messages in 90 minutes on a topic we are discussing for weeks now.
Please realise that that is why people do not engage on this mailing list.
It is not the choice of tools.
Sorry for being late to the discussion, but I haven't
Hello,
First of all, thank you Boud for the wise words.
On Tuesday 03 February 2015 11:17:59 Boudewijn Rempt wrote:
On Mon, 2 Feb 2015, Milian Wolff wrote:
Sigh, I find it highly sad to read this over and over again.
Well, this whole discussion makes me extremely sad. What people have to
On Tuesday, 3 February 2015 11:36:37 CEST, Martin Sandsmark wrote:
On Fri, Jan 30, 2015 at 11:44:22PM -0200, Thiago Macieira wrote:
Many of your complaints about usability (threading, replies,
etc.) are solved
or at least partially addressed in the new Gerrit UI, which
versions like 2.7
On Thu, Jan 29, 2015 at 06:49:28PM +0100, Eike Hein wrote:
I disagree - having the comment in a floating popup instead
of breaking up source code makes it easier to read the code
for me.
I just want to back up this point.
As mentioned already, we've been using Gerrit at work for quite a while
On Sat, Jan 31, 2015 at 01:16:05PM +0100, Jan Kundrát wrote:
Your mail suggested that they apparently do not care about improving
their UI, because if they did, they would have solved everything
already. I disagree with that, and provide evidence which supports
the idea that Gerrit upstream in
On Tuesday, 3 February 2015 11:48:30 CEST, Martin Sandsmark wrote:
As mentioned already, we've been using Gerrit at work for quite a while now,
and having the code broken up by comments (sometimes many lines in case of a
discussion) makes it extremely hard to actually follow the flow of the
On Sun, Feb 01, 2015 at 10:49:58AM -0200, Thiago Macieira wrote:
They would have if they still had major problems with the usability of the
tool. It probably just so happens that all the backers are used to the
interface, however bad it might be, and don't feel the need to sponsor such a
On Tuesday, 3 February 2015 11:53:30 CEST, Martin Sandsmark wrote:
I think the point was more that what Gerrit has fixed were simple UI
glitches, not radical improvements that change the existing design to make
it easier for less experienced or casual users (or even experienced users,
but that's
On Tue, Feb 03, 2015 at 11:55:58AM +0100, Jan Kundrát wrote:
I believe that this is fixed in the new change UI:
We use 2.7, which I assume has the new UI.
- The diff viewer shows comments minimized/collapsed and in a way
which consumes less space.
Yes, but as I said this doesn't really solve
On Tue, Feb 03, 2015 at 11:46:10AM +0100, Jan Kundrát wrote:
Yes, the one we're testing in KDE is reasonably recent. It lives at
https://gerrit.vesnicky.cesnet.cz/ , and it uses the new change
screen by default.
Thanks!
And now I see that the source/line from the comments is already a link.
On Tue, Feb 03, 2015 at 11:58:50AM +0100, Jan Kundrát wrote:
As they completely revamped the change screen UI in 2.8, I do not
think that this point is true, either.
It doesn't really seem revamped, mostly just fixing all the glitches, not
really changes in the basic assumptions about how it
On Mon, 2 Feb 2015, Milian Wolff wrote:
Sigh, I find it highly sad to read this over and over again.
Well, this whole discussion makes me extremely sad. What people have to
learn is that _arguments_ only go so far. People can feel they're
double-plus extra-super right, and still at one
On Fri, Jan 30, 2015 at 11:44:22PM -0200, Thiago Macieira wrote:
Many of your complaints about usability (threading, replies, etc.) are solved
or at least partially addressed in the new Gerrit UI, which versions like 2.7
have. It might not be the default on the installation, so check the
On Monday 02 February 2015 13:17:21 Milian Wolff wrote:
On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote:
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
On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote:
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
Jan Kundrát wrote:
However, we also have people with little to no experience using Gerrit
just fine. Shall we therefore focus on explaining that contributing
through Gerrit is actually not painful?
My two cents here: as an occasional contributor (and one drop in the ocean;
take what I say
On 02/02/2015 01:20 PM, Milian Wolff wrote:
Sigh, I find it highly sad to read this over and over again. People keep
confusing the flaky CI and the high quality barrier in Qt with gerrit
itself... Seriously, gerrit the tool is OK, what makes it hard and what is the
actual barrier to entry in
On Saturday 31 January 2015 21:34:40 Eike Hein wrote:
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
On Sat, January 31, 2015 8:25 pm, Boudewijn Rempt wrote:
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
On Monday, 2 February 2015 11:22:57 CEST, David Jarvie wrote:
I occasionally contributed patches in the past to Qt, but since the
current gerrit setup was introduced I've never even contemplated doing so
because it looks too much effort to get to grips with. It's far too
off-putting for
On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote:
I have to agree. Whenever I need to do a change for Qt I need to google for
how to do it. Including putting serious thought in how the push command
must look like, how I need to adjust the examples provided and for which
ref/for/foo
On Friday 30 January 2015 10:57:33 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 an
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 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
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
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
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
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
On Thursday 29 January 2015 17:22:45 Thomas Lübking wrote:
Maybe it's possible to borrow or upstream the Qt mod?
See the repository qtqa/gerrit in the Qt infrastructure (Gitorious, Gerrit,
etc.). See commits 6f3d74b7bda9d86a16d33ed16a0806b74482d57c,
f6ec276bbd6980e4619e85abd3b3d62f7156fbfc,
On Friday 30 January 2015 10:04:01 Martin Graesslin wrote:
Also I don't think it can be improved, this looks really fundamental in
gerrit. I am not the only one who notices the problem and AFAIU Qt even
patches around the issues. Given that I'm not confident that we can improve
the
On Thursday 29 January 2015 12:25:57 Jan Kundrát wrote:
On Wednesday, 28 January 2015 13:14:14 CEST, Martin Gräßlin wrote:
Navigation through the code is difficult, you cannot see the
complete change in one, but have to go through each file. This
is something I consider as unfortunate as
On Thursday, 29 January 2015 12:25:57 CEST, Jan Kundrát wrote:
Hi Martin, thanks for an excellent idea, sorting headers before
actual code changes makes a lot of sense. I have a quick'n'dirty
patch at [1].
The patch has been merged upstream and will be released in next version
(2.11). I'll
On Tuesday 27 January 2015 11:08:49 Jan Kundrát wrote:
Hi,
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
Feedback is very welcome.
Hello Jan,
thank you very much for this exhaustive overview of
On 01/29/2015 06:16 PM, Milian Wolff wrote:
FWIW, this document reads like a fairy tale to me. The fact that so much is
already tested and deployed
One thing I'm unclear on: Does the gerrit test instance run
on machines administrated by kde.org these days?
Cheers,
Eike
On Thursday 29 January 2015 16:27:52 Luca Beltrame wrote:
Jan Kundrát wrote:
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
I'm not sure if this is the right thread for it, but as someone who
On Wednesday, 28 January 2015 13:14:14 CEST, Martin Gräßlin wrote:
Navigation through the code is difficult, you cannot see the
complete change in one, but have to go through each file. This
is something I consider as unfortunate as normally I prefer reading the
changes to the header before
Jan Kundrát wrote:
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
I'm not sure if this is the right thread for it, but as someone who commits
patches very occasionally either through CLI or the web
On Thursday, 29 January 2015 18:22:35 CEST, Eike Hein wrote:
One thing I'm unclear on: Does the gerrit test instance run
on machines administrated by kde.org these days?
The VM runs at my workplace. The KDE sysadmins have root access, PostgreSQL
backups are automatically pushed to a KDE
On 01/29/2015 06:51 PM, Jan Kundrát wrote:
The VM runs at my workplace. The KDE sysadmins have root access,
PostgreSQL backups are automatically pushed to a KDE server twice a day,
and Git is replicated to git.kde.org within seconds after each push.
Just for the record: I consider you a KDE
On 01/29/2015 06:24 PM, Milian Wolff wrote:
Much nicer, I think!
I disagree - having the comment in a floating popup instead
of breaking up source code makes it easier to read the code
for me.
Personally, I agree that the gerrit UI is terrible to use.
It's not just the diff viewer, either.
On Mittwoch, 28. Januar 2015 13:14:14 CET, Martin Gräßlin wrote:
Ah. Web UI concerns.
Yes. Share most of them.
Navigation through the code is difficult, you cannot see the
complete change in one, but have to go through each file.
+1
Ideally one could have show the patch at once (for small
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 29.01.2015 12:25, Jan Kundrát wrote:
Git has a config diff.orderfile option which might solve this
reasonably well. Do you think that the following sorting order is
reasonable for a KDE's default?
CMake* cmake* src/*.h src/*.cpp
Milian Wolff wrote:
I agree. But is that such a serious blocker that outweights all other
benefits? As I just wrote in the other mail, I think its a problem we, as
Perhaps not for frequent contributors, but for occasional ones (speaking for
for myself, I send a patch every 3-5 months, at
On 01/29/2015 08:54 PM, Luca Beltrame wrote:
This is only the perspective of an occasional contributor, so perhaps it
doesn't weigh as much.
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
On 01/29/2015 10:34 PM, Thomas Lübking wrote:
Given the multiple concerns on the gerrit webfrontend (not only in this
kcd thread) I however also assume that it should be not too hard to get
a serious improvement upstream.
That includes If we endup w/ a -hypothetical- decision between
On Donnerstag, 29. Januar 2015 21:03:32 CET, 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.
Afaiu Jan's proposal, the default gerrit webui is
On Fri, Jan 30, 2015 at 10:34 AM, Thomas Lübking
thomas.luebk...@gmail.com wrote:
On Donnerstag, 29. Januar 2015 21:03:32 CET, 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
Hi,
Jan Kundrát wrote:
Feedback is very welcome.
First of all, I would like to apologize for my overly negative tone in your
prior feedback threads.
I would also like to point out that I have absolutely no experience with
Phabricator (the solution proposed by the competing proposal), and as
On Wednesday 28 January 2015 13:14:14 Martin Gräßlin wrote:
I agree on what Martin says about some issues with the web interface of
Gerrit, esp. in regard to shortcuts. Note though that the Qt gerrit has the
ability (via custom code) to show the full patch.
snip
Given that code review is the
Hey,
On Tue, Jan 27, 2015 at 11:08 AM, Jan Kundrát j...@kde.org wrote:
Hi,
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
Feedback is very welcome.
Thanks for putting that together.
One thing
On Tue, Jan 27, 2015 at 11:08 PM, Jan Kundrát j...@kde.org wrote:
Hi,
Hi Jan,
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
Feedback is very welcome.
A few comments.
1) Most applications
On Wednesday, 28 January 2015 10:08:54 CEST, Ben Cooksley wrote:
1) Most applications integrate extremely poorly with LDAP. They
basically take the details once on first login and don't sync the
details again after that (this is what both Chiliproject and
Reviewboard do). How does Gerrit perform
On Wednesday 28 January 2015 11:52:17 Martin Klapetek wrote:
Hey,
On Tue, Jan 27, 2015 at 11:08 AM, Jan Kundrát j...@kde.org wrote:
Hi,
as promised, here is a proposal on how our infrastructure can be improved,
with emphasis on service integration. There are screenshots inside.
On Wednesday 28 January 2015 12:27:06 Jan Kundrát wrote:
On Wednesday, 28 January 2015 10:08:54 CEST, Ben Cooksley wrote:
11) We actually do use some of Jenkins advanced features, and it
offers quite a lot more than just a visual view of the last failure.
As a quick overview:
a)
On Wednesday 28 January 2015 13:14:14 Martin Gräßlin wrote:
At the moment I must say that I find gerrit's web interface extremely
cumbersome to use. This is something I experienced with both Qt's as well
as KDE's setup. Navigation through the code is difficult, you cannot see
the complete
87 matches
Mail list logo
