Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira :
>
> On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> > Should we instead just encourage people to make returnsQtContainer()
> > return a const container ?
>
> We should not, since the prevents move-construction from happening.
On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira
wrote:
> The answer to all of those questions needs to be "yes". Anything short of
> that
> means the CoC is powerless and just for show.
>
Which was my point exactly.
> Whether there's a termination of employment or not is out of scope, since
On Saturday, 27 October 2018 13:07:40 PDT Lars Knoll wrote:
> No need. He’s right. A move constructor only works with a non const value,
> as it needs to modify the object. One thing to check however for our
> containers is how much more expensive the copy is (compared to the move).
Two atomic
On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?
We should not, since the prevents move-construction from happening. You'll pay
the cost of two reference counts (one up and one
On Saturday, 27 October 2018 12:04:12 PDT Konstantin Shegunov wrote:
> Say we adopt the CC (basically the proposed text) and imagine that the
> abusive party is an employee of the QtC and has committed heinous acts
> against a community member. As far as I can tell this is very unlikely, but
>
On 27 Oct 2018, at 21:07, Elvis Stansvik
mailto:elvst...@gmail.com>> wrote:
Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll
mailto:lars.kn...@qt.io>>:
On 27 Oct 2018, at 19:29, André Pönitz
mailto:apoen...@t-online.de>> wrote:
On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins
Den lör 27 okt. 2018 kl 21:07 skrev Elvis Stansvik :
>
> Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
> >
> >
> >
> > On 27 Oct 2018, at 19:29, André Pönitz wrote:
> >
> > On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
> >
> > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik
Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
>
>
>
> On 27 Oct 2018, at 19:29, André Pönitz wrote:
>
> On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
>
>
> Hi all (first post),
>
>
> Welcome :)
>
> In Qt 5.7+ there's
On Sat, Oct 27, 2018 at 4:56 PM Martin Smith wrote:
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
Oh, it is going to end in A resolution, it may not end the way the offended
party may feel just, but that's
On Sat, Oct 27, 2018 at 05:34:30PM +, Martin Smith wrote:
> >Actions that are considered offenses by a society are typically mentioned
> >in its laws. If something is not forbidden by law it usually means that
> >there is no majority, let alone consensus in that society that this action
> >is
On 27 Oct 2018, at 19:29, André Pönitz
mailto:apoen...@t-online.de>> wrote:
On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik
mailto:elvst...@gmail.com>> wrote:
Hi all (first post),
Welcome :)
In Qt 5.7+ there's qAsConst, an
>Actions that are considered offenses by a society are typically mentioned
>in its laws. If something is not forbidden by law it usually means that
>there is no majority, let alone consensus in that society that this action
>is an offense.
Exactly. Without a CoC, we have no laws, so the
On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
> >
> > Hi all (first post),
>
> Welcome :)
>
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for
On Sat, Oct 27, 2018 at 01:09:45PM +, Martin Smith wrote:
> >Well, then let me give you my simple minded opinion on this topic, an
> >engineers
> >opinion:
> >Do not introduce a CoC.
>
> In that case, if a contributor is mistreated by another contributor,
> what recourse does the victim
Want to add that CoC implementation matters.
It's hard to accept and change or revert some rules than.
The controversial discrimination protection sentences at least should be
carefully discussed. It's not some thing that we could accept as easy as
rewrite.
сб, 27 окт. 2018 г., 18:51 Martin
Having observed this discussion since the beginning...
Apparently there are cases where contributors are being abused by other
contributors. Currently, there is no formal procedure for resolving these cases
of alleged abuse.
Those objecting to establishing a CoC the purpose of which will be to
Den lör 27 okt. 2018 kl 17:33 skrev Sérgio Martins :
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
> >
> > Hi all (first post),
>
> Welcome :)
>
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating
On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
>
> Hi all (first post),
Welcome :)
> In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> who are not on C++17 yet, which is convenient for iterating over Qt
> containers using range-based for loops without causing a
> Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
> > Jokes aside, I think we still should let users use Q_FOREACH for implicitly
> > shared containers.
But what's the percentage of Qt developers that understand the
subtleties between Q_FOREACH and range-for ?
Having a toolbox with two
I agree not interacting is probably not a solution and your contribution
without other details is not an excuse.
But I think existing CoC have problems.
There are statements everywhere about discrimination protection for example
which are very controversial.
The problem with that in other
>I am yet to hear an answer about what is going to be done in case the person
>mistreating is an active contributor.
>Will you chose potential harm, over actual benefit of having such a person on
>the
>project?
Active contributors who abuse others should be treated the same as inactive
I am yet to hear an answer about what is going to be done in case the
person mistreating is an active contributor.
Will you chose potential harm, over actual benefit of having such a person
on the project?
The edge case being, for example, if a module maintainer is mistreating
someone for
>1) To contact the contributor first and try to resolve the issue civilly.
>2) To seek help with a third party (another contributor) who is known to the
>alleged victim and who can act as mediator to try an resolve it.
>3) If 1) and 2) don't work he/she may also bring it to the attention of the
On Sat, Oct 27, 2018 at 4:09 PM Martin Smith wrote:
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor)
Den lör 27 okt. 2018 kl 15:06 skrev Kevin Kofler :
>
> Elvis Stansvik wrote:
> > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
> >> Jokes aside, I think we still should let users use Q_FOREACH for
> >> implicitly shared containers.
> >
> > Yes, I thought that Q_FOREACH was slated for
>Note that installing a conflict resolution authority doesn't need installing a
>controversial CoC and formalizing every thing a contributor can or cannot do..
But it does require specifying how to lodge a complaint, which specifies
conduct, and it then ought to say something about the kinds of
Note that installing a conflict resolution authority doesn't need
installing a controversial CoC and formalizing every thing a contributor
can or cannot do..
True, there won't be formalized and standadized rules for resolution, but
aren't people in this project sensible enough, in general, to have
>Well, then let me give you my simple minded opinion on this topic, an engineers
>opinion:
>Do not introduce a CoC.
In that case, if a contributor is mistreated by another contributor, what
recourse does the victim have?
martin
From: Development on
Elvis Stansvik wrote:
> Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
>> Jokes aside, I think we still should let users use Q_FOREACH for
>> implicitly shared containers.
>
> Yes, I thought that Q_FOREACH was slated for deprecation though. But
> maybe that's not set in stone yet?
That's
Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
>
> On 10/26/18 10:26 PM, Elvis Stansvik wrote:
> > For completely other reasons, I came across "Range-based for
> > statements with initializer" today:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
> >
> >
On 10/26/18 10:26 PM, Elvis Stansvik wrote:
For completely other reasons, I came across "Range-based for
statements with initializer" today:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
With that, the Qt best practice could become
for (const auto list =
Indeed, the CI appears to be down as a whole. There is one single change in
integrating state and that since yesterday, so it’s certainly not processing.
Simon
> On 27. Oct 2018, at 07:53, Thiago Macieira wrote:
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect
32 matches
Mail list logo
