On Tuesday 03 February 2015 11:56:53 Martin Sandsmark wrote:
> 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, ho
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: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
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 wrote:
>
>
> On Sat, Jan 31, 2015 at 02:01:22PM +0100,
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 developer
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 cov
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
> pe
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 s
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
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: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 sol
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'
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: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 code.
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
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 whi
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
have.
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 se
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 point
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 Qt
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 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
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
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 sizabl
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 occasiona
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 develop
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/
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 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 in
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'
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
>
> wrote:
> > that KDE still couldn't agree even
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 c
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 re
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
wrote:
>
> that KDE still couldn't agree even on a set of git workflows to use, the
> wiki page still just lists a few propo
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
v
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 you
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 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 [...
... 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
tooling
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
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 majorit
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 fr
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 if
> 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
2015-01-31 19:37 GMT+00:00 Christoph Feck :
> 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
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
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 de
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 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 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 equiva
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 c
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 i
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 Ge
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 ever
On Saturday, January 31, 2015 12:56:56 Jan Kundrát wrote:
> 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 lik
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 enou
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
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 Sat, Jan 31, 2015 at 10:53 PM, Jan Kundrát 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 suitable
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 an
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
an
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 to
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 softw
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 al
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
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 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
'powerful
On Fri, Jan 30, 2015 at 10:34 AM, Thomas Lübking
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 upgrading Bugzilla for
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 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 upgradin
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 bes
-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 *t
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 s
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 server
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. T
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
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 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 overvie
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 on
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 we
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 the
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
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:
> >
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.
> Given that code review is the cor
On Wednesday 28 January 2015 11:52:17 Martin Klapetek wrote:
> Hey,
>
> On Tue, Jan 27, 2015 at 11:08 AM, 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.
> >
> > Feed
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
Hey,
On Tue, Jan 27, 2015 at 11:08 AM, 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.
>
Thanks for putting that together.
One thing I still
On Tue, Jan 27, 2015 at 11:08 PM, Jan Kundrát 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 integrate ext
89 matches
Mail list logo
