First of all, Thomas, I forgive you (and others) for nit-picking, etc. but
please
don't do it again.
And I thank you, Thomas, for two positive suggestions re fixing the Dr Konqi
reporting failure, both before 10 October and during its resurgence, in a new
guise, in November and December (see thre
On Montag, 5. Januar 2015 23:53:02 CEST, Boudewijn Rempt wrote:
I'm just trying to make clear that reviewboard is a crappy tool
inciting people to write crappy reviews that drive people away.
And I was trying to make clear that those "crappy reviews" are just the house
cleaning stuff that sho
On Monday, January 05, 2015 23:53:02 Boudewijn Rempt wrote:
> I'm just trying to make clear that reviewboard is a crappy tool inciting
> people to write crappy reviews that drive people away. Apart from any
> other nonsense about cultural differences (the standard cop-out from
> Dutchmen and German
El Dilluns, 5 de gener de 2015, a les 23:46:18, Alexander Neundorf va
escriure:
> On Monday, January 05, 2015 22:35:23 Albert Astals Cid wrote:
> > El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va
escriure:
> ...
>
> > > * figured out what branches are for, and how different pr
I'm just trying to make clear that reviewboard is a crappy tool inciting
people to write crappy reviews that drive people away. Apart from any
other nonsense about cultural differences (the standard cop-out from
Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!), I
think tha
On Monday, January 05, 2015 22:35:23 Albert Astals Cid wrote:
> El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure:
...
> > * figured out what branches are for, and how different projects handle
> > those
>
> Right, that's hardly documentable though (and will get old soon
On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote:
For me, personally, RB's mails are even worse.
Ok, but that's pretty much OT, isn't?
(Same problem with this thread, or rather mailing list. Why the
heck do I need to get two copies of every reply to a mail of
mine... One is _en
Well, this getting to a pretty useless discussion. You set out to prove
that you find it all very simple, and I am sure you find it simple.
You don't have to rebut everything I say point by point to prove whatever
you think you are proving because the point is this: you find it simple,
others
On Mon, 5 Jan 2015, Aaron J. Seigo wrote:
On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote:
In short, what I meant is that as a tool to dicuss code changes,
Reviewboard is a poor thing. It facilitates nit-picking, which is
off-putting and useless, but at least gives the reviewer the fe
On Mon, 5 Jan 2015, Thomas Lübking wrote:
I don't think this is a problem w/ RB.
When RRs get on k-c-d, many devs who can provide an abstract review are
addressed. They can take /this/ load from the actual maintainer/main
developer.
For me, personally, RB's mails are even worse. They are unr
On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote:
> In short, what I meant is that as a tool to dicuss code changes,
> Reviewboard is a poor thing. It facilitates nit-picking, which is
> off-putting and useless, but at least gives the reviewer the feeling he's
> done his job, while it fail
El Dilluns, 5 de gener de 2015, a les 22:29:36, Thomas Lübking va escriure:
> On Montag, 5. Januar 2015 21:36:54 CEST, Albert Astals Cid wrote:
> > What's the problem with php?
>
> Dynamic typing ;-)
>
> I don't think there's a particular issue with php in this context.
> To me the concern seemed
On Montag, 5. Januar 2015 22:26:24 CEST, Boudewijn Rempt wrote:
In short, what I meant is that as a tool to dicuss code
changes, Reviewboard is a poor thing. It facilitates
nit-picking, which is off-putting and useless, but at least
gives the reviewer the feeling he's done his job, while it fai
El Dilluns, 5 de gener de 2015, a les 22:26:24, Boudewijn Rempt va escriure:
> Well, _obviously_ reviewboard supports raising issues and adding comments
> , but neither facilitates actual conversation, i.e. discussion on what's
> up with a particular patch at a deeper level.
>
> In short, what I m
El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure:
> On Mon, 5 Jan 2015, Albert Astals Cid wrote:
> > I think this is due to the fact that it's quite simple
> > git clone kde:repo
>
> This requires:
>
> * setting up gitconfig with the kde: alias. That requires finding th
On Montag, 5. Januar 2015 21:36:54 CEST, Albert Astals Cid wrote:
What's the problem with php?
Dynamic typing ;-)
I don't think there's a particular issue with php in this context.
To me the concern seemed to have more been around "try to not require stuff that's
not likely around anyway"
W
Well, _obviously_ reviewboard supports raising issues and adding comments
, but neither facilitates actual conversation, i.e. discussion on what's
up with a particular patch at a deeper level.
In short, what I meant is that as a tool to dicuss code changes,
Reviewboard is a poor thing. It fa
On Mon, 5 Jan 2015, Albert Astals Cid wrote:
I think this is due to the fact that it's quite simple
git clone kde:repo
This requires:
* setting up gitconfig with the kde: alias. That requires finding the
right info on techbase, as well as the awareness that techbase exists.
* figuring out t
El Dilluns, 5 de gener de 2015, a les 17:25:48, Thomas Lübking va escriure:
> On Montag, 5. Januar 2015 16:40:52 CEST, Jan Kundrát wrote:
> > Phabricator has an equivalent of rbtools/rbt called Arcanist
> > which is written in PHP.
>
> So this is actually a concern on a particular tool.
>
> Leavi
El Dilluns, 5 de gener de 2015, a les 21:51:34, Alexander Neundorf va
escriure:
> On Monday, January 05, 2015 16:15:09 Ian Wadham wrote:
> ...
>
> > I wonder also how many people have just tiptoed quietly away from the KDE
> > Community rather than speak out about frustrations they may have been
On Monday, January 05, 2015 16:15:09 Ian Wadham wrote:
...
> I wonder also how many people have just tiptoed quietly away from the KDE
> Community rather than speak out about frustrations they may have been
> feeling. Where *did* all those people go in the last few years? And why?
I didn't reall
El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure:
> I do agree, btw, with Ian, that the current reviewboard workflow is badly
> broken and can be very discouraging. It doesn't support conversation
What do you mean it doesn't support conversation?
Cheers,
Albert
El Dilluns, 5 de gener de 2015, a les 17:57:19, Thomas Lübking va escriure:
> On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
> > Your hatred of PHP is well noted.
>
> I don't think it's hate - but it remains an undeniable fact that it's of
> little use on typical client systems. The
El Dilluns, 5 de gener de 2015, a les 16:23:15, Thomas Lübking va escriure:
> On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote:
> > Not at all. I perfectly understand what Jan is talking about.
>
> To sum up my understanding:
> - Nobody wants to install/use PHP (or, good god, .NET/Mono
Hi,
2015-01-05 19:03 GMT+01:00 Jeff Mitchell:
> On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote:
>
>> All this back-and-forth about cli tools actually sounds weird to me. I
>> know that the beginners who start hacking on Krita would never use any of
>> them. Git on the command line is often already
On 5 Jan 2015, at 12:47, Thomas Lübking wrote:
Stuff that relies on present and known libraries/executables has a
lower barrier. I've no gtk3 installation atm. and when I need to pick
among different tools, the one that doesn't require gtk3 wins.
That may be irrational, but still happens.
I'd
On Mon, 5 Jan 2015, Jeff Mitchell wrote:
I do disagree about needing a KDE identity to submit things like bug reports;
it is not useful to be unable to follow-up with someone, and if they don't
have an email address they're much less likely to remember to check back. Not
to mention link spam a
On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote:
All this back-and-forth about cli tools actually sounds weird to me. I
know that the beginners who start hacking on Krita would never use any
of them. Git on the command line is often already something they can
be rightly proud of when they maste
On 5 Jan 2015, at 12:39, Jan Kundrát wrote:
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 ow
On Montag, 5. Januar 2015 18:06:57 CEST, Jeff Mitchell wrote:
I really, really don't understand this concern. We're not in
the days of 500MB hard drives and nobody is asking anyone to
install constantly-running daemons with open ports. I don't
shiver with fear when I apt-get install a package
On 5 Jan 2015, at 12:15, Thomas Lübking wrote:
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
It's not a matter of what is possible, but of preferences (while we
probably all prefer to not return to send patches on mailing lists ;-)
Since they may obviously cover a large range,
All this back-and-forth about cli tools actually sounds weird to me. I
know that the beginners who start hacking on Krita would never use any of
them. Git on the command line is often already something they can be
rightly proud of when they master the beginnings. Heck, I myself haven't
used rbt
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 t
On 5 Jan 2015, at 12:21, Milian Wolff wrote:
On Monday 05 January 2015 12:06:57 Jeff Mitchell wrote:
On 5 Jan 2015, at 11:57, Thomas Lübking wrote:
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
Your hatred of PHP is well noted.
I don't think it's hate - but it remains an und
On Monday 05 January 2015 12:06:57 Jeff Mitchell wrote:
> On 5 Jan 2015, at 11:57, Thomas Lübking wrote:
> > On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
> >> Your hatred of PHP is well noted.
> >
> > I don't think it's hate - but it remains an undeniable fact that it's
> > of lit
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
"Sending patches around"? That's quite the stretch from
"submitting a diff to a web interface" and recalls the KDE 1.0
days. And you're accusing me of language-lawyering?
The problem here is that you believe -- incorrectly -- that
On 5 Jan 2015, at 11:57, Thomas Lübking wrote:
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
Your hatred of PHP is well noted.
I don't think it's hate - but it remains an undeniable fact that it's
of little use on typical client systems.
Therefore it's a valid concern that p
On 5 Jan 2015, at 11:06, Jan Kundrát wrote:
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
Hi developers!
The KDE Gardening Team nominates one particular annoying bug as “The
Bug of the Month”, see https://community.kde.org/Gardening
This time, kded memory leaks await investigation:
https://bugs.kde.org/show_bug.cgi?id=271934
To trace memory leaks in running processes, Milian Wolff
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121805/
---
(Updated Jan. 5, 2015, 9:57 a.m.)
Status
--
This change has been dis
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
Your hatred of PHP is well noted.
I don't think it's hate - but it remains an undeniable fact that it's of little
use on typical client systems.
Therefore it's a valid concern that people might very well be pushed off by the
requi
On 5 Jan 2015, at 10:40, Jan Kundrát wrote:
On Monday, 5 January 2015 16:23:15 CEST, Thomas Lübking wrote:
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a
client.
- Nobody remotely intends to *require* this (but one can oc. *offer*
tools written
On Montag, 5. Januar 2015 16:40:52 CEST, Jan Kundrát wrote:
Phabricator has an equivalent of rbtools/rbt called Arcanist
which is written in PHP.
So this is actually a concern on a particular tool.
Leaving aside that Phabricator seems to be owned/maintained by Facebook Inc.
(what alone may c
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121805/#review73185
---
Ship it!
Thanks for fixing this, Jeremy! :)
- Marko Käning
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 make
On Monday, 5 January 2015 16:23:15 CEST, Thomas Lübking wrote:
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a client.
- Nobody remotely intends to *require* this (but one can oc.
*offer* tools written on any whatsoever exotic requirement)
Phabri
On 5 Jan 2015, at 10:23, Thomas Lübking wrote:
On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote:
Not at all. I perfectly understand what Jan is talking about.
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a
client.
Jan doesn't wan
On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote:
Not at all. I perfectly understand what Jan is talking about.
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a client.
- Nobody remotely intends to *require* this (but one can oc. *offer
On 5 Jan 2015, at 9:41, Milian Wolff wrote:
On Monday 05 January 2015 09:14:36 Jeff Mitchell wrote:
On 5 Jan 2015, at 4:05, Jan Kundrát wrote:
Ben, you and Jeff appear to disagree with my point that e.g.
requiring
a PHP tool to be installed client-side on each developers' and
contributors' ma
On 5 Jan 2015, at 4:37, Jan Kundrát wrote:
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
On 5 Jan 2015, at 4:27, Jan Kundrát wrote:
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
On Monday 05 January 2015 09:14:36 Jeff Mitchell wrote:
> On 5 Jan 2015, at 4:05, Jan Kundrát wrote:
> > Ben, you and Jeff appear to disagree with my point that e.g. requiring
> > a PHP tool to be installed client-side on each developers' and
> > contributors' machine might be a little bit discoura
On 5 Jan 2015, at 4:05, Jan Kundrát wrote:
Ben, you and Jeff appear to disagree with my point that e.g. requiring
a PHP tool to be installed client-side on each developers' and
contributors' machine might be a little bit discouraging.
Yes, because you are repeatedly assuming that such a tool w
On 4 Jan 2015, at 20:41, Thiago Macieira wrote:
On Saturday 03 January 2015 15:35:12 Jeff Mitchell wrote:
- Not needing a CLI tool in an "obscure language" (PHP, Java,
.NET,...).
.NET is a framework, not a language. Maybe you meant C#. Regardless,
I
fail to see how any of those are "obscure
On 4 Jan 2015, at 19:07, Ben Cooksley wrote:
> At least as far as I know the only hosted service we have looked at is
> Gitorious, and that was undertaken in part by the Board.
> Others have been around longer than me and may be able to comment on
> more though.
And Gitorious was looked at over Gi
Hi,
On Mon, 05 Jan 2015 10:37:24 +0100
Jan Kundrát wrote:
> 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_ contribut
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 we
On Monday 05 January 2015 23:57:40 Ben Cooksley wrote:
> On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát wrote:
> > 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 shoul
On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát wrote:
> 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 a
On Sun, Jan 4, 2015 at 8:21 PM, Michael G. Hansen wrote:
>
> We also had a Google Summer of Code student work on the library, and the
> project was not rejected by Google.
I would actually be surprised if it was. GSoC is run by the Google Open
Source Office
and this program particularly is done
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 conc
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 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 l
Hi,
Happy New Year to all in this room.
Thanks Micheal for all details about libkgeomap history, especially
GoogleMaps rules.
Just few words about libkgeomap KF5 port :
- Library is fully ported as QT5/KF5 and sound work fine.
- Alin Marin Elen currently work on
KGeoMap::HTMLWidget class to po
On 03.01.2015 15:09, Tobias Leupold wrote:
IMHO, the real question is, shouldn't that pointless wrapper be deprecated
in favor of just using Marble directly?
Can marble be used in an identical way as libkgeomap, as a QWidget only
displaying a map with not only coordinates but also photo thumbna
65 matches
Mail list logo
