On čtvrtek 12. ledna 2017 15:28:08 CET, Kevin Kofler wrote:
What will happen now is that they will revert your commits that require the
unavailable version of the library. It is just more work for us packagers
Hi Kevin,
do you have some examples of distribution maintainers actually doing such
On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote:
That doesn't work. Such inflexibility take away the advantage
of having a CI.
What base system(s) do you prefer to target as a developer, Martin?
A CI system can have different sets of base images for different projects
(and
KDE has expanded over the last few years to include projects which are not
based on kdelibs or kf5 (or even Qt). There are e-mails about new project
incubation, upcoming conferences and CFPs and other semi-social topics. I
am interested in these discussions and I thought that this is what k-c-d
On úterý 11. října 2016 21:41:09 CEST, Thomas Eschenbacher wrote:
the _(...) macro has nothing to do with i18n
Isn't that a bit confusing? Underscore is used by gettext to mean the
*opposite* from what Kwave uses it for. It is also a reserved identifier in
C++. Inventing non-standard idioms
On Wednesday, 27 April 2016 01:21:22 CEST, Albert Astals Cid wrote:
It is strange that your Qt5-only tests are failing, may it be that they are
loading some plugin that is linked against some KF5 lib?
Qt guesses what platform one is running on in order to blend with it. In
KDE and under the
I've taken the liberty to remove the ad-hominem which you used. I'm not
happy with your approach to this discussion, but I'll try to stick with the
technical points.
There is active work within the DMARC WG, with first drafts being published
only *two months ago* [1]. My suggestion for
On Tuesday, 8 December 2015 10:19:51 CET, Ben Cooksley wrote:
a) Clearing the "subject_prefix" setting
b) Clearing "msg_header" and "msg_footer"
c) Disabling "scrub_nondigest" and "first_strip_reply_to"
Depending on who posts to your list, you may also need to:
a) Set "reply_goes_to_list" to
On Tuesday, 8 December 2015 16:09:43 CET, Nicolás Alvarez wrote:
It is irrelevant what our personal preference about doing
modifications to messages is (like the tag in the subject). The
fact of life is that there *are* mail providers out there (like
Yahoo) which are already enforcing DMARC
On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote:
To be specific I will be enabling the following line:
On-BadSignature tempfail
within the configuration of OpenDKIM on our servers.
Thanks, but that's not a full answer. What is the proposed content of the
following DNS
On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote:
Note that in the long run with DMARC looming you will need to switch
to #2 anyway, and keeping your current behaviour will likely lead to
mail from people who use Yahoo / AOL / etc ending up in the spam
folder with many mailing list
On Thursday, 3 December 2015 07:13:07 CET, Ben Cooksley wrote:
I will be re-enabling DKIM validation in one week's time - which will
then break subscriptions to Debian mailing lists (as any email from
anyone who has enabled DKIM which hits their lists will not be
accepted by KDE email
On Monday, 17 August 2015 20:04:04 CEST, Albert Astals Cid wrote:
Other comments?
Nice, happy to see it -- it builds here, with a bunch of warnings:
[2/29] Generating index.cache.bz2
index.docbook:2: element para: validity error : ID gnu-fdl already defined
element div: validity error : ID
On Wednesday, 19 August 2015 01:00:13 CEST, Christoph Feck wrote:
-- Build files have been written to: /local/build/kf5/rsibreak
/local/git/extragear/utils/rsibreak/src/rsitimer.cpp:26:20: fatal
error: kdebug.h: No such file or directory
A missing dep on kde4libssupport,
On Wednesday, 19 August 2015 00:30:01 CEST, Albert Astals Cid wrote:
These messages are not new, IMHO does not apply to this request of bringing
back from unmaintiained ;)
I agree that it's not a blocker of course, but you asked for feedback :).
However, the worst thing is that the passive
On Thursday, 6 August 2015 12:43:28 CEST, Martin Klapetek wrote:
You can still use kmix with Plasma, there is even a port to kf5 though I'm
not sure what's its state.
FYI, I've been running with the KF5 kmix for a couple of months without any
issues. I'm using just plain old ALSA, not PA.
On Sunday, 19 July 2015 23:11:05 CEST, Mark Gaiser wrote:
Regarding gerrit. How can i make patch 2 and 3 dependent on 1?
You did a good job. A correct way is to produce three commits locally, 1
being parent of 2 and 2 being a parent of 3, and push these to
refs/for/master, which is what you
Hi,
if you would like to check how well the KF5 builds cope with multiple Qt5
versions, take a look at this page generated from the Zuul/Gerrit CI
system:
http://ci-logs.kde.flaska.net/matrix.html
I am open for suggestions for service improvements, so if you have an idea
on how to make this
On Thursday, 14 May 2015 17:40:09 CEST, Scarlett Clark wrote:
I woke up this morning to a sea of red. Almost all of the linux builds are
failing. It looks like QT5 was triggered by an scm change, but
hard to tell as
it was also started and aborted by kaning.
Sune reported this to Thiago who
Hi David,
could you please clarify the release procedure, in particular what
determines whether commits pushed after the -rc1 tag are included or not?
I pushed a Qt 5.5 build fix to kitemmodels yesterday, but it apparently
didn't make it through. Not a big deal, of course, but it got me
Hi,
we're now running with Gerrit 2.11. This brings a couple of new features
and changes.
My personal favorite is the online editing via web browser. One can now fix
up small changes in patches without going to git. It's also possible to
create new changes from scratch, without touching Git
On Monday, 20 April 2015 21:14:51 CEST, Sune Vuorela wrote:
And Red Hat is following Fedora.
RHEL might not be a good example here because they are a rather a strange
beast. RHEL has actually never shipped QtWebKit (!) and they also aren't
shipping Qt5 so far.
Cheers,
Jan
--
Trojitá, a
On Monday, 20 April 2015 21:12:44 CEST, Franz Fellner wrote:
Is it really necessary to use a multiprocess web framework just
to view HTML mails?
I suppose that it is necessary to use an HTML content renderer which:
- is still supported,
- remains reasonably secure and up-to-date,
- provides
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 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 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 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 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 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 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
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, 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 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 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 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 Thursday, 29 January 2015 12:49:17 CEST, Christoph Feck wrote:
If it even allows to edit a change request from a different person
online, then I *want that*. I find it much more time consuming and
demotivating to nitpick small style/whitespace changes, than to simply
edit them out.
Yes,
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
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 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 Monday, 26 January 2015 18:11:34 CEST, Thomas Lübking wrote:
Eg. I can very well see that somebody concerned w/ i18n would
like to lookup code via cgit (or similar - no flames here,
please ;-), download a single file, fix a so far untranslated
string, diff -pru it with the original and
On Tuesday, 27 January 2015 09:51:46 CEST, Ben Cooksley wrote:
Jenkins provides rich tracking of tests, code coverage and code
quality (eg: cppcheck) in addition to checking if it builds.
Zuul is designed to determine if it builds and if tests fail -
providing a binary pass/fail response.
This
On Friday, 23 January 2015 15:21:34 CEST, Boudewijn Rempt wrote:
There is no way an artist who has a nice patch for Krita is
ever going to be able to inducted into becoming a Krita
developer if they have to follow
instructions like this:
https://techbase.kde.org/Development/Gerrit
Hi
Please read Bens article again. We do this currently and its
not working. This
is what needs to be replaced. Phabricator seems to support this, or so they
say, **and** is does what Gerrit does. So why not use that and
have everything
integrated? It's not as simple as picking a WWW git
On Wednesday, 21 January 2015 16:28:20 CEST, Thomas Lübking wrote:
- The major concern about gerrit seems about scratch repos and
I think I found a quite old bug/request on this which might
cross trivial approaches w/ scripts? [1]
Otoh, it seems Phabricator doesn't support scratch repos right
On Wednesday, 21 January 2015 15:54:52 CEST, Milian Wolff wrote:
6) The discussion focuses in highlighting Phabricator's benefits, which is
understandable from your point of view. However, much of the same things
can be said about Gerrit as well, especially its backing by a well-known
player,
On Wednesday, 21 January 2015 20:07:21 CEST, Ben Cooksley wrote:
1) A detailed list of the issues which a competing proposal would have to
address. Some glimpse of this is in the last paragraph, but that's just a
very high-level description. Could you please provide a list of
functionality that
On Wednesday, 21 January 2015 23:57:07 CEST, Ben Cooksley wrote:
Using either
http://www.guywarner.com/2014/06/part-2-integrating-phabricator-and.html
or http://www.dctrwatson.com/2013/01/jenkins-and-phabricator/ or a
variation thereof.
That is quite some custom code that one has to maintain,
On Wednesday, 21 January 2015 23:12:33 CEST, Thomas Lübking wrote:
The bug cooked up for asking google about gerrit and scratch repos.
The problem is that pushing into any branch would close a
review - I can only assume it was linked in the mail thread I
found because a similar issue would
Hi Ben,
thanks for your proposal. A couple of points which I'm missing from the
text, and a few further questions as well:
1) A detailed list of the issues which a competing proposal would have to
address. Some glimpse of this is in the last paragraph, but that's just a
very high-level
On Monday, 5 January 2015 20:57:47 CEST, Frank Reininghaus wrote:
Ultimately, a constant stream of
newcomers is the only thing that keeps a free software project alive
in the long term.
Yes, as long as these newcomers eventually get enough interest and enough
skills to become maintainers. I
On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
a) I do not know anything about Dr K, but I will try and
find someone who does.
b) Unfortunately there is nobody available any more who
knows anything about
Dr K, but I (or another suggested guy) will try to
help. How
On Monday, 5 January 2015 22:22:19 CEST, Boudewijn Rempt wrote:
Usually, half-way through they ask me, why doesn't KDE use github
I do not understand how stuff would change if we used GitHub, though. There
would still be that huge gap of not understanding which of the repos to
use. I think
On Monday, 5 January 2015 14:03:13 CEST, Thomas Friedrichsmeier wrote:
I think there is an easy test for this (well, not a real test, but a
useful initial heuristic): Can you explain exactly how to submit a
patch for your project
- to someone without prior knowledge of the tools involved
-
On Sunday, 4 January 2015 19:32:28 CEST, Jeff Mitchell wrote:
I don't follow this line of logic. The end result is software
stored in git trees, but how it gets there is a totally
different concern. Whether it comes from patches that are then
accepted and merged, or direct merging of branches,
On Sunday, 4 January 2015 13:21:12 CEST, Thomas Friedrichsmeier wrote:
True, but don't forget about the other side of the story:
- potential contributors will have to learn more stuff, before they
can even _start_ contributing, which may be a real turn-off in some
cases.
That's a valid
On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote:
Ease of installation and it's the availability of the necessary
interpreters within mainstream distributions should be more than
sufficient criteria here. Limiting it by any other criteria is playing
pure favouritism to a given set of
On Monday, 5 January 2015 12:43:06 CEST, Milian Wolff wrote:
Hm, why don't we do a prioritization poll? Quite some items
raised by others
are totally unimportant to me, and probably vice versa. While I
agree that it
would be nice to make everyone happy, I doubt that's going to
work out. If
On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote:
The problem here is that you believe -- incorrectly -- that a
single workflow cannot include more than one tool. The reason I
can definitively say that you are incorrect is because your own
preferred workflow involves more than one
On Monday, 5 January 2015 16:05:07 CEST, Jeff Mitchell wrote:
- Existing KDE account holders can and do use git for their workflow.
- Using non-git workflow for others introduces a different
workflow to the mix.
- Having two workflows is more complex than having just a single one.
Does it
On Saturday, 3 January 2015 03:31:26 CEST, Ben Cooksley wrote:
Regrettably there were one or two items which conflicted. I sided with
the option which kept the barrier to entry as low
as possible as that seemed to be the greater consensus within the thread.
Hi Ben,
thanks for compiling a list.
On Saturday, 3 January 2015 21:35:12 CEST, Jeff Mitchell wrote:
On 3 Jan 2015, at 14:00, Jan Kundrát wrote:
- Working on git trees, not patches. This directly translates
into making the contributors familiar with our workflow, and
therefore getting them immersed into what we're doing
On Saturday, 3 January 2015 08:57:43 CEST, Aaron J. Seigo wrote:
It would be nice if there was an opt-out for this. I receive a
large number of
emails from gerrit for reviews which I have been automatically
subscribed to
which I have absolutely zero interest in.
Hi Aaron,
sorry about that.
On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:
Personal clones are for forks. If you can't get a patch set accepted by
upstream, its equally unlikely that upstream are going to let you put a
private branch in their repo for sharing that patch set.
This is a social issue, then. What
On Monday, 29 December 2014 09:50:06 CEST, Ben Cooksley wrote:
Unfortunately allowing force pushes is an extremely messy business
with the hooks - so we're unable to do this (for maintenance reasons
among others).
Could you please elaborate on this one?
The only reason I remember ever hearing
On Monday, 29 December 2014 20:41:03 CEST, Jeff Mitchell wrote:
(The current scratch area itself is already entirely
custom-coded on top of Gitolite, and that means it must be
maintained.)
Can we take a look at these custom patches? I'm asking because I see this
exact feature described at
On Monday, 29 December 2014 19:44:21 CEST, Jeremy Whiting wrote:
2. The students typically change their commits quite often after review
(sometimes many times to finally get it right) and force pushing isn't
permitted, but is on clones.
I guess 2 could be solved with more commits rather than
We agreed on IRC that these patches are used for personal clones. The
support for scratch space, i.e. self-service repo creation, is implemented
by upstream Gitolite, and no custom patches for that are in production now.
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client --
On Monday, 29 December 2014 23:05:48 CEST, Jeff Mitchell wrote:
...what does that have to do with anything?
It means that there is no problem with having scratch repos (self service
repo creation) with Gitolite.
I find that relevant because you mentioned that the current scratch area
Hi, here's my possibly incomplete wishlist of how I would like to work on
SW within KDE.
- The tools should recognize that we have a limited number of people
familiar with the code, while the pool of newcomers tends to be bigger.
This means that we should teach these newcomers on how to
On Tuesday, 23 December 2014 13:21:37 CEST, Milian Wolff wrote:
Furthermore, I'd like to use the same review mechanism for
post-review. When a
patch is triggering problems, I'd like to start a discussion in
the context of
the commit that was merged. Again, I want to annotate source
lines. So
On Thursday, 25 December 2014 09:20:53 CEST, Ben Cooksley wrote:
No comments on scratch
Scratch repositories (I can do whatever here, it's simply mine) is good,
but its actual utility is limited on current setup. If it takes
minutes/half-an-hour for a new repo creation to propagate, I will
On Thursday, 25 December 2014 11:06:05 CEST, Ben Cooksley wrote:
Not sure why random / 3rd party stuff would be imported - regardless
of whether it is a scratch repository or otherwise.
Distributions tend to frown upon bundling...
I've had a need for this twice.
The first instance was trying
On Thursday, 25 December 2014 08:21:05 CEST, Ben Cooksley wrote:
In essence, yes - those are the two possible options we have.
Force pushing will *still* be prohibited under this proposal as it
stands (and would be a CoC violation if done).
Hi Ben,
this is a very strong statement. I'm believe
On Wednesday, 24 December 2014 01:57:15 CEST, Ben Cooksley wrote:
Unfortunately i'm not sure if Gitolite's ACL mechanisms let us
differentiate between tags and branches so if we allow anyone to
delete branches they'll probably be able to do the same for tags.
Are the generated config files or
On Friday, 19 December 2014 22:16:36 CEST, Scarlett Clark wrote:
Jenkins is compatible
and works with Gerrit, so I don't understand why another CI is being
considered.
Because when I started this effort this spring, build.kde.org appeared to
be on life support. I also wanted to expand the
On Thursday, 18 December 2014 14:52:12 CEST, Sebastian Kügler wrote:
Of course it would be prudent to give KDE's sysadmin's access
at some point, but it's not required per se.
Hi, that's been always the case, all sysadmins have root access, and they
also have the admin role within Gerrit.
On Monday, 15 December 2014 22:25:37 CEST, Kevin Kofler wrote:
That creates the situation that we
either all switch and have uniformity or we don't and then we end up with
reviewborad+gerrit (Albert Astals Cid), which to me sounds a lot like
blackmail (of course not by Albert, he's just the
Hi Ben,
It isn't just
the tool itself which has to be maintained: we have commit hooks,
integration with other bits of infrastructure and so forth which also
needs to both be implemented and maintained.
In case of Gerrit, there is no need for custom hooks as they stay on
git.kde.org, and
On Monday, 15 December 2014 10:46:03 CEST, Lydia Pintscher wrote:
Yeah. Wikimedia just switched to it for bug tracking. More will follow.
My understanding of the reason behind this switch is that they are PHP
programmers, so they prefer to work with software written in PHP,
Made my life as
On Monday, 15 December 2014 07:34:24 CEST, Luca Beltrame wrote:
- Apache Allura
https://allura.apache.org/
That is said to support pull requests, but I wasn't able to find an example
of that in their website. Got one?
Also, loading a list of commits took tens of second at the time I tried
On Friday, 12 December 2014 22:44:39 CEST, Albert Astals Cid wrote:
That's very different from saying whole KDE should just
switch to Gerrit, and I'm not proposing that. Some people have made
themselves clear that no change is going to happen, and I can live with
that.
Where was that
On Thursday, 11 December 2014 23:20:59 CEST, Albert Astals Cid wrote:
You need to understand understand though that changing patch
review systems is
not your decision to take (nor mine), we need to have a general
agreement/consensus when changing systems as important.
Changing systems is not
On Wednesday, 10 December 2014 10:28:59 CEST, Christian Mollekopf wrote:
* pull requests/the webinterface: reviewboard is awesome for single patches
every now and then, it's rather useless when you work with
branches IMO. With github we have a nice webinterface to review
branches while keeping
On Wednesday, 10 December 2014 19:41:31 CEST, Albert Astals Cid wrote:
D is really important to me since it makes it harder to contribute to non
hardcore git users; it took me days to start understanding Qt's
gerrit and i
am still not sure i understand it fully, with reviewboard i do git diff
On Thursday, 11 December 2014 00:51:28 CEST, Albert Astals Cid wrote:
Yes, it is harder.
Yyou need to setup git correctly, so that gerrit in that
command is valid,
you need to understand you're pushing to a different server than the real
one, you need to commit (i never do format-patch, just
On Tuesday, 2 December 2014 12:05:46 CEST, Jan Kundrát wrote:
Right now, the CI runs only for dummy.git (doing nothing) and
for trojita.git (doing three separate build test checks to
cover various combinations of ancient and new Qt4, Qt5, clang,
gcc and debug and release builds). Doing
Hi,
I managed to get a pre-merge continuous integration working with Gerrit.
This means that whenever someone uploads/updates a change to Gerrit, it
gets through a CI run and the result is reported back to Gerrit as an
advice -- see e.g. [1] for an example. A KDE developer can still override
On Tuesday, 2 December 2014 19:46:18 CEST, Albert Astals Cid wrote:
Dependencies are the hard part. Any reason you didn't piggy-back on
build.kde.org for it?
That's right.
The reason for not using Jenkins was that the existing KDE's instance was
not up to that task without significant
On Tuesday, 2 December 2014 12:05:46 CEST, Jan Kundrát wrote:
[1] https://gerrit.vesnicky.cesnet.cz/r/167
Sorry for noise, that was a very bad example. A much better one is at
https://gerrit.vesnicky.cesnet.cz/r/164 .
Because that change has been merged now, the comments are shown collapsed
On Tuesday, 28 October 2014 19:13:53 CET, Marco Martin wrote:
Gerrit question: I have a feature branch in plasma-framework
(mart/basicDeleteUndo), and i wanted to do the review process with gerrit.
Hi,
Gerrit is quite flexible, and supports many different use cases. It's up to
us to agree on
On Thursday, 16 October 2014 23:43:00 CEST, Kevin Kofler wrote:
In Gerrit, I basically get an ugly command-line interface: I
have to push to
a magic ref encoding all the information (and IIRC, git-cola only lets me
enter the basic refs/for/branchname, the special characters in stuff like
On Monday, 29 September 2014 18:39:08 CEST, Christoph Feck wrote:
Russian folks behind PVS-Studio static analyzer
(http://www.viva64.com/en/pvs-studio/) made analysis of KDE project.
Hi, can we make them run it on extragear (and especially
extragear/pim/trojita)?
Cheers,
Jan
--
Trojitá,
The language for Code-Review +2 now reads Looks good to me and I know this
code, approved. I hope people won't be afraid to approve changes now :).
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
On Monday, 15 September 2014 16:49:39 CEST, Milian Wolff wrote:
Where do I see the diff there?
Thanks to Ben and his review of my patches, Gerrit is now replicating all
of the changes under review into KDE's git as well. In the context of this
discussion, it means that there's now a link to
On Saturday, 13 September 2014 23:05:48 CEST, Eike Hein wrote:
Yeah, that's something I'm OK with too. Maybe we can even
adapt the UI to use strings like Sven proposes?
https://gerrit.vesnicky.cesnet.cz/r/35
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client --
On Monday, 15 September 2014 16:49:39 CEST, Milian Wolff wrote:
Where do I see the diff there?
For me, it's easiest to just click on any file name. That will open a diff
view (either side-by-side or a unidiff one, based on your prefs). The diff
shows just a single file, but you can use [ and
On Saturday, 13 September 2014 23:29:55 CEST, David Edmundson wrote:
I think a good example is your patch today (and pretending you're not a
maintainer). There was a single typo in a commit message. I wanted it
fixing, but I don't want to have to have to review that whole thing again
(in
1 - 100 of 128 matches
Mail list logo
