Hi,
thanks for your encouragement. Trojitá, a fast IMAP e-mail client (homepage
[1], more in-depth look [2], the KDE project page [3]) has spent the last week
or so under playground and was just moved to kdereview (thanks to sysadmins for
their excellent turnaround time). I'd appreciate people
On Wednesday, 21 November 2012 20:53:14 CEST, Albert Astals Cid wrote:
I.e. if you don't use i18n() or tr() + kdecore (and actually
this one has a
missing feature because someone in Qt decided to make a method
not virtual)
you can't get our .po/.mo system work-flow to work.
Not having
It took quite a few hours, but it looks like I've tamed the beast.
I wanted to follow the way how Marble works, i.e. calling QObject::tr and
converting between the .ts and .po files. This turned out to be a problem
because QObject::tr expects the context to be a name of the class while the
On Tuesday, 4 December 2012 13:03:57 CEST, Burkhard Lück wrote:
Scripty does not like your message extraction, see
ftp://l10n.kde.org/121204.trunk_l10n-kde4.
Using a simple
$XGETTEXT_QT `find src/ -name \*.cpp` -o $podir/trojita_common.pot
will avoid the duplicated messages make Scripty
On Tuesday, 4 December 2012 14:32:20 CEST, Chusslove Illich wrote:
Other than the difference in contexts, the POT file is actually invalid (due
to duplication of messages, which must be unique by msgctxt+msgid).
My gettext skills are very sub-par, I know just what I've read in the last two
On Tuesday, 4 December 2012 13:03:57 CEST, Burkhard Lück wrote:
Scripty does not like your message extraction, see
ftp://l10n.kde.org/121204.trunk_l10n-kde4.
Hi Burkhard,
the latest log [1] looks fine to me. Could you please confirm that it is indeed
OK now?
With kind regards,
Jan
[1]
On Monday, 10 December 2012 11:16:40 CEST, Chusslove Illich wrote:
The scripts Jan had to write are a temporary fix, due to Scripty machine
having too old lconvert which produces broken POTs. Once lconvert is
updated, no third-party scripts should be necessary.
Chusslove's description is
On Thursday, 13 December 2012 18:52:51 CEST, David Faure wrote:
If it handles this correctly (so that tr() works at runtime), this is good
news then, it sounds like we can drop the weird QCoreApp::translate(,
text) in KF5.
I can confirm that lconvert from Qt 4.8.3 is enough to preserve the
On Tuesday, 18 December 2012 16:15:15 CEST, David Faure wrote:
It just means that l10n will have to run lconvert during make install, in
order to install .qm files (compiled from .ts files), rather
than .mo files, for
these frameworks which use tr() and not i18n().
In Trojita, the lconvert
On Thursday, 7 February 2013 10:26:52 CEST, Anders Lund wrote:
I'm already spending a lot of time marking reports as
duplicate/invalid or telling people that reporting bugs for KDE 4.8
or earlier is not quite as useful as they think.
Are most of these reports coming from DrKonqi? If so, have
/109551/#comment21974
Why are these commented out instead of being removed?
- Jan Kundrát
On March 17, 2013, 4:44 p.m., Martin Tobias Holmedahl Sandsmark wrote:
---
This is an automatically generated e-mail. To reply, visit:
http
that the actual
pointer itself is const, too.
That said, in this particular case I would just use a hardcoded HOME in both
getenv and setenv for simplicity, but I'm not a kdelibs developer.
- Jan Kundrát
On Oct. 7, 2013, 7:40 p.m., Jiří Pinkava wrote
On Oct. 9, 2013, 11:24 a.m., Jan Kundrát wrote:
You can even make it a `const char * const` to communicate that the actual
pointer itself is const, too.
That said, in this particular case I would just use a hardcoded HOME in
both getenv and setenv for simplicity, but I'm
and the associated memory streaming
benefits. The STL class has a lower overhead than an implicitly shared QVector
(and you do not need implicit sharing of the actual entries, do you?).
Anyway, the point is, if the number is small enough, the big-O notation does
not necessarily matter.
- Jan Kundrát
On Oct. 21, 2013, 4:26 p.m., Jan Kundrát wrote:
Have you tried a naive implementation with a
std::vectorstd::pairKey,Value? You say that a typical use case has
eight entries; that's a very small number where a well-tuned vector could
easily beat the O(1) of QHash or the O(log n
for the
QVectorField. Saves some time when loading the UDSEntry, and reduces the
memory usage further.
It isn't clear to me how a call to QVector::reserve might reduce memory usage.
- Jan Kundrát
On Oct. 24, 2013, 10:34 p.m., Frank Reininghaus wrote
On Monday, 11 November 2013 19:17:22 CEST, Albert Astals Cid wrote:
Not sure you're understanding what i say, we have an explicit check about
QDialog on stack+exec that says it will crash if you dbus quit.
We've chatted about this with Albert on IRC. My understanding of this is
that there are
On Thursday, 14 November 2013 22:02:09 CEST, Michael Reeves wrote:
That link is broken.
Try this one -- it's from valgrind, not the gdb, but it points to the
actual problem:
http://kde.6490.n7.nabble.com/QDialog-on-stack-exec-and-dbus-quit-crash-is-no-more-tp1549181p1549244.html
Cheers,
On Tuesday, 26 November 2013 00:35:18 CEST, Alexander Neundorf wrote:
Serious question: do systems, which run KDE4 and are connected to a 10
Mbps
wired network exist ?
One place I know used to use this as a crude form of traffic shaping just a
couple years ago. The offices were provisioned
On Dec. 5, 2013, 11:52 p.m., Martin Klapetek wrote:
Note that Debian-based systems actually do copy the file rather than
symlink - main reason being that if you use a symlink and your /usr is
mounted on a separate partition, anything that starts before /usr gets
mounted will not have
On Friday, 27 December 2013 13:43:50 CEST, Albert Astals Cid wrote:
kphotoalbum
Unless I'm terribly mistaken, KPhotoAlbum uses just the stars widget. The
actual rating is saved in its own DB.
We do care about the backwards compatibility, though, which means that a
released tarball needs to
Hi folks,
as requested by Ben, I would like to accounce that Trojita
(extragear/pim/trojita) is now using Gerrit [1] for patch review.
The system is open for other KDE projects as well -- if you're interested,
see [2] for further details, or come to my talk today at 14:00 in room #2
at the
On Sunday, 7 September 2014 21:27:44 CEST, Eike Hein wrote:
I'm curious however, what's the state of manifesto-compliance[1]
for the Gerrit instance? Does KDE Sysadmin have admin access and
the ability to get the data out if needed?
This is a very good question. Right now, only I (and other
Hi,
we agreed on the Frameworks BoF that the following two repos are now using
Gerrit for some initial testing:
- kio
- plasma-framework
Some rudimentary instructions are at
https://techbase.kde.org/Development/Gerrit , edits are welcome.
If you would like to become a Gerrit admin, want to
On Tuesday, 9 September 2014 17:39:54 CEST, Aaron J. Seigo wrote:
Would it not make more sense to trial it using newer / smaller / unstable
projects, as it is an experiment?
Yes, which is why trojita.git was dogfooding Gerrit before I announced
this.
As it stands with plasma-framework in
On Tuesday, 9 September 2014 20:02:55 CEST, Aaron J. Seigo wrote:
That would honestly make more sense for Plasma imho, though it still would
make sense to start small and consistent.
A suggestion made by sysadmins was to start with just a couple of repos to
prevent further confusion and to
Hi folks,
we're trying to document how to work with Gerrit within KDE at [1]. If you
can make that page better, please go ahead.
With kind regards,
Jan
[1] https://techbase.kde.org/Development/Gerrit
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
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
On Saturday, 13 September 2014 20:40:27 CEST, Kevin Krammer wrote:
As for submit, that IMHO should at least also be available to the review
request owner.
Does anyone see advantages of having submit restricted at all once the
necessary approval has been achieved?
I made a mistake when
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 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
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, 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á,
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 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
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, 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
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 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 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 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 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 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 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 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 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
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 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
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 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 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 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
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 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 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 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 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 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 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 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
1 - 100 of 128 matches
Mail list logo
