On Thursday 20 September 2012 19:42:32 Sune Vuorela wrote:
> On 2012-09-17, Dario Freddi wrote:
> > It really depends on what you want to achieve. If your goal is just
> > cleaning up the API and implementing the existing standard it might
> > work out, but for sure it won't just cut it for what I
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105279/#review19251
---
This review has been submitted with commit
1f94ff76581fe84d3d0
2012/9/20 Sune Vuorela :
> On 2012-09-17, Dario Freddi wrote:
>> It really depends on what you want to achieve. If your goal is just
>> cleaning up the API and implementing the existing standard it might
>> work out, but for sure it won't just cut it for what I proposed, where
>
> Why won't the ex
On 2012-09-17, Dario Freddi wrote:
> It really depends on what you want to achieve. If your goal is just
> cleaning up the API and implementing the existing standard it might
> work out, but for sure it won't just cut it for what I proposed, where
Why won't the existing (as in the fdo/galago spec
In data giovedì 20 settembre 2012 09:53:53, Daniel Kreuter ha scritto:
> is already in the KDE 4.9 branch. Maybe we can regularly merge the
> latest stable branch into the master or next version branch, f.e. once
> a week?
I think it would be a wise idea. For the record, I tried merging things
lo
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106448/
---
(Updated Sept. 20, 2012, 4:10 p.m.)
Review request for Plasma and Martin G
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106441/#review19223
---
This review has been submitted with commit
b45eada25bcd38d355a
On Thursday, September 20, 2012 11:40:41 Ralf Jung wrote:
> Hi,
>
> >> Ralf Jung wrote: Actually, the patch presented here does not break
> >> BC. This function I renamed is part of CalendarPrivate and
> >> therefore can not be used from the outside. The BC breakage would
> >> (possibly) be introd
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106504/#review19215
---
Ship it!
just fix the if() note and push away (both to 4.9 bra
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106479/#review19214
---
Ship it!
Ship It!
- Aaron J. Seigo
On Sept. 19, 2012, 11:03
Hi,
>> Ralf Jung wrote: Actually, the patch presented here does not break
>> BC. This function I renamed is part of CalendarPrivate and
>> therefore can not be used from the outside. The BC breakage would
>> (possibly) be introduced by removing Calendar::resizeEvent, which
>> is why I just stubbed
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106441/#review19212
---
This review has been submitted with commit
ba0f7a9bf36b2765418
On Tue, Sep 18, 2012 at 11:29 PM, David Faure wrote:
> On Wednesday 12 September 2012 13:22:48 Frank Reininghaus wrote:
>> 1. Before a commit, which is not a merge, is pushed to either the
>> stable branch or master, run 'git pull --rebase'. If the remote branch
>> has moved on since the last pull
> On Sept. 11, 2012, 7:39 p.m., Zack Rusin wrote:
> > That's pretty bonkers. This class was never meant to be used like that.
> > Holding an object in two threads is not going to work unless you make the
> > entire communication synchronous effectively reducing all the
> > multi-threading aspe
> On Sept. 11, 2012, 7:39 p.m., Zack Rusin wrote:
> > That's pretty bonkers. This class was never meant to be used like that.
> > Holding an object in two threads is not going to work unless you make the
> > entire communication synchronous effectively reducing all the
> > multi-threading aspe
15 matches
Mail list logo
