Sergey Shambir wrote:
> I just put it here
> GNOME#Past_releases
> List_of_Ubuntu_releases#Table_of_versions
>
> Ubuntu (and other distros) maintainers should have at least one month,
> i guess.
Once we have our release process in shape, say after a successful 5.0.0
and 5.1.0, we can look at alig
Alan Alpert wrote:
> On Tue, 7 Aug 2012 18:59:28 Abecasis Joao wrote:
>> When you mention "destabilizing" changes the truth is most of the
>> time we don't know which ones those are. Here, we try to increase
>> stability by limiting the type of changes that go into each branch:
>> only regressions
Charley Bay wrote:
> Honest question, this isn't a proposal, but don't we have *TWO* issues
> being considered?
>
> (1)- "Levels-of-stability" (for the next release)
> (2)- "Evolving-APIs/Features" (for future releases)
>
> I don't want to "explode" the issue, but that seems to imply (to me)
>
Sven Anderson wrote:
> On 07.08.2012 13:09, joao.abeca...@nokia.com wrote:
>> While the two setups are very similar, almost isomorphs, they're not
>> exactly so. There are important practical consequences that
>> distinguish the two.
>>
>> - Releases happen on a fixed schedule
>> - Minor
Sven Anderson wrote:
> On 07.08.2012 01:12, Thiago Macieira wrote:
>> On terça-feira, 7 de agosto de 2012 01.00.54, Olivier Goffart wrote:
>>> ---+--+-- fire-hose
>>>/ \ / / / / / / / / \ / / / / / /
>>> --+ +-+++
On 7. aug. 2012, at 10:10, ext lars.kn...@nokia.com wrote:
> In general I like the model. As Thiago said it's pretty close to what we've
> been discussing internally before we started Qt 5 development.
>
> I agree that we should kickstart the model after the beta release. Branch
> names should
On 7. aug. 2012, at 02:45, Alan Alpert wrote:
> On Mon, 6 Aug 2012 22:13:30 ext joao.abeca...@nokia.com wrote:
>> Fire-hose is a development branch, things may be variously broken at all
>> times. Typically, developers in this mailing list will be tracking that
>> branch.
>>
>> Leaky-faucet is de
Olivier Goffart wrote:
> On Monday 06 August 2012 21:22:27 joao.abeca...@nokia.com wrote:
> [...]
>>
>> -+--+-- fire-hose
>> \ \
>> -+-+--+++-+--++ leaky-faucet
>> \\\
Thiago Macieira wrote:
> One think I'd like to know from others is: what does dripping-bucket contain
> when changes are not going in, in-between releases? From the description and
> from the graph, it sounds like that branch contains the next release before
> it is tested out. That is, it's a bran
Thiago Macieira wrote:
> Thanks for putting it together. I like it. It's what we had discussed over a
> year ago and it makes sense to me.
For context, I proposed this setup internally before. The beginning of Qt 5's
development made most of the proposal temporarily mute.
It is now a good time to
Hello Qt-ians,
While releasing Qt 5.0.0 is an ongoing process, I think this is a good
time to start planning future releases (5.0.1, 5.1.0, etc.) and, most
importantly, we need to discuss *how* we'll get them out on time.
With the setup we now have we should quickly move to a strict time-based
re
Thiago Macieira wrote:
> As you've shown, we need to duplicate everything that has QString,
> QByteArray and QVector in our API.
Not to forget QList, QVariant and potentially other classes we haven't
considered changing yet.
Besides, I'm sure we'd find places where we can't decide which one is
th
Marius Storm-Olsen wrote:
> On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote:
>> I think it would be feasible to do a binary-only break somewhere
>> around the 5.2 timeframe (say, ~12 months) where we address this.
>> Technically, this would be Qt 6, but user porting effort would be
>> reduce
Marc Mutz wrote:
> On Wednesday July 18 2012, joao.abeca...@nokia.com wrote:
>> I think it would be feasible to do a binary-only break somewhere
>> around the 5.2 timeframe (say, ~12 months) where we address this.
>> Technically, this would be Qt 6, but user porting effort would be
>> reduced to a
André Pönitz wrote:
> On Wed, Jul 18, 2012 at 07:06:55AM +, joao.abeca...@nokia.com wrote:
>> I think it would be feasible to do a binary-only break somewhere
>> around the 5.2 timeframe (say, ~12 months) where we address this.
>> Technically, this would be Qt 6, but user porting effort would b
he stack.
Cheers,
João
From: development-bounces+joao.abecasis=nokia@qt-project.org
[development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext
André Pönitz [andre.poen...@mathematik.tu-chemnitz.de]
Sent: 17 July 2012 23:59
To: development@qt-project.org
Subject: Re: [De
Hi,
As others have pointed out, a "Code of Conduct" or just some general
netiquette guidelines [1] we can point people at may be a good thing. But it
doesn't end there. We can already reply to such posts saying "This is
unacceptable behaviour in this list". Equally as important, is to otherwise
av
Thiago Macieira wrote:
> Performance considerations:
> * ref() does two 1-bit tests before the atomic increment
> * deref() does one 1-bit test before the atomic decrement
> * needsDetach() does one 2-bit test and a check for the refcount's value
I think these are the operations that can afford to
Hello again,
To every-concerned-one-of-you, I hope you do realize that we share all
of those same concerns. We do! :-)
So, let's make Qt 5 the best it can be under the constraints set out by
the previous incantations of Qt and the tone set by our Chief
Maintainer.
If you still have concerns or j
Hi all,
Earlier today I pushed some changes to Gerrit, Thiago suggested I bring
it up on the mailing list before he can approve them. Given the impact
these changes have on user code it's important that we get this merged
to master and out in the alpha as quickly as possible.
For reference the ch
like a git merge -s ours, discarding changes in the release branch. I
assume this was done for the sake of the release manager's sanity...
Cheers,
João
From: development-bounces+joao.abecasis=nokia@qt-project.org
[development-bounces+j
Ben wrote:
> The concerns are not the signals/slots. Yes, that is one aspect.
> The concern is other code that uses qreal - e.g. people embedding it
> in binary protocols, or using it in printf()'s, etc.
> The vast majority of Qt is probably in the desktop arena, and there
> qreal is a double; and
+1
I like this idea. It would allow you to both test a change before integrating
and check if preventive changes (whenever possible) already applied in upstream
modules are working as expected.
Since this would effectively offer another commonly requested feature (namely,
a dry run of the CI)
Kai Koehne wrote:
> Olivier Goffart wrote:
> > On Tuesday 24 January 2012 11:03:11 kai.koe...@nokia.com wrote:
> > > + comparing int's is fast
> > > - one central registry needed for debug areas (no go for custom
> > > apps?)
> >
> > May I suggest we use something like qHash("MyModule") And ignore
[ Re-trying after the previous massive quoting and line-wrap fail :-/ ]
Denis Dzyubenko wrote:
> 2011/12/9 João Abecasis :
> >> inline QUuid QUuid::createFromName(const QUuid &ns, const
> >> QString &name)
> >> {
> >> return createFromName(ns, name.toUtf8());
> >> }
> >
> > woul
Denis Dzyubenko wrote:> 2011/12/9 João Abecasis :> >>
inline QUuid QUuid::createFromName(const QUuid &ns, const> >> QString
&name)> >> {> >> return createFromName(ns, name.toUtf8());> >> }>
>> > would only be updated to call the right implementations, as> >
appropriate.> > I
implementation.
Finally, note that it is usually ok to add API as time goes by, but our BC
promises mean we have to maintain most of what we add for a long time.
Cheers,
João
From: development-bounces+joao.abecasis=nokia@qt-project.org
[development
27 matches
Mail list logo
