Re: [Development] QUIP 12: Code of Conduct
On Sunday, 28 October 2018 17:20:04 PDT Alexey Andreyev wrote: > > Sure, but again that's why we have a committee behind who will evaluate > the > > charges and decide what the proper action to be taken is. If the charges > are > > fake, then the accused would of course not be affected in any way. And if > the > > accuser keeps making false accusations, that's the one who could face > > sanctions. > > Sanctions like ban with additional false accusations about harassment could > be sent to mass media to create negative image of the community. And if the mass media does buy into the fake story, what can we do? The attacker can seize on any particular point of our community, whether there's a CoC or not. They could attack us for *not* having one in the first place and having no method to address their fake injutsice. They could attack us for having a security mailing list that judged a particular issue they reported not to be a security problem, etc. If they want to be malicious, they'll find a way. And if the media sides with them, not giving us a chance to explain, what are we going to do? > Let's take a look at archlinux CoC for example: > https://wiki.archlinux.org/index.php/Code_of_conduct > > Literally no vulnerable promises about protecting from harassment that > could be hard to keep. Additional mention at archwiki not to play with > controvertial non-related subjects at technical place: Which promises in other CoCs do you find vulnerable? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sunday, 28 October 2018 16:53:01 PDT Lydia Pintscher wrote: > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of > > times > > that they were maliciously asked to look into situations and how much time > > it took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. Hi Lydia Thanks for chiming in. Note I asked about malicious request to the CWG, not legitimate ones. I mean baseless accusations, based on no actual fact, just attempts to smear someone or generate useless expediture of people's time. Has that happened, at all? If so, how long did the committee spend addressing it? How much effort was put into it? Maybe we can also expand to accusations that, though not malicious, were found not to be under the CoC's purview, like asking someone to be removed due to some action on their personal time. > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. You must remember we discussion we had in KDE 10 years ago. As I wrote in my email here, I was one of those not convinced of the need to have a text at all, and I do think several other proeminent community members were like me. But the discussion went through and we were won out. Now I see the value of it that I didn't then. Almost all the emails in this thread have been civil and willing to engage in discussion, though not without some language barriers sometimes. I'm not seeing anyone in a different light as I did a week ago. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sunday, 28 October 2018 14:57:42 PDT Konstantin Shegunov wrote: > Note: I continue to think that KDE's CoC's text is written better and more > clearly. me too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Thank you, Lydia and everyone! I hope I'm not upsetting anyone. I could accept I'm taking too much attention to the subject. Qt project is very valuable for me as a user and a developer. пн, 29 окт. 2018 г. в 2:53, Lydia Pintscher : > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > > that they were maliciously asked to look into situations and how much > time it > > took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. > > (For those who don't know me: I'm one of the people who wrote KDE's > CoC and has been a member of it's community working group since then. > I'm also the current president of the non-profit behind KDE.) > If you have further questions about KDE's Code of Conduct please let > me know. I'm happy to answer them. > > > Cheers > Lydia > > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> Sure, but again that's why we have a committee behind who will evaluate the > charges and decide what the proper action to be taken is. If the charges are > fake, then the accused would of course not be affected in any way. And if the > accuser keeps making false accusations, that's the one who could face > sanctions. Sanctions like ban with additional false accusations about harassment could be sent to mass media to create negative image of the community. > No one said that keeping a > community welcoming is free. It requires all of us to look after one another > and our shared values. > But I think it's a price we're willing to pay. I'm not saying we should not work on shared values. As I said earlier many times, I agree we need rules. Let's take a look at archlinux CoC for example: https://wiki.archlinux.org/index.php/Code_of_conduct Literally no vulnerable promises about protecting from harassment that could be hard to keep. Additional mention at archwiki not to play with controvertial non-related subjects at technical place: "The staff certainly realize that such issues are deeply ingrained human realities. However, this is a technical community and is not intended nor able to effectively facilitate such commentary nor the resulting unrest." > And I'm pretty sure the KDE Community WG can easily compile a list of times > that they were maliciously asked to look into situations and how much time it > took them to give it the attention it was due. Thank you! It would be nice to see with general numbers, to make a comparison, but I agree it is very hard to research > Tell us how to measure the benefit compared to not having a CoC. I never said we don't need a CoC. I've said that not any CoC is healthy. пн, 29 окт. 2018 г. в 0:44, Thiago Macieira : > On Sunday, 28 October 2018 13:18:02 PDT Alexey Andreyev wrote: > > > The text is clear - actions will be taken to stop the discrimination. > > > That involves technical means (kick / ban) but also more social means > > > > It is not clear. Intruder could ask to ban some person pretending it's > > discrimination problem. > > Sure, but again that's why we have a committee behind who will evaluate > the > charges and decide what the proper action to be taken is. If the charges > are > fake, then the accused would of course not be affected in any way. And if > the > accuser keeps making false accusations, that's the one who could face > sanctions. > > > intruder could ask to accept vulnerable changes. > > And why would you or an approver accept technically inferior solutions? No > one > is saying that we should do that. All that is required is to be civil and > harassment-free when discussing such a solution. > > > All the described situations requires resources from the community. > > It also could be used to something could be called denial-of-community > > situation. > > Yes, it does require resources from the community. No one said that > keeping a > community welcoming is free. It requires all of us to look after one > another > and our shared values. > > But I think it's a price we're willing to pay. > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > that they were maliciously asked to look into situations and how much time > it > took them to give it the attention it was due. > > > In general, it could be used to change the image of the community to made > > it less popular > > and decrease the number of new members. > > How could it be used to do that? > > > Anyway, I guess there's still no scientific research and social survey > > about the number of the situations that could be called conflicts. > > So I don't see what problem should be solved right now. > > First of all, there are enough situations handled by multiple CoC > committees > in several communities to prove that it's worth it. There have been > situations > when they've been called to act and they have. I'd like to know about > situations that were resolved peacefully and the person who was found to > be > doing harassing changed their behaviour. > > As for a scientific research, it's pretty hard with social situations, > like > almost anything related to people's behaviour: communities are different > from > one another and you can't have a control group to see what happens if you > don't adopt a CoC. > > > I could not accept an answer like "let's try and see" since we didn't > even > > proposed metrics how to check new CoC is helping. > > Tell us how to measure the benefit compared to not having a CoC. > > I'll be very satisfied even if we have a total of zero times the CoC acts > in > the next 5 years and that no new contributor mentions reading the CoC > before > joining the community. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org >
Re: [Development] QUIP 12: Code of Conduct
On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira wrote: > And I'm pretty sure the KDE Community WG can easily compile a list of times > that they were maliciously asked to look into situations and how much time it > took them to give it the attention it was due. I don't have an exact number but less than 10. And we could always deal with it very quickly thanks to some common sense and good knowledge of the situation and people involved. No big deal. (For those who don't know me: I'm one of the people who wrote KDE's CoC and has been a member of it's community working group since then. I'm also the current president of the non-profit behind KDE.) If you have further questions about KDE's Code of Conduct please let me know. I'm happy to answer them. Cheers Lydia PS: As someone on the fringes of the Qt Project some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one. -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sunday, 28 October 2018 13:18:02 PDT Alexey Andreyev wrote: > > The text is clear - actions will be taken to stop the discrimination. > > That involves technical means (kick / ban) but also more social means > > It is not clear. Intruder could ask to ban some person pretending it's > discrimination problem. Sure, but again that's why we have a committee behind who will evaluate the charges and decide what the proper action to be taken is. If the charges are fake, then the accused would of course not be affected in any way. And if the accuser keeps making false accusations, that's the one who could face sanctions. > intruder could ask to accept vulnerable changes. And why would you or an approver accept technically inferior solutions? No one is saying that we should do that. All that is required is to be civil and harassment-free when discussing such a solution. > All the described situations requires resources from the community. > It also could be used to something could be called denial-of-community > situation. Yes, it does require resources from the community. No one said that keeping a community welcoming is free. It requires all of us to look after one another and our shared values. But I think it's a price we're willing to pay. And I'm pretty sure the KDE Community WG can easily compile a list of times that they were maliciously asked to look into situations and how much time it took them to give it the attention it was due. > In general, it could be used to change the image of the community to made > it less popular > and decrease the number of new members. How could it be used to do that? > Anyway, I guess there's still no scientific research and social survey > about the number of the situations that could be called conflicts. > So I don't see what problem should be solved right now. First of all, there are enough situations handled by multiple CoC committees in several communities to prove that it's worth it. There have been situations when they've been called to act and they have. I'd like to know about situations that were resolved peacefully and the person who was found to be doing harassing changed their behaviour. As for a scientific research, it's pretty hard with social situations, like almost anything related to people's behaviour: communities are different from one another and you can't have a control group to see what happens if you don't adopt a CoC. > I could not accept an answer like "let's try and see" since we didn't even > proposed metrics how to check new CoC is helping. Tell us how to measure the benefit compared to not having a CoC. I'll be very satisfied even if we have a total of zero times the CoC acts in the next 5 years and that no new contributor mentions reading the CoC before joining the community. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sun, Oct 28, 2018 at 9:51 PM Thiago Macieira wrote: > I'm pretty sure their company HR would want to have a chat anyway. > Well, I'm not as sure as you, but I am hopeful. > That's also a good reason to choose the KDE CoC, as both TQtC and KDAB > recruit > heavily from the KDE community and its CoC is basically a statement of > shared > values. > A very good point. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sun, Oct 28, 2018 at 2:08 PM Martin Smith wrote: > No, it isn't a resolution. Not reacting to a complaint is no resolution. Given the (current) structure of the community I take that as the offence not carrying merit. But even if "the community" does react to the alleged offense, how is that > different from mob rule? > It is not. Note that having a committee doesn't exclude mob rule either. In all fairness, though, it makes it less likely, as I can easily imagine the people voted in are going to be of significant integrity. >Not only can I, I pretty much have to. > > No. You don't. You used the word "heinous." It has a meaning. You used it > deliberately to draw attention away from the problems the CoC is meant to > resolve. > I did no such thing, and I resent the accusation. I'm not defending the CoC text and premise. I'm defending the goal of > establishing a CoC. > Then I have no idea why we are arguing. I was just responding in good faith to a question that was put forth. From the very beginning of this thread I have operated under the assumption that a CoC is going to be adopted in some form or another. My turn to bite. What is a heinous act that is not a criminal act? > Personal attacks, baseless accusations, mean-spirited comments, a combination thereof. Anything that's beyond distasteful, but still doesn't constitute a crime. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> So, as far as I see you have not identified any controversial > sentences either I've defined controversial sentences previously about proposed harassment-free pledge part and KDE's protection from discrimination part. > see people reporting on successes of KDE CoC and > problems with kernel one Could you provide the link with research or any other details about successes of the KDE CoC? > The text is clear - actions will be taken to stop the discrimination. > That involves technical means (kick / ban) but also more social means It is not clear. Intruder could ask to ban some person pretending it's discrimination problem. intruder could ask to accept vulnerable changes. All the described situations requires resources from the community. It also could be used to something could be called denial-of-community situation. In general, it could be used to change the image of the community to made it less popular and decrease the number of new members. Anyway, I guess there's still no scientific research and social survey about the number of the situations that could be called conflicts. So I don't see what problem should be solved right now. I could not accept an answer like "let's try and see" since we didn't even proposed metrics how to check new CoC is helping. вс, 28 окт. 2018 г. в 22:29, Tomasz Siekierda : > > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > > > controversial sentences. Could you elaborate? Which points shall be > > > discussed? > > > > > > > The controversial discrimination protection sentences at least > should be carefully discussed. It's not some thing that we could accept as > easy as rewrite. > > On Sun, 28 Oct 2018 at 11:34, Alexey Andreyev > wrote: > > > > Hello, Tomasz! :) > > Thank you for the question! > > > > > > [...] > > > > Do we have any research about effects it leading? > > > > How many discrimination suspicions do we have right now? > > > > How could it be resolved successfully at digital community? > > > > How many misuse examples do we have at open projects since accepting > similar rules? > > > > How CoC board are going to protect community from discrimination and > harassment? > > > > Are CoC committee ready for "affirmative action"? > > > > [...] > > So, as far as I see you have not identified any controversial > sentences either, your questions are more general and have been > answered already (see people reporting on successes of KDE CoC and > problems with kernel one). > > Regarding: > > > How CoC board are going to protect community from discrimination and > harassment? > > The text is clear - actions will be taken to stop the discrimination. > That involves technical means (kick / ban) but also more social means > (talking with both parties, trying to mediate, trying to understand > what is going on etc. - all this is mentioned in CoC draft). > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Saturday, 27 October 2018 13:40:42 PDT Konstantin Shegunov wrote: > > Note also it applies to any company. If you're not welcome anymore in the > > community where your employer is asking you to do work, that is going to > > affect your employment. > > I agree. However my argument was that the QtC being a major contributor to > the codebase is going to have to abide by the ruling of the proposed > committee, which is a significant commitment (and a major nitpick I admit). Correct, they would have to, but given that it looks like the majority of them are in agreement, it doesn't look problematic. And besides, if any of them or the KDABians started being obnoxious and hostile, given how many of their coworkers are working on this project, I'm pretty sure their company HR would want to have a chat anyway. That's also a good reason to choose the KDE CoC, as both TQtC and KDAB recruit heavily from the KDE community and its CoC is basically a statement of shared values. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > > controversial sentences. Could you elaborate? Which points shall be > > discussed? > > > > > The controversial discrimination protection sentences at least should be > > > carefully discussed. It's not some thing that we could accept as easy as > > > rewrite. On Sun, 28 Oct 2018 at 11:34, Alexey Andreyev wrote: > > Hello, Tomasz! :) > Thank you for the question! > > > [...] > > Do we have any research about effects it leading? > > How many discrimination suspicions do we have right now? > > How could it be resolved successfully at digital community? > > How many misuse examples do we have at open projects since accepting similar > rules? > > How CoC board are going to protect community from discrimination and > harassment? > > Are CoC committee ready for "affirmative action"? > > [...] So, as far as I see you have not identified any controversial sentences either, your questions are more general and have been answered already (see people reporting on successes of KDE CoC and problems with kernel one). Regarding: > How CoC board are going to protect community from discrimination and > harassment? The text is clear - actions will be taken to stop the discrimination. That involves technical means (kick / ban) but also more social means (talking with both parties, trying to mediate, trying to understand what is going on etc. - all this is mentioned in CoC draft). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: > It is a bit ironic that one reason given to deprecate Q_FOREACH is that it > may copy the container in some cases, while the alternative has the same > problem in much more common cases. (It is my impression that implicitly > shared container such as QList/QVector are by far much more used than the > one that are not within a typical Qt code base) There are two problems with Q_FOREACH: 1) it will copy containers. For Qt containers, that's rather cheap (two atomic refcount operations), but it's not free. And for Standard Library containers, that is likely very expensive. 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code Our rule already was: Don't use foreach in Qt code. (it was fine in examples) Using iterators and now using the ranged for may need more typing, but produces optimal code. > What could be done is to only deprecate partial specialization of > qMakeForeachContainer for QVarLenghtArray and the standard containers. > Or for containers that do not have a 'detach' function. > That way, users would get a warning for the problematic containers, but > would continue to work just fine with with the containers most Qt developer > use. I disagree. The optimisation problem is not solved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sunday, 28 October 2018 08:36:17 PDT André Pönitz wrote: > That would be a valid reason in case there had been or we would > expect to be unstoppable abusive behaviour. > > Most abusive behaviour on the mailing lists and IRC can be > stopped by technical means, in exceptional cases like the recent > spam attack on FreeNode also a coc won't help. Spam is pretty obvious, since spammy messages are off-topic and the spammer is not going to bother contesting the filter. But if it isn't spam, what gives the list moderator the right to intervene in something that he/she believes is abusive behaviour? Same thing about IRC: we do have one annoying person who does come along every now and then, but most of his messages are just that: annoyance. It's only when he uses profanity that I feel justified in kicking him out of the channel. Am I the one abusing my position as channel op to kick him? Am I being arbitrary? > > We need a formal procedure to enable that, and the CoC is that > > procedure. > > This "we" needs qualification. It apparently does not include me. Of course it does. Why do you feel excluded? Or did you mean you feel you don't need a procedure? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On 10/27/18 5:27 PM, Sérgio Martins 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. But what's the percentage of Qt developers that understand the subtleties between Q_FOREACH and range-for ? Having a toolbox with two similar-but-not-quite constructs is bad for less seasoned users. I prefer explicitly assigning the container to a const local variable instead of relying in the magic behind macros. I don't know... what's the percentage of Qt developers that understands when to use this qAsConst or const copy gymnastic? It is a bit ironic that one reason given to deprecate Q_FOREACH is that it may copy the container in some cases, while the alternative has the same problem in much more common cases. (It is my impression that implicitly shared container such as QList/QVector are by far much more used than the one that are not within a typical Qt code base) What could be done is to only deprecate partial specialization of qMakeForeachContainer for QVarLenghtArray and the standard containers. Or for containers that do not have a 'detach' function. That way, users would get a warning for the problematic containers, but would continue to work just fine with with the containers most Qt developer use. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Undeprecating Q_FOREACH (was: Re: qMoveToConst helper for rvalue references to movable Qt containers?)
Il 28/10/18 15:42, Kevin Kofler ha scritto: As long as it is not actually removed, it is not too late to undo this totally incorrect decision. See also:https://valdyas.org/fading/hacking/happy-porting/ (Technically, it could be readded even after it is removed, but it would be much easier to undeprecate it now.) Please bring technical arguments to the table for undoing this deprecation. So far, this hasn't been done, so the deprecation stands and likely go into effect the first time we get a chance of breaking SC. Note that "annoyance for end-users" is not an argument. In the absence of infinite development bandwidth, and given the natural evolution of software, Qt will need to shed some old crust from time to time, even if that means annoyances for the users. I briefly discussed about this here: https://www.kdab.com/un-deprecate-qt-project/ Specifically for Q_FOREACH, if a project doesn't want to move away, then the solution takes 5 minutes: 1) copy and paste Q_FOREACH's implementation in a central header of your project 2) rename it to MY_FOREACH 3) do a search/replace of Q_FOREACH to MY_FOREACH throughout the project's code base And that's it. Yes, this is effectively a fork, which means you'll also need to backport any fixes that in the meanwhile land upstream. And they _do land_, even for something apparently as "mundane" as Q_FOREACH: https://codereview.qt-project.org/#/c/179396/ https://codereview.qt-project.org/#/c/176299/ > https://codereview.qt-project.org/#/c/176298/ https://codereview.qt-project.org/#/c/170073/ https://codereview.qt-project.org/#/c/167065/ https://codereview.qt-project.org/#/c/140268/ Why should the Qt Project invest any resource whatsoever maintaining a solution to a problem that has also been solved by the C++ language (and in a more efficient and general way than Q_FOREACH)? -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] How to create dummy plugins in qtbase?
Hello all, I am currently working on improving Qt's CMake support, and I've written some rather complicated logic that I want to test thoroughly - specifically, I want to make sure that an exact list of plugins that I've requested has been statically loaded, no more, and no less. The easiest way to do this would be to create a new dummy Qt module which contains a bunch of dummy plugins for me to load. However, I'm not sure how to create a new Qt module that's visible to the tests without also being installed/visible outside the tests. I've attempted to hack together an external project outside the qtbase tree that creates some plugins, but I'm not very familiar with qmake, and in its current state it is installing its plugins into the qtbase build tree, which is undesirable (I want it to install them into its own build tree instead.) Can someone who's more familiar with qmake help me out here? Thank you very much. Kyle ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
I agree my example is extremely contrived right now, I just tried to show the idea. Thank you, Elvis, for your answers. > getting your patches rejected is not harassment I agree that getting some patches rejected without any additional info is not a harassment by default I'm saying something like "water wears away a stone". What could you say about public conflicts at Opal, Github, Django, Ruby, PHP, Nodejs, Drupal, Linux after accepting similar CoC? > The patches can be respectfully rejected with e.g. "this is not in > line with the Qt vision", or "could you please revise this part > first?". It easily could be misused as blocking due to discrimination with existing CoC and the question of resources and time on both sides > See the difference? Yes, of course. But I'm not talking about where CoC could be helpful right now, I agree we need rules. I'm trying to pay attention on the current implementation. We (me too) spend literally 0 minutes to scientifically research social state of the Qt community, didn't research influence and the trends of the accepted CoC at other projects. Nobody held even one social survey about the nubmer of the conflicts at Qt project before, anything like that. Nobody tried to predict the consequences after accepting current CoC. We just trying to provide some rules and to treat something blindly without even specifying the problem. вс, 28 окт. 2018 г. в 17:35, Elvis Stansvik : > Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev > : > > > > > [...] or the shorter list in the KDE CoC, so we instinctively > > > want to trim the fat - we want to optimize. > > > > I've provided both (CC and from KDE) not to show some version is better, > > but to show both have same problems. > > > > For me it's not about optimization right now. Is it possible to follow > provided versions? > > And receive more positive for the commuity than negative. > > > > > the purpose of this enumeration is to list those very large > > > groups of people in society who are currently experiencing harassment > > > and mistreatment for who they are > > > > Is that obvious that provided document will help not made things worse > for everyone? > > Are we going to treat something at the commuity just blindly without > diagnosis and research? > > > > > We tell a large part of the population who are currently > > > being oppressed/mistreated that, at least in our community, you can > > > feel safe > > > > How are we going to provide safety? > > > > > The enumeration is not supposed to cover everything, but I > > > think it fulfills a purpose by covering a lot. > > > > As far as I can see the reasoning is based on the hypothesis that any > rules will not be able to aggravate the situation. It's not obvious. > > > > > I don't agree with some earlier poster who thought of the enumeration > > > as setting some kind of bar, I don't think that is the purpose of it. > > > > > The concluding "[...] or any other characteristics that are > > > not relevant to a person's ability to contribute to the Qt Project." > > > is of course very important *as well*, to cover our bases. > > > > How the committee is going to determine that someone has violated these > "guidelines not bars"? > > What is the purpose of the guidelines without additional information how > to protect them? > > > > > I can't really see how this list could be misused. If people have an > > > issue with a particular item on the list, they should say so. > > > > For example, let's say some person (person or legal entity, organization > or groups of organizations) have projects, competing with Qt somehow (or > linux, or KDE). > > That "person/groups" will get more profit if Qt community will became > unhealthy or will cease to exist. > > That person could sponsor, support or pay money somehow to other persons > to support some vulnerable ideas. > > Persons who accept that ideas and have interests, conflicting with the > community, could say something like > > "hey, we are actually feeling harassment, please accept our > ideas/patches/anything too". > > It is a space for accepting non-obvious security or architectural > changes. > > > > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community > could lost their image of as awesome commuity as it is right now. > > I honestly think this is an extremely contrived example, and I think > you're worrying way too much, but OK let's play along. > > You're suggesting that someone would submit bad patches, hoping to get > harassed and thereby somehow get the patches in, as some sort of > compensation for the harassment, and would use this in order to > sabotage the Qt project? > > Looking past the ridiculousness of that idea for the moment, getting > your patches rejected is not harassment. Not under any definition of > harassment that I know of, and certainly not according to the > suggested CoC. > > The patches can be respectfully rejected with e.g. "this is not in > line with the Qt vision", or
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Sérgio Martins wrote: > On Sat, Oct 27, 2018 at 1:53 PM Elvis Stansvik wrote: >> Yes, I thought that Q_FOREACH was slated for deprecation though. But >> maybe that's not set in stone yet? > > It is, see Qt's documentation: > "Since Qt 5.7, the use of this macro is discouraged. It will be > removed in a future version of Qt" As long as it is not actually removed, it is not too late to undo this totally incorrect decision. See also: https://valdyas.org/fading/hacking/happy-porting/ (Technically, it could be readded even after it is removed, but it would be much easier to undeprecate it now.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sun, Oct 28, 2018 at 08:34:40AM +, Martin Smith wrote: > And because we are online and spread all around the world, there is > currently no way for us to stop and prevent abusive behavior. That would be a valid reason in case there had been or we would expect to be unstoppable abusive behaviour. Most abusive behaviour on the mailing lists and IRC can be stopped by technical means, in exceptional cases like the recent spam attack on FreeNode also a coc won't help. > We need a formal procedure to enable that, and the CoC is that > procedure. This "we" needs qualification. It apparently does not include me. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev : > > > [...] or the shorter list in the KDE CoC, so we instinctively > > want to trim the fat - we want to optimize. > > I've provided both (CC and from KDE) not to show some version is better, > but to show both have same problems. > > For me it's not about optimization right now. Is it possible to follow > provided versions? > And receive more positive for the commuity than negative. > > > the purpose of this enumeration is to list those very large > > groups of people in society who are currently experiencing harassment > > and mistreatment for who they are > > Is that obvious that provided document will help not made things worse for > everyone? > Are we going to treat something at the commuity just blindly without > diagnosis and research? > > > We tell a large part of the population who are currently > > being oppressed/mistreated that, at least in our community, you can > > feel safe > > How are we going to provide safety? > > > The enumeration is not supposed to cover everything, but I > > think it fulfills a purpose by covering a lot. > > As far as I can see the reasoning is based on the hypothesis that any rules > will not be able to aggravate the situation. It's not obvious. > > > I don't agree with some earlier poster who thought of the enumeration > > as setting some kind of bar, I don't think that is the purpose of it. > > > The concluding "[...] or any other characteristics that are > > not relevant to a person's ability to contribute to the Qt Project." > > is of course very important *as well*, to cover our bases. > > How the committee is going to determine that someone has violated these > "guidelines not bars"? > What is the purpose of the guidelines without additional information how to > protect them? > > > I can't really see how this list could be misused. If people have an > > issue with a particular item on the list, they should say so. > > For example, let's say some person (person or legal entity, organization or > groups of organizations) have projects, competing with Qt somehow (or linux, > or KDE). > That "person/groups" will get more profit if Qt community will became > unhealthy or will cease to exist. > That person could sponsor, support or pay money somehow to other persons to > support some vulnerable ideas. > Persons who accept that ideas and have interests, conflicting with the > community, could say something like > "hey, we are actually feeling harassment, please accept our > ideas/patches/anything too". > It is a space for accepting non-obvious security or architectural changes. > > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community could > lost their image of as awesome commuity as it is right now. I honestly think this is an extremely contrived example, and I think you're worrying way too much, but OK let's play along. You're suggesting that someone would submit bad patches, hoping to get harassed and thereby somehow get the patches in, as some sort of compensation for the harassment, and would use this in order to sabotage the Qt project? Looking past the ridiculousness of that idea for the moment, getting your patches rejected is not harassment. Not under any definition of harassment that I know of, and certainly not according to the suggested CoC. The patches can be respectfully rejected with e.g. "this is not in line with the Qt vision", or "could you please revise this part first?". The patches can also be rejected with "please don't submit crap like this, you fat dyke". See the difference? The first is not a matter for the CoC. If the party would still file a complaint, it would be dealt with and the council would find that no harassment took place. The second would most certainly be cause for some kind of action (I guess to begin with, tell the offender to not do that again and point them to the CoC). Elvis > > ..??? > > PROFIT! Young generation not interested, no support, commuity is dying, > profit for competing projects. > > > It's just one example that could sound like a joke since I'm not a > professional with this kind of tricky social questions, > but I hope I showed the danger as a caricature at least. > > I don't want my arguments be adressed to someone personally, and I'm not > saying there's some conspiracy here. > I just want to help to save and develop the community for the future. > > I agree we need rules. My problem is not any rules are healthy. > > вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : >> >> Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev >> : >> > >> > Hello, Tomasz! :) >> > Thank you for the question! >> > >> > Current draft based on CoC: >> > >> > > Our Pledge >> > > == >> > > In the interest of fostering an open and welcoming environment, we >> > > as contributors to and maintainers of the Qt Project pledge to make >> > > participation in our project and our community a harassment-free >> > > experience for everyone,
Re: [Development] QUIP 12: Code of Conduct
> [...] or the shorter list in the KDE CoC, so we instinctively > want to trim the fat - we want to optimize. I've provided both (CC and from KDE) not to show some version is better, but to show both have same problems. For me it's not about optimization right now. Is it possible to follow provided versions? And receive more positive for the commuity than negative. > the purpose of this enumeration is to list those very large > groups of people in society who are currently experiencing harassment > and mistreatment for who they are Is that obvious that provided document will help not made things worse for everyone? Are we going to treat something at the commuity just blindly without diagnosis and research? > We tell a large part of the population who are currently > being oppressed/mistreated that, at least in our community, you can > feel safe How are we going to provide safety? > The enumeration is not supposed to cover everything, but I > think it fulfills a purpose by covering a lot. As far as I can see the reasoning is based on the hypothesis that any rules will not be able to aggravate the situation. It's not obvious. > I don't agree with some earlier poster who thought of the enumeration > as setting some kind of bar, I don't think that is the purpose of it. > The concluding "[...] or any other characteristics that are > not relevant to a person's ability to contribute to the Qt Project." > is of course very important *as well*, to cover our bases. How the committee is going to determine that someone has violated these "guidelines not bars"? What is the purpose of the guidelines without additional information how to protect them? > I can't really see how this list could be misused. If people have an > issue with a particular item on the list, they should say so. For example, let's say some person (person or legal entity, organization or groups of organizations) have projects, competing with Qt somehow (or linux, or KDE). That "person/groups" will get more profit if Qt community will became unhealthy or will cease to exist. That person could sponsor, support or pay money somehow to other persons to support some vulnerable ideas. Persons who accept that ideas and have interests, conflicting with the community, could say something like "hey, we are actually feeling harassment, please accept our ideas/patches/anything too". It is a space for accepting non-obvious security or architectural changes. In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community could lost their image of as awesome commuity as it is right now. ..??? PROFIT! Young generation not interested, no support, commuity is dying, profit for competing projects. It's just one example that could sound like a joke since I'm not a professional with this kind of tricky social questions, but I hope I showed the danger as a caricature at least. I don't want my arguments be adressed to someone personally, and I'm not saying there's some conspiracy here. I just want to help to save and develop the community for the future. I agree we need rules. My problem is not any rules are healthy. вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : > Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev > : > > > > Hello, Tomasz! :) > > Thank you for the question! > > > > Current draft based on CoC: > > > > > Our Pledge > > > == > > > In the interest of fostering an open and welcoming environment, we > > > as contributors to and maintainers of the Qt Project pledge to make > > > participation in our project and our community a harassment-free > > > experience for everyone, regardless of age, body size, disability, > > > ethnicity, sex characteristics, gender identity and expression, level > > > of experience, education, socio-economic status, nationality, personal > > > appearance, race, religion, or sexual identity and orientation, > > > or any other characteristics that are not relevant to a person's > > > ability to contribute to the Qt Project. > > A lot of people seem to have a problem with this long enumeration. > > I think this is because we're programmers, and we think of it as > redundant given the concluding "[...] or any other characteristics > that are not relevant to a person's ability to contribute to the Qt > Project.", or the shorter list in the KDE CoC, so we instinctively > want to trim the fat - we want to optimize. > > But, and this is of course just my personal opinion/interpretation, I > think the purpose of this enumeration is to list those very large > groups of people in society who are currently experiencing harassment > and mistreatment for who they are. The pledge is supposed to be a set > of guidelines for how the community operates, but *also* a message to > potential contributors. Thought of that way, I think the enumeration > makes sense: We tell a large part of the population who are currently > being oppressed/mistreated that, at least in our community, you can > feel safe. The
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 13:32 skrev Giuseppe D'Angelo via Development : > > Il 28/10/18 11:22, Elvis Stansvik ha scritto: > > Though hmm, even if we'd lose move-construction, for the copy we'd get > > instead, wouldn't copy elision kick in and elide it? So we wouldn't > > have to pay for the ref count up/down? > > GCE is one thing, and applies in a very specific case (returning a > prvalue). > > (N)RVO is another thing, and may or may not be applied depending on > whether the compiler *can* apply it and *will* apply it. > > In the general case, you won't have either, and thus having a move will > be cheaper than a copy. Returning const objects for types which benefit > from moves is a bad idea. Ah yes of course, my bad. Elvis > > My 2 c, > > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Il 27/10/18 17:27, Sérgio Martins ha scritto: It is, see Qt's documentation: "Since Qt 5.7, the use of this macro is discouraged. It will be removed in a future version of Qt" ... we need to start adding actual deprecation macros, or people will never notice. https://codereview.qt-project.org/#/c/243949/ Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Il 28/10/18 11:22, Elvis Stansvik ha scritto: Though hmm, even if we'd lose move-construction, for the copy we'd get instead, wouldn't copy elision kick in and elide it? So we wouldn't have to pay for the ref count up/down? GCE is one thing, and applies in a very specific case (returning a prvalue). (N)RVO is another thing, and may or may not be applied depending on whether the compiler *can* apply it and *will* apply it. In the general case, you won't have either, and thus having a move will be cheaper than a copy. Returning const objects for types which benefit from moves is a bad idea. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
>In any case, the current status quo, which is what I described, ends in either >the >community reacting or not reacting to the alleged offence (i.e. isolating the >offensive party for example). That is A resolution, be it a good one or bad. No, it isn't a resolution. Not reacting to a complaint is no resolution. But even if "the community" does react to the alleged offense, how is that different from mob rule? >Not only can I, I pretty much have to. No. You don't. You used the word "heinous." It has a meaning. You used it deliberately to draw attention away from the problems the CoC is meant to resolve. We don't need a CoC to deal with heinous offenses because heinous offenses are dealt with by the police. >You can't defend the CoC's text and premise on the basis that my argument is >unlikely, or extreme. I'm not defending the CoC text and premise. I'm defending the goal of establishing a CoC. >Not if they don't elevate to a criminal act. My turn to bite. What is a heinous act that is not a criminal act? From: Konstantin Shegunov Sent: Sunday, October 28, 2018 11:35:42 AM To: Martin Smith Cc: development@qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sun, Oct 28, 2018 at 10:43 AM Martin Smith mailto:martin.sm...@qt.io>> wrote: >Oh, it is going to end in A resolution, it may not end the way the offended >party >may feel just, but that's true also for the proposed text. HA! You are not Konstantin Shegunov! A software engineer would imediately see that your 3 step CoC might not terminate. You are an imposter! That's actually amusing, but I'll bite. Formally speaking, I'm not a software engineer, never had any formal training in the field. I'm a physicist who moonlights as a programmer. In any case, the current status quo, which is what I described, ends in either the community reacting or not reacting to the alleged offence (i.e. isolating the offensive party for example). That is A resolution, be it a good one or bad. >imagine that the abusive party is an employee of the QtC and has committed >heinous acts against a community member. You can't immediately jump to the worst case scenario to discredit the code of conduct. In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. Not only can I, I pretty much have to. Minor infringements can already be handled internally without the need for CoC, major ones is where it would actually matter if we have one and which one we chose. Also it's a perfectly valid logic to push an argument to the extreme to see if holds, we do it on every day basis. In math you can assume something, operate on the presumption and see if contradicts itself when pushed (reductio ad impossibilem). If I were to design a safety net for a nuclear power plant am I to just ignore the extreme or unlikely case? Surely not. You compared the CoC to a "local law" of sorts, but does the local law forgo the unlikely case that from the whole population one person would be a murderer? I shouldn't think so. You can't defend the CoC's text and premise on the basis that my argument is unlikely, or extreme. It has to able to withstand exactly those extremes! In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. Not if they don't elevate to a criminal act. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev : > > Hello, Tomasz! :) > Thank you for the question! > > Current draft based on CoC: > > > Our Pledge > > == > > In the interest of fostering an open and welcoming environment, we > > as contributors to and maintainers of the Qt Project pledge to make > > participation in our project and our community a harassment-free > > experience for everyone, regardless of age, body size, disability, > > ethnicity, sex characteristics, gender identity and expression, level > > of experience, education, socio-economic status, nationality, personal > > appearance, race, religion, or sexual identity and orientation, > > or any other characteristics that are not relevant to a person's > > ability to contribute to the Qt Project. A lot of people seem to have a problem with this long enumeration. I think this is because we're programmers, and we think of it as redundant given the concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project.", or the shorter list in the KDE CoC, so we instinctively want to trim the fat - we want to optimize. But, and this is of course just my personal opinion/interpretation, I think the purpose of this enumeration is to list those very large groups of people in society who are currently experiencing harassment and mistreatment for who they are. The pledge is supposed to be a set of guidelines for how the community operates, but *also* a message to potential contributors. Thought of that way, I think the enumeration makes sense: We tell a large part of the population who are currently being oppressed/mistreated that, at least in our community, you can feel safe. The enumeration is not supposed to cover everything, but I think it fulfills a purpose by covering a lot. I don't agree with some earlier poster who thought of the enumeration as setting some kind of bar, I don't think that is the purpose of it. It is meant as a message, and to drive that message home with the groups of people we want to reach, I think it makes sense to be explicit. The concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project." is of course very important *as well*, to cover our bases. If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer widespread discrimination and mistreatment of people for their race, religion or sexual identity/orientation, but some other groups are being mistreated (again, sorry for the pessimism), then I think it's perfectly fine to revise this list. I can't really see how this list could be misused. If people have an issue with a particular item on the list, they should say so. That's just my 2 cents on the enumeration, which seems to bug people, and I completely understand if others see it differently. Elvis > > and KDE version: > > > We do not tolerate personal attacks, racism, sexism or any other form of > > discrimination. > > Do we have any research about effects it leading? > > How many discrimination suspicions do we have right now? > > How could it be resolved successfully at digital community? > > How many misuse examples do we have at open projects since accepting similar > rules? > > How CoC board are going to protect community from discrimination and > harassment? > > Are CoC committee ready for "affirmative action"? > > I'm not against the rules as a concept, I agree we need it, > but I totally against perverted or undefined rules that could help to destroy > the community. > > I could not accept argument like "let's accept just anything and see how it > goes and fix something later". > "Don't code today what you can't debug tomorrow" :) > > I'm just saying we should think twice befoce accepting something. > > P.S.: I'm ready to change my mind if I've made a mistake, feel free to > criticize, correct and ignore me :) > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : >> >> > The controversial discrimination protection sentences at least should be >> > carefully discussed. It's not some thing that we could accept as easy as >> > rewrite. >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any >> controversial sentences. Could you elaborate? Which points shall be >> discussed? >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov >> wrote: >> > >> > 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 >> >> the >> >> CoC does not rule TQtC employment and what other work there is inside that >> >> company. >> >> >> >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> >> community where your employer is asking you to do work,
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik :
>
> 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. You'll
> > pay
> > the cost of two reference counts (one up and one down).
>
> Though hmm, even if we'd lose move-construction, for the copy we'd get
> instead, wouldn't copy elision kick in and elide it? So we wouldn't
> have to pay for the ref count up/down?
>
> I simplified my example a little, so to recap:
>
> $ cat copytest.cpp
> #include
> #include
>
> struct Foo {
> Foo() {
> std::cout << this << " constructed" << std::endl;
> }
> Foo(const Foo &) {
> std::cout << this << " copy constructed" << std::endl;
> }
> Foo(Foo &&) {
> std::cout << this << " move constructed" << std::endl;
> }
> ~Foo() {
> std::cout << this << " destructed" << std::endl;
> }
> std::vector::iterator begin() {
> std::cout << this << " begin" << std::endl; return v.begin();
> };
> std::vector::const_iterator begin() const {
> std::cout << this << " begin const" << std::endl; return v.begin();
> };
> std::vector::iterator end() {
> std::cout << this << " end" << std::endl; return v.end();
> };
> std::vector::const_iterator end() const {
> std::cout << this << " end const" << std::endl; return v.end();
> };
> std::vector v{1, 2, 3};
> };
>
> Foo f() {
> Foo foo;
> return foo;
> }
>
> const Foo constF() {
> Foo foo;
> return foo;
> }
>
> template
> const T moveToConst(T &)
> {
> return std::move(t);
> }
>
> int main(void) {
> std::cout << "without moveToConst:" << std::endl;
> for (auto v : f()) { }
>
> std::cout << std::endl;
>
> std::cout << "with moveToConst:" << std::endl;
> for (auto v : moveToConst(f())) { }
>
> std::cout << std::endl;
>
> std::cout << "with returning const:" << std::endl;
> for (auto v : constF()) { }
>
> std::cout << std::endl;
>
> std::cout << "with recommended way:" << std::endl;
> const auto stuff = f();
> for (auto v : stuff) { }
>
> return 0;
> }
>
> Result:
>
> $ g++ -std=c++17 -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffcc6ac76b0 constructed
> 0x7ffcc6ac76b0 begin
> 0x7ffcc6ac76b0 end
> 0x7ffcc6ac76b0 destructed
>
> with moveToConst:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac76d0 move constructed
> 0x7ffcc6ac7710 destructed
> 0x7ffcc6ac76d0 begin const
> 0x7ffcc6ac76d0 end const
> 0x7ffcc6ac76d0 destructed
>
> with returning const:
> 0x7ffcc6ac76f0 constructed
> 0x7ffcc6ac76f0 begin const
> 0x7ffcc6ac76f0 end const
> 0x7ffcc6ac76f0 destructed
>
> with recommended way:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac7710 begin const
> 0x7ffcc6ac7710 end const
> 0x7ffcc6ac7710 destructed
>
> So it looks like the copy has been elided also in the "with returning
> const" case. Anyone know if this is guaranteed in C++17, or just
> permitted?
>
> If I compile with -fno-elide-constructors to disable elision:
>
> $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c1070f0 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c1070f0 begin
> 0x7ffe7c1070f0 end
> 0x7ffe7c1070f0 destructed
>
> with moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107110 move constructed
> 0x7ffe7c107150 destructed
> 0x7ffe7c107110 begin const
> 0x7ffe7c107110 end const
> 0x7ffe7c107110 destructed
>
> with returning const:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107130 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107130 begin const
> 0x7ffe7c107130 end const
> 0x7ffe7c107130 destructed
>
> with recommended way:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107150 begin const
> 0x7ffe7c107150 end const
> 0x7ffe7c107150 destructed
> $
I tried some more compilers.
With Apple Clang 9.0.0 and -std=c++14, the output is the same without
-fno-elide-constructors, but interestingly, if -fno-elide-constructors
is added, the output is:
with returning const:
0x7fff596ed8a8 constructed
0x7fff596eda20 move constructed
0x7fff596ed8a8 destructed
0x7fff596eda20 begin const
0x7fff596eda20 end const
0x7fff596eda20 destructed
with recommended way:
0x7fff596ed8a8 constructed
0x7fff596ed9c8 move constructed
0x7fff596ed8a8 destructed
0x7fff596ed9e0 move constructed
0x7fff596ed9c8 destructed
0x7fff596ed9e0 begin const
0x7fff596ed9e0 end const
0x7fff596ed9e0 destructed
With MSVC 2015 (compiled with just cl copytest.cpp), the output is:
with returning const:
009FFE4BFD90 constructed
009FFE4BFE88 move constructed
009FFE4BFD90
Re: [Development] QUIP 12: Code of Conduct
I agree with you, Konstantin вс, 28 окт. 2018 г. в 13:36, Konstantin Shegunov : > > > On Sun, Oct 28, 2018 at 10:43 AM Martin Smith wrote: > >> >Oh, it is going to end in A resolution, it may not end the way the >> offended party >> >may feel just, but that's true also for the proposed text. >> >> HA! You are not Konstantin Shegunov! A software engineer would imediately >> see that your 3 step CoC might not terminate. You are an imposter! >> > > That's actually amusing, but I'll bite. Formally speaking, I'm not a > software engineer, never had any formal training in the field. I'm a > physicist who moonlights as a programmer. In any case, the current status > quo, which is what I described, ends in either the community reacting or > not reacting to the alleged offence (i.e. isolating the offensive party for > example). That is A resolution, be it a good one or bad. > > >imagine that the abusive party is an employee of the QtC and has committed >> >heinous acts against a community member. >> >> You can't immediately jump to the worst case scenario to discredit the >> code of conduct. In fact, the CoC can deal with "heinous acts" by stating >> that such acts will be referred to the appropriate legal authority. >> > > Not only can I, I pretty much have to. Minor infringements can already be > handled internally without the need for CoC, major ones is where it would > actually matter if we have one and which one we chose. Also it's a > perfectly valid logic to push an argument to the extreme to see if holds, > we do it on every day basis. In math you can assume something, operate on > the presumption and see if contradicts itself when pushed (reductio ad > impossibilem). If I were to design a safety net for a nuclear power plant > am I to just ignore the extreme or unlikely case? Surely not. You compared > the CoC to a "local law" of sorts, but does the local law forgo the > unlikely case that from the whole population one person would be a > murderer? I shouldn't think so. > You can't defend the CoC's text and premise on the basis that my argument > is unlikely, or extreme. It has to able to withstand exactly those extremes! > > In fact, the CoC can deal with "heinous acts" by stating that such acts >> will be referred to the appropriate legal authority. > > > Not if they don't elevate to a criminal act. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Sun, Oct 28, 2018 at 10:43 AM Martin Smith wrote: > >Oh, it is going to end in A resolution, it may not end the way the > offended party > >may feel just, but that's true also for the proposed text. > > HA! You are not Konstantin Shegunov! A software engineer would imediately > see that your 3 step CoC might not terminate. You are an imposter! > That's actually amusing, but I'll bite. Formally speaking, I'm not a software engineer, never had any formal training in the field. I'm a physicist who moonlights as a programmer. In any case, the current status quo, which is what I described, ends in either the community reacting or not reacting to the alleged offence (i.e. isolating the offensive party for example). That is A resolution, be it a good one or bad. >imagine that the abusive party is an employee of the QtC and has committed > >heinous acts against a community member. > > You can't immediately jump to the worst case scenario to discredit the > code of conduct. In fact, the CoC can deal with "heinous acts" by stating > that such acts will be referred to the appropriate legal authority. > Not only can I, I pretty much have to. Minor infringements can already be handled internally without the need for CoC, major ones is where it would actually matter if we have one and which one we chose. Also it's a perfectly valid logic to push an argument to the extreme to see if holds, we do it on every day basis. In math you can assume something, operate on the presumption and see if contradicts itself when pushed (reductio ad impossibilem). If I were to design a safety net for a nuclear power plant am I to just ignore the extreme or unlikely case? Surely not. You compared the CoC to a "local law" of sorts, but does the local law forgo the unlikely case that from the whole population one person would be a murderer? I shouldn't think so. You can't defend the CoC's text and premise on the basis that my argument is unlikely, or extreme. It has to able to withstand exactly those extremes! In fact, the CoC can deal with "heinous acts" by stating that such acts > will be referred to the appropriate legal authority. Not if they don't elevate to a criminal act. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Hello, Tomasz! :) Thank you for the question! Current draft based on CoC: > Our Pledge > == > In the interest of fostering an open and welcoming environment, we > as contributors to and maintainers of the Qt Project pledge to make > participation in our project and our community a harassment-free > experience for everyone, regardless of age, body size, disability, > ethnicity, sex characteristics, gender identity and expression, level > of experience, education, socio-economic status, nationality, personal > appearance, race, religion, or sexual identity and orientation, > or any other characteristics that are not relevant to a person's > ability to contribute to the Qt Project. and KDE version: > We do not tolerate personal attacks, racism, sexism or any other form of discrimination. Do we have any research about effects it leading? How many discrimination suspicions do we have right now? How could it be resolved successfully at digital community? How many misuse examples do we have at open projects since accepting similar rules? How CoC board are going to protect community from discrimination and harassment? Are CoC committee ready for "affirmative action"? I'm not against the rules as a concept, I agree we need it, but I totally against perverted or undefined rules that could help to destroy the community. I could not accept argument like "let's accept just anything and see how it goes and fix something later". "Don't code today what you can't debug tomorrow" :) I'm just saying we should think twice befoce accepting something. P.S.: I'm ready to change my mind if I've made a mistake, feel free to criticize, correct and ignore me :) вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > The controversial discrimination protection sentences at least should be > carefully discussed. It's not some thing that we could accept as easy as > rewrite. > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > controversial sentences. Could you elaborate? Which points shall be > discussed? > On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov > wrote: > > > > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira < > thiago.macie...@intel.com> 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 the > >> CoC does not rule TQtC employment and what other work there is inside > that > >> company. > >> > >> > >> Note also it applies to any company. If you're not welcome anymore in > the > >> community where your employer is asking you to do work, that is going to > >> affect your employment. > > > > > > I agree. However my argument was that the QtC being a major contributor > to the codebase is going to have to abide by the ruling of the proposed > committee, which is a significant commitment (and a major nitpick I admit). > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik :
>
> 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. You'll
> > pay
> > the cost of two reference counts (one up and one down).
>
> Though hmm, even if we'd lose move-construction, for the copy we'd get
> instead, wouldn't copy elision kick in and elide it? So we wouldn't
> have to pay for the ref count up/down?
>
> I simplified my example a little, so to recap:
>
> $ cat copytest.cpp
> #include
> #include
>
> struct Foo {
> Foo() {
> std::cout << this << " constructed" << std::endl;
> }
> Foo(const Foo &) {
> std::cout << this << " copy constructed" << std::endl;
> }
> Foo(Foo &&) {
> std::cout << this << " move constructed" << std::endl;
> }
> ~Foo() {
> std::cout << this << " destructed" << std::endl;
> }
> std::vector::iterator begin() {
> std::cout << this << " begin" << std::endl; return v.begin();
> };
> std::vector::const_iterator begin() const {
> std::cout << this << " begin const" << std::endl; return v.begin();
> };
> std::vector::iterator end() {
> std::cout << this << " end" << std::endl; return v.end();
> };
> std::vector::const_iterator end() const {
> std::cout << this << " end const" << std::endl; return v.end();
> };
> std::vector v{1, 2, 3};
> };
>
> Foo f() {
> Foo foo;
> return foo;
> }
>
> const Foo constF() {
> Foo foo;
> return foo;
> }
>
> template
> const T moveToConst(T &)
> {
> return std::move(t);
> }
>
> int main(void) {
> std::cout << "without moveToConst:" << std::endl;
> for (auto v : f()) { }
>
> std::cout << std::endl;
>
> std::cout << "with moveToConst:" << std::endl;
> for (auto v : moveToConst(f())) { }
>
> std::cout << std::endl;
>
> std::cout << "with returning const:" << std::endl;
> for (auto v : constF()) { }
>
> std::cout << std::endl;
>
> std::cout << "with recommended way:" << std::endl;
> const auto stuff = f();
> for (auto v : stuff) { }
>
> return 0;
> }
I put it up on godbolt for this who want to play: https://godbolt.org/z/x6FPq_
Elvis
>
> Result:
>
> $ g++ -std=c++17 -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffcc6ac76b0 constructed
> 0x7ffcc6ac76b0 begin
> 0x7ffcc6ac76b0 end
> 0x7ffcc6ac76b0 destructed
>
> with moveToConst:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac76d0 move constructed
> 0x7ffcc6ac7710 destructed
> 0x7ffcc6ac76d0 begin const
> 0x7ffcc6ac76d0 end const
> 0x7ffcc6ac76d0 destructed
>
> with returning const:
> 0x7ffcc6ac76f0 constructed
> 0x7ffcc6ac76f0 begin const
> 0x7ffcc6ac76f0 end const
> 0x7ffcc6ac76f0 destructed
>
> with recommended way:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac7710 begin const
> 0x7ffcc6ac7710 end const
> 0x7ffcc6ac7710 destructed
>
> So it looks like the copy has been elided also in the "with returning
> const" case. Anyone know if this is guaranteed in C++17, or just
> permitted?
>
> If I compile with -fno-elide-constructors to disable elision:
>
> $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c1070f0 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c1070f0 begin
> 0x7ffe7c1070f0 end
> 0x7ffe7c1070f0 destructed
>
> with moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107110 move constructed
> 0x7ffe7c107150 destructed
> 0x7ffe7c107110 begin const
> 0x7ffe7c107110 end const
> 0x7ffe7c107110 destructed
>
> with returning const:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107130 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107130 begin const
> 0x7ffe7c107130 end const
> 0x7ffe7c107130 destructed
>
> with recommended way:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107150 begin const
> 0x7ffe7c107150 end const
> 0x7ffe7c107150 destructed
> $
>
> What I find surprising here is that with the -fno-elide-constructors
> flag, in the "with returning const", the move constructor *is* called.
>
> Didn't we just say it wouldn't, because the const rvalue wouldn't bind
> to the non-const rvalue reference?
>
> I'm a little confused :p
>
> Elvis
>
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > Software Architect - Intel Open Source Technology Center
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
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. You'll pay
> the cost of two reference counts (one up and one down).
Though hmm, even if we'd lose move-construction, for the copy we'd get
instead, wouldn't copy elision kick in and elide it? So we wouldn't
have to pay for the ref count up/down?
I simplified my example a little, so to recap:
$ cat copytest.cpp
#include
#include
struct Foo {
Foo() {
std::cout << this << " constructed" << std::endl;
}
Foo(const Foo &) {
std::cout << this << " copy constructed" << std::endl;
}
Foo(Foo &&) {
std::cout << this << " move constructed" << std::endl;
}
~Foo() {
std::cout << this << " destructed" << std::endl;
}
std::vector::iterator begin() {
std::cout << this << " begin" << std::endl; return v.begin();
};
std::vector::const_iterator begin() const {
std::cout << this << " begin const" << std::endl; return v.begin();
};
std::vector::iterator end() {
std::cout << this << " end" << std::endl; return v.end();
};
std::vector::const_iterator end() const {
std::cout << this << " end const" << std::endl; return v.end();
};
std::vector v{1, 2, 3};
};
Foo f() {
Foo foo;
return foo;
}
const Foo constF() {
Foo foo;
return foo;
}
template
const T moveToConst(T &)
{
return std::move(t);
}
int main(void) {
std::cout << "without moveToConst:" << std::endl;
for (auto v : f()) { }
std::cout << std::endl;
std::cout << "with moveToConst:" << std::endl;
for (auto v : moveToConst(f())) { }
std::cout << std::endl;
std::cout << "with returning const:" << std::endl;
for (auto v : constF()) { }
std::cout << std::endl;
std::cout << "with recommended way:" << std::endl;
const auto stuff = f();
for (auto v : stuff) { }
return 0;
}
Result:
$ g++ -std=c++17 -O0 -o copytest copytest.cpp
$ ./copytest
without moveToConst:
0x7ffcc6ac76b0 constructed
0x7ffcc6ac76b0 begin
0x7ffcc6ac76b0 end
0x7ffcc6ac76b0 destructed
with moveToConst:
0x7ffcc6ac7710 constructed
0x7ffcc6ac76d0 move constructed
0x7ffcc6ac7710 destructed
0x7ffcc6ac76d0 begin const
0x7ffcc6ac76d0 end const
0x7ffcc6ac76d0 destructed
with returning const:
0x7ffcc6ac76f0 constructed
0x7ffcc6ac76f0 begin const
0x7ffcc6ac76f0 end const
0x7ffcc6ac76f0 destructed
with recommended way:
0x7ffcc6ac7710 constructed
0x7ffcc6ac7710 begin const
0x7ffcc6ac7710 end const
0x7ffcc6ac7710 destructed
So it looks like the copy has been elided also in the "with returning
const" case. Anyone know if this is guaranteed in C++17, or just
permitted?
If I compile with -fno-elide-constructors to disable elision:
$ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
$ ./copytest
without moveToConst:
0x7ffe7c107070 constructed
0x7ffe7c1070f0 move constructed
0x7ffe7c107070 destructed
0x7ffe7c1070f0 begin
0x7ffe7c1070f0 end
0x7ffe7c1070f0 destructed
with moveToConst:
0x7ffe7c107070 constructed
0x7ffe7c107150 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107110 move constructed
0x7ffe7c107150 destructed
0x7ffe7c107110 begin const
0x7ffe7c107110 end const
0x7ffe7c107110 destructed
with returning const:
0x7ffe7c107070 constructed
0x7ffe7c107130 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107130 begin const
0x7ffe7c107130 end const
0x7ffe7c107130 destructed
with recommended way:
0x7ffe7c107070 constructed
0x7ffe7c107150 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107150 begin const
0x7ffe7c107150 end const
0x7ffe7c107150 destructed
$
What I find surprising here is that with the -fno-elide-constructors
flag, in the "with returning const", the move constructor *is* called.
Didn't we just say it wouldn't, because the const rvalue wouldn't bind
to the non-const rvalue reference?
I'm a little confused :p
Elvis
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
>Oh, it is going to end in A resolution, it may not end the way the offended >party >may feel just, but that's true also for the proposed text. HA! You are not Konstantin Shegunov! A software engineer would imediately see that your 3 step CoC might not terminate. You are an imposter! >imagine that the abusive party is an employee of the QtC and has committed >heinous acts against a community member. You can't immediately jump to the worst case scenario to discredit the code of conduct. In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. From: Konstantin Shegunov Sent: Saturday, October 27, 2018 9:04:12 PM To: Martin Smith Cc: development@qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 4:56 PM Martin Smith mailto:martin.sm...@qt.io>> 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 true also for the proposed text. But that isn't the implication. Then I apologize, this is how I interpreted it. The implication is that a mistreated person can take the actions you have specified, and the result can be that the mistreatment, real or not, is not resolved. The proposed text can't guarantee resolution either (see below for a reductio ad absurdum). Active contributors who abuse others should be treated the same as inactive contributors who abuse others. What would be done would of course depend on what the abuser did. I suppose the abuser (active contributor or not) would be informed as to what he/she did wrong and would be told to stop doing it. 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 humor me for a second. As QtC employees' main work is on the Qt project, i.e. writing patches, committing features, writing docs and such, how would is this proposed committee to enforce the CoC? Are they going to plead that the person is taken out of the project, and wouldn't that mean that, basically, he/she can't be an employee for the QtC anymore? And to drive it home, say the head troll had a mental breakdown or something what is the committee to do? Take over the QtC? Just as I said before, I'm not against a CoC in principle. I'm against the CC's text which is quite invasive and badly written. To me KDE's CoC is much more practical in the case of the Qt project. Exactly. Without a CoC, we have no laws, so the implication is we don't consider any behavior an offense. Laws are bit more complicated than a statement of how people *should* behave. There's also separation of power, mandates, enforcement and laws that control how laws are made. Also there's hierarchy between the laws themselves in case they are in conflict. I suggest we don't venture into that. It's not what binds us to this community to begin with. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
>I am not aware of a single country without laws. >Over here e.g. "insult" is an offense. First, most of us aren't in Germany and don't have the German legal system to protect us. But more to the point, A CoC need not be adequate to deal with actual crimes nor even violations of civil law, because, as you point out, every country has laws to deal with incidents that rise to that level. For dealing with these problems, our CoC can simply state that the committee will refer such incidents to the appropriate legal authority. The forums where our CoC is needed are like meetings, but they are online. Imagine a group of contributors attending a meeting in a room. Abusive behavior would not be allowed there, and it probably wouldn't happen anyway, because people generally remain civil in a face to face context. But the same set of behaviors that would not be allowed in that face to face meeting should not be allowed in our online interactions, whether synchronous in an actual online meeting or asynchronous via code reviews and email list discussions. And because we are online and spread all around the world, there is currently no way for us to stop and prevent abusive behavior.We need a formal procedure to enable that, and the CoC is that procedure. From: André Pönitz Sent: Saturday, October 27, 2018 8:37:12 PM To: Martin Smith Cc: Bernhard Lindner; development@qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct 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 an offense. > > Exactly. Without a CoC, we have no laws, so the implication > is we don't consider any behavior an offense. I am not aware of a single country without laws. Over here e.g. "insult" is an offense. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> The controversial discrimination protection sentences at least should be > carefully discussed. It's not some thing that we could accept as easy as > rewrite. Hi Alexey, I've just read the QUIP proposal and couldn't find any controversial sentences. Could you elaborate? Which points shall be discussed? On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov wrote: > > 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 the >> CoC does not rule TQtC employment and what other work there is inside that >> company. >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> community where your employer is asking you to do work, that is going to >> affect your employment. > > > I agree. However my argument was that the QtC being a major contributor to > the codebase is going to have to abide by the ruling of the proposed > committee, which is a significant commitment (and a major nitpick I admit). > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
