> Behalf Of Sergio Ahumada
>> On 17.02.2014 11:47, Giuseppe D'Angelo wrote:
> >> On 17 February 2014 10:11, Haataja Ismo wrote:
> >> one page review, are refactored for 2.7 but need few days to complete.
> >
> > Our of curiosity, are there any plans for upstreaming this particular
> > feature? The
Em seg 24 fev 2014, às 21:11:47, Knoll Lars escreveu:
> * We have one dev branch for all new development
I.e., nothing changes. I propose this branch stay named "dev", for clarity of
purpose, not "master".
> * We create one branch for each minor release. This branch can be created
> atomically f
On Mon, Feb 24, 2014 at 10:22 AM, Thiago Macieira
wrote:
> Em seg 24 fev 2014, às 19:00:28, Frederik Gladhorn escreveu:
>> > Some of those features then either caused regressions (... ok,
>> > that's what betas are for, although it may also be a symptom of poor
>> > testing in order to get the fea
Em seg 24 fev 2014, às 21:11:47, Knoll Lars escreveu:
> * Since the 5.x.y branches then only contain a very small (ideally 0) set
> of changes that have been cherry-picked from 5.x, we can safely close that
> branch after the release is out. Yes, this implies that there’s no
> fast-forward from one
Em seg 24 fev 2014, às 21:01:41, Hauke Krüger escreveu:
> Once I had fixed that problem, I started to run into the next problem
> which was related to a QFontCache behavior which seemed not to be safe
> against unload of DLLs. I did not check the reason for this in detail
> since I need to use QT a
Em seg 24 fev 2014, às 16:25:36, Lisandro Damián Nicanor Pérez Meyer escreveu:
> The situation seems to have improved, but I will probably need to switch to
> gstabs mips[el] and possibly armel, our current build machines seems to
> don't have enough RAM+SWAP. It would be cool to be able to have a
Hi,
there’s been quite a bit of discussions on both topics lately. I’ll sum up
my thinking in a separate mail, as I think they are to some extent related.
Let’s start with our release cycle. In my opinion (and having seen 15
years of doing Qt releases), our time based releasing model works better
Hi everyone,
I have posted this question into another mailing list here,
http://www.qtcentre.org/threads/58194-QT-dialogs-loaded-as-DLLs-in-QT5-seem-to-be-not-safe-against-unload-procedures?p=259492&highlight=#post259492
and was then adviced to post it in the QT development forum. Hopefully,
thi
On Monday 06 January 2014 16:08:12 Allan Sandfeld Jensen wrote:
> On Monday 06 January 2014, Oswald Buddenhagen wrote:
> > On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> > > The archs arm, i386, i686, mips and s390 can get their memory exhausted
> > > wh
On Monday 06 January 2014 16:08:12 Allan Sandfeld Jensen wrote:
> On Monday 06 January 2014, Oswald Buddenhagen wrote:
> > On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> > > The archs arm, i386, i686, mips and s390 can get their memory exhausted
> > > wh
On Monday 24 February 2014 13:17:58 Giuseppe D'Angelo wrote:
> Hello,
>
> right next to the discussion about the branching model, I'd like to
> propose a discussion about the time based releases. In particular,
> both for 5.2 and for 5.3 the model has IMO failed, in that features
> that were consi
Em seg 24 fev 2014, às 19:00:28, Frederik Gladhorn escreveu:
> > Some of those features then either caused regressions (... ok,
> > that's what betas are for, although it may also be a symptom of poor
> > testing in order to get the feature in), or are highly debatable
> > from an API / technical p
Mandag 24. februar 2014 13.17.58 skrev Giuseppe D'Angelo:
> Hello,
>
> right next to the discussion about the branching model, I'd like to
> propose a discussion about the time based releases. In particular,
> both for 5.2 and for 5.3 the model has IMO failed, in that features
> that were consider
> Unfortunately, it looks to me that time based releases seem to
> encourage developers to try to rush to get their feature in.
The theory is that developers shouldn't panic about missing a
particular release because the next release date is predictable
and developers can catch the next train if n
Hi all,
I've been trying to upgrade to Qt 5.2.1 in an embedded application on an
ARM7-based Linux device. It has been running fine with 5.2.0, but once we
upgraded to 5.2.1, "nothing" worked anymore.
The application uses c++ QObject-based classes that are exposed to Qt Quick
using setContextPrope
Hi all,
Please update all new features, modules etc to the Qt 5.3 new features page as
soon as possible
Br,
Jani
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Hello,
right next to the discussion about the branching model, I'd like to
propose a discussion about the time based releases. In particular,
both for 5.2 and for 5.3 the model has IMO failed, in that features
that were considered "too good to be missing" were rushed in at the
last second (or eve
17 matches
Mail list logo
