---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/#review1190
---
Please also add the { } around single line blocks (as per
On Friday, 4 de February de 2011 08:47:08 Johannes Sixt wrote:
I can offer a set of git bundles that contain the merge results. (I don't
have push access yet.) Anyone interested?
Send to me.
By the way, for the KDE readers here: git mergetool running kdiff3 is very
useful too. Select the
On Feb. 4, 2011, 8:02 a.m., Pino Toscano wrote:
Please also add the { } around single line blocks (as per kdelibs coding
style).
Dawit Alemayehu wrote:
Lets us forget about such nitpicks, okay... If such unnecessary coding
styles were to be enforced, there would be so many lines
On Fri, Feb 4, 2011 at 11:26 PM, Stefan Majewsky
stefan.majew...@googlemail.com wrote:
On Thu, Feb 3, 2011 at 7:28 PM, Marco Martin notm...@gmail.com wrote:
so, what should happen is, everyting in the scratch repo, should become
basically a branch of the master branch (in my first two cases
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/#review1199
---
Still the coding style issues to fix in the new code.
On Friday 04 February 2011, Thiago Macieira wrote:
Hmm... I don't get it. Isn't the database version saved in the database?
Why do we need to search the pkg-config file (which is a development
file!) to find out how to use the database?
If this is required, it sounds like shared-mime-info
On Thursday 06 January 2011, Edgar Fuß wrote:
Would it be better to have some configuration option in a phononserverrc
not to complain about vanishing sound cards?
Yes I think this would be a useful configuration option.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by
On Friday, February 4, 2011, you wrote:
On Tuesday 01 February 2011, Aaron J. Seigo wrote:
* 3rd party examples we can learn from:
http://public.kitware.com/Wiki/Git/Workflow/Topic
Qt?
http://wiki.videolan.org/Git
thanks; added to
Is QIODevice the best idea to use as source?
Since we are talking KIO, I believe we can espect the user of KIO::http_post
to be using KIO and not Qt IO. So would it instead be possible to make the
source a KIO job or KUrl?
Regards
`Allan
On Wednesday 02 February 2011, Dawit Alemayehu wrote:
On 04.02.11 08:47:08, Johannes Sixt wrote:
Am 2/3/2011 13:04, schrieb Johannes Sixt:
Before anybody begins to work in this way, someone with sufficient
knowlege must introduce the first real merge of the 4.6 branch into the
master branch. The conflicts must be resolved; or it is possible to
On Fri, Feb 04, 2011 at 08:47:08AM +0100, Johannes Sixt wrote:
(e) There is no (e).
as far as i'm concerned, there isn't even an (a).
i said about a year ago and repeated it later that *if* we wanted a
forward-merge based process, we would have to do the git migration
*before* branching off the
Ahh... I think you misunderstood the purpose of the patch or rather
the title of this review. The new APIs simply overload the existing
http post APIs such that the data you are going to post is sent
through a QIODevice (QFile or QBuffer) rather than a QByteArray. To be
clear here is the new
On Feb. 4, 2011, 10:54 a.m., Pino Toscano wrote:
Still the coding style issues to fix in the new code.
Sorry, but I do not see that as an issue...
On Feb. 4, 2011, 10:54 a.m., Pino Toscano wrote:
kdecore/services/kmimetyperepository.cpp, lines 688-689
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 3:52 p.m.)
Review request for kdelibs and David
On Feb. 4, 2011, 8:02 a.m., Pino Toscano wrote:
Please also add the { } around single line blocks (as per kdelibs coding
style).
Dawit Alemayehu wrote:
Lets us forget about such nitpicks, okay... If such unnecessary coding
styles were to be enforced, there would be so many lines
On Friday 04 February 2011, Allan Sandfeld Jensen wrote:
Is QIODevice the best idea to use as source?
I believe we can espect the user of KIO::http_post
to be using KIO and not Qt IO
I like QIODevice actually, for reading stuff on demand.
I use it everywhere in KArchive (KZip, KTar...) and
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces for single
line statements and another says the complete
On Friday 04 February 2011 17:05:07 Tom Albers wrote:
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces
On 4 February 2011 17:05, Tom Albers t...@kde.org wrote:
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces for
Em sexta-feira, 4 de fevereiro de 2011, às 05:24:26, Dawit A escreveu:
In the meantime, I've been discussing with Rémi about the issue and he's
not budging from his position that libraries shoul
never use Unix signals. To be
honest, he's right: Unix signals are meant to be used centrally
Em sexta-feira, 4 de fevereiro de 2011, às 16:52:54, Allan Sandfeld Jensen
escreveu:
Or to put another way; PUT takes a KUrl to send to and gets the data it
sends from a slot. POST is essentially just a PUT with return data, so I
would find it most natural if POST mirrored PUT in how it sends
Em sexta-feira, 4 de fevereiro de 2011, às 15:27:49, Oswald Buddenhagen
escreveu:
and i'm strongly opposed to merging any previous branches back to master
with -s ours, as this will effectively rewrite history (we did *not*
merge back, and claiming that now will possibly hide actual omissions).
On Fri, Feb 04, 2011 at 05:41:16PM +0100, Thiago Macieira wrote:
This makes each process started spawn a new thread, which
will block on waitpid(2).
i have the vague notion that blocking/ignoring sigchld will prevent
wait*() from working on some systems. dunno where i got that from.
I'm
Em sexta-feira, 4 de fevereiro de 2011, às 18:05:09, Oswald Buddenhagen
escreveu:
On Fri, Feb 04, 2011 at 05:41:16PM +0100, Thiago Macieira wrote:
This makes each process started spawn a new thread, which
will block on waitpid(2).
i have the vague notion that blocking/ignoring sigchld will
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 6:22 p.m.)
Review request for kdelibs and David
Can somone please clarify the proper rule to follow for committing bug
fixes as it relates to the KDE 4.6 branch ? The conclusion from the
discussion here is rather confusing as to what should be done going
forward. Should we still commit new bug fixes to the 4.6 branch first
and merge into master
On Tue, Feb 1, 2011 at 06:29, Johannes Sixt wrote:
Am 2/1/2011 10:31, schrieb David Jarvie:
On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote:
On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote:
I guess that won't quite work when there are commits specific to 4.6 in
the
4.6
Thiago Macieira wrote:
On Friday, 4 de February de 2011 15:18:58 Nicolas Alvarez wrote:
Johannes Sixt wrote:
(1) All back- and forward-porting was complete when SVN went
read-only.
IMHO this is not a safe assumption. As I said before, I found a missing
forward-port in kdeplasma-addons,
On Friday, 4 de February de 2011 17:13:31 Nicolas Alvarez wrote:
Whoever forgot to do forward-ports should be doing it *yesterday*.
I know forward-ports should be done anyway and asap. But until they aren't
done, we can't do the 4.6 merge.
Sure we can. It doesn't influence in anyway.
--
On Friday, 4 de February de 2011 19:38:51 Oswald Buddenhagen wrote:
On Fri, Feb 04, 2011 at 06:28:10PM +0100, Thiago Macieira wrote:
Em sexta-feira, 4 de fevereiro de 2011, às 18:17:13, Thiago Macieira
escreveu:
I thought about that. My work on no-thread-until-pipes-close had
already
On Friday, 4 de February de 2011 14:06:58 Dawit A wrote:
BTW, there is one side issue I noticed in QProcess through this whole
process. Why does QProcess not exit immediately if I invoke kill or
terminate or even when it just timed out from waiting for the child
process ? IOW, why wait some
On Friday, 4 de February de 2011 14:58:52 Parker Coates wrote:
Another special and unavoidable case of this will be applications
bumping their stable version numbers. It seems weird to have a
Updated version to 4.6.2 commit in a 4.7 master, for example, but I
guess that the (small) price one
On Friday, 4 de February de 2011 16:35:32 Dawit A wrote:
Let us take out terminate from the equation. It is my mistake I
included it here because its documentation states that The process
may not exit as a result of calling this function. However, I really
do not understand why what you stated
On Fri, Feb 4, 2011 at 5:00 PM, Thiago Macieira thi...@kde.org wrote:
On Friday, 4 de February de 2011 16:35:32 Dawit A wrote:
Let us take out terminate from the equation. It is my mistake I
included it here because its documentation states that The process
may not exit as a result of calling
On Friday, 4 de February de 2011 19:28:06 Nicolás Alvarez wrote:
On 04/02/2011, Thiago Macieira thi...@kde.org wrote:
Ok, fair enough. Threading-after-pipes-closed is not an option then.
That leaves back again at square one:
- one thread per subprocess
OR
- SIGCHLD handler
On Friday, 4 de February de 2011 17:35:00 Dawit A wrote:
Ok, that sounds like unexpected behaviour. Has this been filed as a bug?
Not yet. I simply mentioned it here because you seem to be addressing
the issue that exposed this behavior, but I guess I can open a ticket
against Qt for this.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100572/
---
Review request for kdelibs.
Summary
---
This request is created
On Fri, Feb 04, 2011 at 04:35:32PM -0500, Dawit Alemayehu wrote:
The case of the kill is even more baffling to me because its
documentation clearly says Kills the current process, causing it to
exit immediately. So If I kill is invoked as such
process.kill();
what should a reasonable
On Friday, February 04, 2011 19:16:03 Tom Albers wrote:
- Original Message -
this will get us used to the merge workflow which starts with fix it
in the
stable branch first.
So, in conclusion, we did not pick a tool which fits our workflow, instead
we are now adjusting our
39 matches
Mail list logo
