On Mittwoch 02 Februar 2011, Thiago Macieira wrote:
if I continue developing the app in master and fix some bugs
on the way, the fixes will be in master first. I would not
always want to put them into 4.6 at once because testing in
master is much easier and comes at much less cost while
please ignore this - I should have first read the rest of
the thread - others already had the same arguments
On Donnerstag 03 Februar 2011, Wolfgang Rohdewald wrote:
On Mittwoch 02 Februar 2011, Thiago Macieira wrote:
if I continue developing the app in master and fix some
bugs on the way,
On Thu, Feb 3, 2011 at 6:21 AM, Dawit A ada...@kde.org wrote:
git config --global push.default tracking
and use the -t or --track option when creating your branches (branch
or checkout -b). This way you can 'git push' (no arguments) in the
current tracked branch without accidentally pushing
Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa:
So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git
checkout -b toolbuttons), then fix, then test.
Now I want to merge to the KDE/4.6 branch; thats easy.
Then I want to merge to master (or to some local branch cloned
On Thursday 03 February 2011 13:04:18 Johannes Sixt wrote:
Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa:
So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git
checkout -b toolbuttons), then fix, then test.
Now I want to merge to the KDE/4.6 branch; thats easy.
On Thursday 03 February 2011 08:57:00 Johannes Sixt wrote:
Am 2/3/2011 6:10, schrieb Dawit A:
What happens if I tested a bug fix and wanted it to push it upstream
so that it can receive even wider testing, but it just so happens the
time to tag the next bug fix release is right around the
On Thursday 03 February 2011 19:28:44 Marco Martin wrote:
Hi all,
thi probably isn't going to be a good workflow for the future, but now that
kdelibs and base are just being converted i think would be a pretty common
problem.
basically, what i have is some repositories (one born as git,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
Review request for kdelibs and David Faure.
Summary
---
The attached
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 3, 2011, 11:23 p.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 12:07 a.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 12:11 a.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 1:29 a.m.)
Review request for kdelibs and David
Pino Toscano p...@kde.org writes:
kdecore/services/kmimetyperepository.cpp
http://git.reviewboard.kde.org/r/100539/#comment1002
I guess you should also add the /usr/local equivalent, and enclose both
in a
#ifdef Q_OS_UNIX
...
#endif
block
By the way, how welcome
On 04.02.11 00:33:58, David Faure wrote:
On Wednesday 02 February 2011, Alexander Neundorf wrote:
On Wednesday 02 February 2011, Michael Pyne wrote:
...
e.g. worrying about environment variables like PKG_CONFIG_PATH is no idle
claim (kdesrc-build sets that as well), along with PATH
On Thursday, 3 de February de 2011 22:44:56 Dawit Alemayehu wrote:
The attached patch is a workaround to the much discussed issue with VLC
hanging when opening a KDE file dialog. For the details about the causes of
this bug, see http://lists.kde.org/?t957244751r=1w=2 and the bug
report
15 matches
Mail list logo
