Re: [Development] QCS2016 Session Notes - QUIPs for Qt
+1 to this. First and foremost we're looking for a way to summarize and document the outcome of discussions and decisions made. That's what QUIPs are for. Arguing about whether gerrit is the perfect tool for reviewing QUIPs is besides the point. It is a tool that'll work better than email discussions (as we're also seeing in this thread), and it's a tool we all are using daily and that we know. And btw, it's being used for documentation changes and review as well. And I'd rather work with gerrit (with all it's deficiencies) than introduce yet another separate tool that doesn't fit into our workflow. Cheers, Lars On 21/11/16 21:11, "Development on behalf of André Pönitz" wrote: On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote: > Giuseppe D'Angelo: > >> I would also like to point out that, despite we have a repository, we > >> still don't have a tool for properly discussing the actual content of > >> QUIPs. > >> > >> * Gerrit does not work because comments cannot be threaded, they > >> don't stick to multiple reviews, and they can be ignored > >> * Email does not work (it may work for the overall direction, but not > >> for the in depth discussion) because a single message may cover > >> multiple discussion points, disrupting the threading, and > >> discussion points can get ignored (*) > > All of which plays into my desire to introduce you all to Critic [0] Guys, the idea of QUIPs was to *fix* a problem, namely the current inability to pinpoint results of mailing list discussion. This *is* a problem for the Project, as lazy consensus on the mailing list is *the* official decision making process in the Qt Governance model, but it works in practice rather accidentally, if at all. Discussions are observed to deteriorate, develop into completely unrelated discussions, and even if something appears like consensus or the discussion dies, it typically turns out that different people think differently about what the consensus actually was, and the discussion re-starts half a year later. You both nicely demonstrate that this problem exist, thank you for that, but beyond that this particular sub-discussion misses the point. QUIPs were not meant to require new or different tooling, and I still believe such will be needed. The rough idea is that a topic is presented as usual on the mailing list, and when someone, usually the original proponent, gets the feeling that the usual rounds of bike-shedding, trolling and name-calling is over, and the occasional sensible arguments all have been heard, writes up what appears like a potential consensus and puts that on Gerrit, where some review process commences. The only difference to a normal review process I'd like to see would be a *much* higher bar for approval, to ensure that QUIPs are really close to consensus and to ensure some consistency within the set of QUIPs. None of this requires new tools, certainly not the bootstrapping of the first QUIP. There's also nothing changing processes, so everybody will be free to continue to present his views on his favourite tools in the future, but for now I'd really like to get this here done. IMNSHO it boils down to the question: Does anybody have any fundamental problem with main idea of having documents summarizing the lazy consensus of certain mailing list discussions? If not I'd call that a lazy consensus and would ask to proceed with reviewing the final wording on Gerrit. Andre' ___ 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] QCS2016 Session Notes - QUIPs for Qt
> On 21 Nov 2016, at 21:11, André Pönitz wrote: > > QUIPs were not meant to require new or different tooling, and I still > believe such will be needed. Me too. See? we have consensus. ;-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On November 21, 2016 20:02:54 André Pönitz wrote: > On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote: >> Giuseppe D'Angelo: >> >> I would also like to point out that, despite we have a repository, we >> >> still don't have a tool for properly discussing the actual content of >> >> QUIPs. >> >> >> >> * Gerrit does not work because comments cannot be threaded, they >> >> don't stick to multiple reviews, and they can be ignored >> >> * Email does not work (it may work for the overall direction, but not >> >> for the in depth discussion) because a single message may cover >> >> multiple discussion points, disrupting the threading, and >> >> discussion points can get ignored (*) >> >> All of which plays into my desire to introduce you all to Critic [0] > > Guys, > > the idea of QUIPs was to *fix* a problem, namely the current inability > to pinpoint results of mailing list discussion. This *is* a problem for > the Project, as lazy consensus on the mailing list is *the* official > decision making process in the Qt Governance model, but it works in > practice rather accidentally, if at all. > > Discussions are observed to deteriorate, develop into completely > unrelated discussions, and even if something appears like consensus or > the discussion dies, it typically turns out that different people think > differently about what the consensus actually was, and the discussion > re-starts half a year later. > > You both nicely demonstrate that this problem exist, thank you for that, > but beyond that this particular sub-discussion misses the point. > QUIPs were not meant to require new or different tooling, and I still > believe such will be needed. > > The rough idea is that a topic is presented as usual on the mailing > list, and when someone, usually the original proponent, gets the feeling > that the usual rounds of bike-shedding, trolling and name-calling is > over, and the occasional sensible arguments all have been heard, writes > up what appears like a potential consensus and puts that on Gerrit, > where some review process commences. > > The only difference to a normal review process I'd like to see would be > a *much* higher bar for approval, to ensure that QUIPs are really close > to consensus and to ensure some consistency within the set of QUIPs. > > None of this requires new tools, certainly not the bootstrapping of > the first QUIP. There's also nothing changing processes, so everybody > will be free to continue to present his views on his favourite tools > in the future, but for now I'd really like to get this here done. > > IMNSHO it boils down to the question: Does anybody have any fundamental > problem with main idea of having documents summarizing the lazy consensus > of certain mailing list discussions? If not I'd call that a lazy > consensus and would ask to proceed with reviewing the final wording > on Gerrit. > I think it's modeled after Python PEP and RFCs? Do we have a first QUIP who is describing the process? I think we should copy a successful model like https://www.python.org/dev/peps/pep-0001/ and don't try to be smarter. And yes, I don't think document a random email conversation is the answer. > Andre' > > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
On Mon, Nov 21, 2016 at 03:29:01PM +0300, Konstantin Tokarev wrote: > > > 21.11.2016, 15:26, "Giuseppe D'Angelo" : > > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen > > wrote: > >>> Any idea to how to actually make this work? > >> how about taking the existing processes seriously and exercising social > >> pressure on those who think they are above them? > > > > May I just say that prefer a tool that mandates a workflow over using > > political and social pressures, which in the long term hurt the > > project? > > Well, tools cannot help with social issues, and ignoring review comments is > more like the latter. Well, right, and wrong, kind of ;-) I think tools can help to *prevent* social issues. As example, I think it easier for people to accept a -1 from the Sanity Bot than to accept exactly the same comment from a human reviewer, specifically when it comes to arbitrary choices like prefering American over British spelling in comments. With the bot I usually just swallow and "fix" the issue, no matter how insane it appears to me. Sounds irrational? It is. It is human. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote: > Giuseppe D'Angelo: > >> I would also like to point out that, despite we have a repository, we > >> still don't have a tool for properly discussing the actual content of > >> QUIPs. > >> > >> * Gerrit does not work because comments cannot be threaded, they > >> don't stick to multiple reviews, and they can be ignored > >> * Email does not work (it may work for the overall direction, but not > >> for the in depth discussion) because a single message may cover > >> multiple discussion points, disrupting the threading, and > >> discussion points can get ignored (*) > > All of which plays into my desire to introduce you all to Critic [0] Guys, the idea of QUIPs was to *fix* a problem, namely the current inability to pinpoint results of mailing list discussion. This *is* a problem for the Project, as lazy consensus on the mailing list is *the* official decision making process in the Qt Governance model, but it works in practice rather accidentally, if at all. Discussions are observed to deteriorate, develop into completely unrelated discussions, and even if something appears like consensus or the discussion dies, it typically turns out that different people think differently about what the consensus actually was, and the discussion re-starts half a year later. You both nicely demonstrate that this problem exist, thank you for that, but beyond that this particular sub-discussion misses the point. QUIPs were not meant to require new or different tooling, and I still believe such will be needed. The rough idea is that a topic is presented as usual on the mailing list, and when someone, usually the original proponent, gets the feeling that the usual rounds of bike-shedding, trolling and name-calling is over, and the occasional sensible arguments all have been heard, writes up what appears like a potential consensus and puts that on Gerrit, where some review process commences. The only difference to a normal review process I'd like to see would be a *much* higher bar for approval, to ensure that QUIPs are really close to consensus and to ensure some consistency within the set of QUIPs. None of this requires new tools, certainly not the bootstrapping of the first QUIP. There's also nothing changing processes, so everybody will be free to continue to present his views on his favourite tools in the future, but for now I'd really like to get this here done. IMNSHO it boils down to the question: Does anybody have any fundamental problem with main idea of having documents summarizing the lazy consensus of certain mailing list discussions? If not I'd call that a lazy consensus and would ask to proceed with reviewing the final wording on Gerrit. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On November 21, 2016 14:29:10 Shawn Rutledge wrote: > >> On 21 Nov 2016, at 12:06, Edward Welbourne wrote: >> >> Giuseppe D'Angelo: I would also like to point out that, despite we have a repository, we still don't have a tool for properly discussing the actual content of QUIPs. * Gerrit does not work because comments cannot be threaded, they don't stick to multiple reviews, and they can be ignored >> >> [0] https://github.com/jensl/critic >> >> I would dearly love to replace Gerrit with it - I realise that's hoping >> for too much - but, for a new repository on which Gerrit isn't adequate, >> maybe we could consider it … > > Maybe it’s worth a try. But someone has to install it on a server so that we > can try it, right? Is that easy enough? Yes, some server for evaluation would be nice. > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
> On 21 Nov 2016, at 12:06, Edward Welbourne wrote: > > Giuseppe D'Angelo: >>> I would also like to point out that, despite we have a repository, we >>> still don't have a tool for properly discussing the actual content of >>> QUIPs. >>> >>> * Gerrit does not work because comments cannot be threaded, they >>> don't stick to multiple reviews, and they can be ignored > > [0] https://github.com/jensl/critic > > I would dearly love to replace Gerrit with it - I realise that's hoping > for too much - but, for a new repository on which Gerrit isn't adequate, > maybe we could consider it … Maybe it’s worth a try. But someone has to install it on a server so that we can try it, right? Is that easy enough? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On November 21, 2016 13:51:10 Oswald Buddenhagen wrote: > On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote: >> On November 21, 2016 12:58:59 Oswald Buddenhagen >> wrote: >> > how about taking the existing processes seriously and exercising social >> > pressure on those who think they are above them? >> >> Sorry, not everybody likes to use social pressure (mobbing). >> > the thing is that there there is no tooling which is absolutely > foolproof. people will always come up with creative ways to > circumvent it, and the only way to deal with that is showing them that > doing so is not acceptable. it's a bit of a stretch to call that > mobbing, and i gladly laugh it off when it happens. But you see that a tool who makes it easy to snippet on some argument is maybe more suboptimal than other. It's not about using the perfect tool but using one which is better. Ones that sets 'loud' people at a disadvantage. And it's not only the tool, it's the culture too. A culture which is appreciating new arguments and not loves to repeat arguments again and again, especially to hide some private agenda. If an argumentation is more about individual agendas and less about the common good it is doomed. Especially if people try to sell the first as last. The tool should help to make that transparent but it is only one building stone. > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote: > On November 21, 2016 12:58:59 Oswald Buddenhagen > wrote: > > how about taking the existing processes seriously and exercising social > > pressure on those who think they are above them? > > Sorry, not everybody likes to use social pressure (mobbing). > the thing is that there there is no tooling which is absolutely foolproof. people will always come up with creative ways to circumvent it, and the only way to deal with that is showing them that doing so is not acceptable. it's a bit of a stretch to call that mobbing, and i gladly laugh it off when it happens. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On November 21, 2016 12:58:59 Oswald Buddenhagen wrote: > On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote: >> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen >> wrote: >> > the repository has been created. >> >> I would also like to point out that, despite we have a repository, we >> still don't have a tool for properly discussing the actual content of >> QUIPs. >> >> * Gerrit does not work because comments cannot be threaded, >> > when you use inline comments, the locality is good enough to > make threading generally unnecessary. > >> they don't stick to multiple reviews, >> > this is true, but becomes a real problem only if the change owner > doesn't bother handling all comments before pushing new changesets. > >> and they can be ignored >> > that's correct, and having real issue tracking would be advantageous > (which gerrit upstream knows very well). > otoh, it's the responsibility of the reviewers and the submitter (a role > we have intentionally restricted in this repo, mind you) to verify that > all comments have been (actually) acted upon. > >> Any idea to how to actually make this work? >> > how about taking the existing processes seriously and exercising social > pressure on those who think they are above them? Sorry, not everybody likes to use social pressure (mobbing). And could it be that the outcome of the argumentation is be quite different of what we would describe as good in the long run. My impression is generally that many smart people don't like too spend their time for that games. But people who thinks that their arguments are smarter think that they deserve to be chosen. Or let our describe it that way, the rationality of people is quite limited and you need a good framework to get a better outcome. You can easily derail cooperation with a dysfunctional framework. Is shown in many experiments and believe me, we are not different. Actually people who working in IT have more trouble because they often describe the world not as contingent but as based on a all-time, universal fundament (truth). So it's hard to compromise because that would be deviate from truth. If the discussion is based on experience it is actually quite positive to compromise because all arguments together give a bigger picture, based on much more experience. So the truth based world description leds to few 'specialists' discuss that matter but the latter is a cooperation of all people with experience about that matter. Neither is guaranteed to succeed but if you get the last in a cooperative mode you have a good chance. > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
21.11.2016, 15:26, "Giuseppe D'Angelo" : > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen > wrote: >>> Any idea to how to actually make this work? >> how about taking the existing processes seriously and exercising social >> pressure on those who think they are above them? > > May I just say that prefer a tool that mandates a workflow over using > political and social pressures, which in the long term hurt the > project? Well, tools cannot help with social issues, and ignoring review comments is more like the latter. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen wrote: >> Any idea to how to actually make this work? >> > how about taking the existing processes seriously and exercising social > pressure on those who think they are above them? May I just say that prefer a tool that mandates a workflow over using political and social pressures, which in the long term hurt the project? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote: > On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen > wrote: > > the repository has been created. > > I would also like to point out that, despite we have a repository, we > still don't have a tool for properly discussing the actual content of > QUIPs. > > * Gerrit does not work because comments cannot be threaded, > when you use inline comments, the locality is good enough to make threading generally unnecessary. > they don't stick to multiple reviews, > this is true, but becomes a real problem only if the change owner doesn't bother handling all comments before pushing new changesets. > and they can be ignored > that's correct, and having real issue tracking would be advantageous (which gerrit upstream knows very well). otoh, it's the responsibility of the reviewers and the submitter (a role we have intentionally restricted in this repo, mind you) to verify that all comments have been (actually) acted upon. > Any idea to how to actually make this work? > how about taking the existing processes seriously and exercising social pressure on those who think they are above them? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Giuseppe D'Angelo: >> I would also like to point out that, despite we have a repository, we >> still don't have a tool for properly discussing the actual content of >> QUIPs. >> >> * Gerrit does not work because comments cannot be threaded, they >> don't stick to multiple reviews, and they can be ignored >> * Email does not work (it may work for the overall direction, but not >> for the in depth discussion) because a single message may cover >> multiple discussion points, disrupting the threading, and >> discussion points can get ignored (*) All of which plays into my desire to introduce you all to Critic [0], a code-review tool my former colleague Jens wrote at Opera. It knows how to carry comments forward from one patch set to another, even through rebases (within limits), it knows the range of lines a comment relates to, it distinguishes issues (which must be resolved) from comments (which can be discussed). Discussions on a particular issue are linear - i.e. forking off side-threads to separately discuss different parts of a comment or follow-up would need to be implemented. It handles whole branches, making it possible to review a set of related changes together; the reviewer can chose whether to review all changes to a file together or each commit's changes separately; it helps keep track of what you have reviewed so that you can tell when you're done. [0] https://github.com/jensl/critic I would dearly love to replace Gerrit with it - I realise that's hoping for too much - but, for a new repository on which Gerrit isn't adequate, maybe we could consider it ... Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Sunday 20 November 2016 20:29:01 Giuseppe D'Angelo wrote: > On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira > > wrote: > > Can you remember the list of C++11 features we're allowed to use? We had > > a discussion on the mailing list. > > Going back to this particular point: so should this list go into the > QUIPs repository, or in qtbase? (The idea of putting it in qtbase was > to re-use the same branching scheme, so for a given branch you can > know which features you are allowed to use). IMHO, we need a QUIP that says where in each Qt module such a file should be located, what its format is, what the process is to update it, whether it should be machine-readable (read: run from configure checks), etc. Neither the wiki, nor the QUIP itself is the place to put the actual lists. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Sun, Nov 20, 2016 at 9:13 PM, Marco Bubke wrote: > Do you think about a wiki where you can comment? I think you want something > with the capability to describe, comment, argument and poll with a version > history. Like you described email is a terrible tool for it. If a wiki allows for all of this, then sure, let's use a wiki. Does MediaWiki support these features? I've got the impression that discussion pages are totally independent from the "main" page. The threading must be somehow manually managed and I don't think there's a way to mark some argumentative point as "this requires a resolution". (Maybe the right tool does not exist, but we'll need to settle for using an existing one "in the right way") Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On November 20, 2016 20:39:08 Giuseppe D'Angelo wrote: > On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen > wrote: >> the repository has been created. > > I would also like to point out that, despite we have a repository, we > still don't have a tool for properly discussing the actual content of > QUIPs. > > * Gerrit does not work because comments cannot be threaded, they don't > stick to multiple reviews, and they can be ignored > * Email does not work (it may work for the overall direction, but not > for the in depth discussion) because a single message may cover > multiple discussion points, disrupting the threading, and discussion > points can get ignored (*) > > Any idea to how to actually make this work? Try reviewboard maybe? > > My 2 cents, > -- > Giuseppe D'Angelo > > > (*) This still happens all the time. User A proposes something; user B > replies with "I don't think it works in scenarios X, Y, Z"; user A > counter-replies "but Z is not a scenario we consider" and the > discussion derails about Z. Noone talks about X and Y, which instead > *must* be talked about, for the proposal to be accepted. We need > something that makes it impossible to ignore the comment about X and > Y. Do you think about a wiki where you can comment? I think you want something with the capability to describe, comment, argument and poll with a version history. Like you described email is a terrible tool for it. > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen wrote: > the repository has been created. I would also like to point out that, despite we have a repository, we still don't have a tool for properly discussing the actual content of QUIPs. * Gerrit does not work because comments cannot be threaded, they don't stick to multiple reviews, and they can be ignored * Email does not work (it may work for the overall direction, but not for the in depth discussion) because a single message may cover multiple discussion points, disrupting the threading, and discussion points can get ignored (*) Any idea to how to actually make this work? Try reviewboard maybe? My 2 cents, -- Giuseppe D'Angelo (*) This still happens all the time. User A proposes something; user B replies with "I don't think it works in scenarios X, Y, Z"; user A counter-replies "but Z is not a scenario we consider" and the discussion derails about Z. Noone talks about X and Y, which instead *must* be talked about, for the proposal to be accepted. We need something that makes it impossible to ignore the comment about X and Y. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira wrote: > > Can you remember the list of C++11 features we're allowed to use? We had a > discussion on the mailing list. Going back to this particular point: so should this list go into the QUIPs repository, or in qtbase? (The idea of putting it in qtbase was to re-use the same branching scheme, so for a given branch you can know which features you are allowed to use). Thanks, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On 10/11/16 14:21, "Development on behalf of Jędrzej Nowacki" wrote: On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote: > the easiest would be going with the normal approval rights, but limit > the submit button to a "QUIP owners" group which would consist of lars > (and possibly a _few_ deputies). Considering expected traffic there it could be only Lars :-) Let's do it that way for now. We can always nominate additional QUIP owners later on if we think it's required. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote: > the easiest would be going with the normal approval rights, but limit > the submit button to a "QUIP owners" group which would consist of lars > (and possibly a _few_ deputies). Considering expected traffic there it could be only Lars :-) Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Wed, Nov 09, 2016 at 06:49:08PM +, Edward Welbourne wrote: > > Agree with meta/quips > > +1, > the repository has been created. next point: permissions. i don't think the regular ones are appropriate - they are way too anarchic for a process that is supposed to reflect *actual* community consensus. the easiest would be going with the normal approval rights, but limit the submit button to a "QUIP owners" group which would consist of lars (and possibly a _few_ deputies). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> Agree with meta/quips +1, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Agree with meta/quips > On Nov 9, 2016, at 10:11 AM, Louai Al-Khanji wrote: > > As far as I am concerned meta/quips will do just fine. It’s not worth a > bikeshed. > > Cheers, > Louai > > On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" > kai.koe...@qt.io> wrote: > > > >> -Original Message- >> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- >> project.org] On Behalf Of Oswald Buddenhagen >> Sent: Wednesday, November 09, 2016 4:01 PM >> To: development@qt-project.org >> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt >> >> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: >>> +1 for qt/quips, I don't think of it as a web site thing either. >>> >> well, i don't want it in qt/ - this is not a generic namespace for stuff that >> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git >> (with an accurate status field), or be a submodule of an aggregated module. >> >> i can offer meta/ as an alternative. > >meta/quips would work for me, too. or qt-project/quips? > >> or maybe qtqt/ - that one already exists, but i suspect the objections will >> be >> the same as to www/. > >No idea what qtqt/ should stand for :) > >>> Kai Koehne wrote: >>>> I'd slightly prefer >>>> >>>> qt/quips >>>> >>>> because it's not directly related to the website, even if we'll >>>> generate an html presentation out of it. We might even consider >>>> adding it to qt/qt5.git at one point ... >>> >> that makes no sense to me at all. the scope if this is certainly wider than >> the >> qt product itself. > >Why do you think so? This is the repository where we want to document > processes >and design decisions for Qt, the project _and_ the product. It's surely > more meta than >most of the modules, but we've also projects like qt/qtqa and > qt/qtrepotools, which >do not contain a qt module, either. > >Regards > >Kai >___ >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 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
As far as I am concerned meta/quips will do just fine. It’s not worth a bikeshed. Cheers, Louai On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" wrote: > -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, November 09, 2016 4:01 PM > To: development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > > +1 for qt/quips, I don't think of it as a web site thing either. > > > well, i don't want it in qt/ - this is not a generic namespace for stuff that > doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git > (with an accurate status field), or be a submodule of an aggregated module. > > i can offer meta/ as an alternative. meta/quips would work for me, too. or qt-project/quips? > or maybe qtqt/ - that one already exists, but i suspect the objections will be > the same as to www/. No idea what qtqt/ should stand for :) > > Kai Koehne wrote: > > > I'd slightly prefer > > > > > > qt/quips > > > > > > because it's not directly related to the website, even if we'll > > > generate an html presentation out of it. We might even consider > > > adding it to qt/qt5.git at one point ... > > > that makes no sense to me at all. the scope if this is certainly wider than the > qt product itself. Why do you think so? This is the repository where we want to document processes and design decisions for Qt, the project _and_ the product. It's surely more meta than most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, which do not contain a qt module, either. Regards Kai ___ 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] QCS2016 Session Notes - QUIPs for Qt
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, November 09, 2016 4:01 PM > To: development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > > +1 for qt/quips, I don't think of it as a web site thing either. > > > well, i don't want it in qt/ - this is not a generic namespace for stuff that > doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git > (with an accurate status field), or be a submodule of an aggregated module. > > i can offer meta/ as an alternative. meta/quips would work for me, too. or qt-project/quips? > or maybe qtqt/ - that one already exists, but i suspect the objections will be > the same as to www/. No idea what qtqt/ should stand for :) > > Kai Koehne wrote: > > > I'd slightly prefer > > > > > > qt/quips > > > > > > because it's not directly related to the website, even if we'll > > > generate an html presentation out of it. We might even consider > > > adding it to qt/qt5.git at one point ... > > > that makes no sense to me at all. the scope if this is certainly wider than > the > qt product itself. Why do you think so? This is the repository where we want to document processes and design decisions for Qt, the project _and_ the product. It's surely more meta than most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, which do not contain a qt module, either. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On 11/09/16 16:01, Oswald Buddenhagen wrote: > > i can offer meta/ as an alternative. +1 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > +1 for qt/quips, I don't think of it as a web site thing either. > well, i don't want it in qt/ - this is not a generic namespace for stuff that doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git (with an accurate status field), or be a submodule of an aggregated module. i can offer meta/ as an alternative. or maybe qtqt/ - that one already exists, but i suspect the objections will be the same as to www/. > Kai Koehne wrote: > > I'd slightly prefer > > > > qt/quips > > > > because it's not directly related to the website, even if we'll generate an > > html presentation out of it. We might even consider adding it to qt/qt5.git > > at > > one point ... > that makes no sense to me at all. the scope if this is certainly wider than the qt product itself. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
+1 for qt/quips, I don't think of it as a web site thing either. -Louai _ From: Kai Koehne mailto:kai.koe...@qt.io>> Sent: Tuesday, November 8, 2016 3:48 AM Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt To: Oswald Buddenhagen mailto:oswald.buddenha...@qt.io>>, mailto:development@qt-project.org>> > -Original Message- > From: Development > [mailto:development-bounces+kai.koehne=qt.io<http://qt.io>@qt- > project.org<http://project.org>] On Behalf Of Oswald Buddenhagen > Sent: Tuesday, November 08, 2016 11:15 AM > To: development@qt-project.org<mailto:development@qt-project.org> > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote: > > Yes, let's get the repo created and this whole thing off the ground. > > > so, anyone has a concrete proposal for a fully qualified repository name? > www/quips? I'd slightly prefer qt/quips because it's not directly related to the website, even if we'll generate an html presentation out of it. We might even consider adding it to qt/qt5.git at one point ... Kai ___ Development mailing list Development@qt-project.org<mailto: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] QCS2016 Session Notes - QUIPs for Qt
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Tuesday, November 08, 2016 11:15 AM > To: development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote: > > Yes, let’s get the repo created and this whole thing off the ground. > > > so, anyone has a concrete proposal for a fully qualified repository name? > www/quips? I'd slightly prefer qt/quips because it's not directly related to the website, even if we'll generate an html presentation out of it. We might even consider adding it to qt/qt5.git at one point ... Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote: > Yes, let’s get the repo created and this whole thing off the ground. > so, anyone has a concrete proposal for a fully qualified repository name? www/quips? > As noted, we need a better way to document results of discussions, decisions > and processes. Grepping through a mailing list archive and trying to figure > out which opinion prevailed in the end is not that ;-) > > Cheers, > Lars > > On 08/11/16 09:41, "Development on behalf of Edward Welbourne" > edward.welbou...@qt.io> wrote: > > Louai Al-Khanji said: > > this is not a bureaucratization process. > > It is about having a way to document the final conclusions of > discussions we already have. In the process, it shall also force us to > be explicit and leave fewer dangling ambiguities, where different > parties have subtly different interpretations, because the final QUIP > shall be one document, rather than a scattered mess of correspondence > spread across several months of a mailing list archive, with references > back to earlier discussions relating to similar topics. Newcomers shall > only have one place to look to get up to speed. > > (I should note, though, that this *is* a bureaucratization process; it's > just that it's *the good kind* - yes, those do exist. Bureaucracy may > have spawned some heinous and easily-noticed messes; but it's actually a > technology - an information technology, no less - that helped > revolutionise the way the world was run (roughly a quarter millennium > ago) and usher in the modern era.) > > I'll third the motion that we should start a repo for QUIPs, > > Eddy. > ___ > 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] QCS2016 Session Notes - QUIPs for Qt
Yes, let’s get the repo created and this whole thing off the ground. As noted, we need a better way to document results of discussions, decisions and processes. Grepping through a mailing list archive and trying to figure out which opinion prevailed in the end is not that ;-) Cheers, Lars On 08/11/16 09:41, "Development on behalf of Edward Welbourne" wrote: Louai Al-Khanji said: > this is not a bureaucratization process. It is about having a way to document the final conclusions of discussions we already have. In the process, it shall also force us to be explicit and leave fewer dangling ambiguities, where different parties have subtly different interpretations, because the final QUIP shall be one document, rather than a scattered mess of correspondence spread across several months of a mailing list archive, with references back to earlier discussions relating to similar topics. Newcomers shall only have one place to look to get up to speed. (I should note, though, that this *is* a bureaucratization process; it's just that it's *the good kind* - yes, those do exist. Bureaucracy may have spawned some heinous and easily-noticed messes; but it's actually a technology - an information technology, no less - that helped revolutionise the way the world was run (roughly a quarter millennium ago) and usher in the modern era.) I'll third the motion that we should start a repo for QUIPs, Eddy. ___ 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] QCS2016 Session Notes - QUIPs for Qt
Louai Al-Khanji said: > this is not a bureaucratization process. It is about having a way to document the final conclusions of discussions we already have. In the process, it shall also force us to be explicit and leave fewer dangling ambiguities, where different parties have subtly different interpretations, because the final QUIP shall be one document, rather than a scattered mess of correspondence spread across several months of a mailing list archive, with references back to earlier discussions relating to similar topics. Newcomers shall only have one place to look to get up to speed. (I should note, though, that this *is* a bureaucratization process; it's just that it's *the good kind* - yes, those do exist. Bureaucracy may have spawned some heinous and easily-noticed messes; but it's actually a technology - an information technology, no less - that helped revolutionise the way the world was run (roughly a quarter millennium ago) and usher in the modern era.) I'll third the motion that we should start a repo for QUIPs, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, Indeed, we are. My fault, sorry. I second the request for a git repository. I have a preliminary set of scripts that I used to generate the preview site. Those are ready to go, along with the initial QUIPs I sent out. I would like to suggest that we use that to seed the repository. There has been interest in writing other QUIPs already, those can then follow immediately. André, to answer your question once more – this is not a bureaucratization process. It’s not really about new features either. Instead, the intent is to gather in a well-defined and maintained place information that we, the community of Qt contributors, have produced. For instance, this could be some process that we have agreed upon, or a technical study that was done before some large component was refactored, just to give two examples. Currently we often have to refer to e-mail conversations which might or might not be archived, aren’t discoverable, and are difficult to search for. If we’re lucky it’s in a wiki, but looking at the number of wikis that we’ve gone through in recent years, and information lost in them, it’s easy to see that it’s not a very stable format. If you don’t feel that any of this applies to you, then you will likely never have to think about it. At least, not produce any QUIP yourself – maybe you will over time find some of them useful to read, however. Does that address your concerns? I would like to fold this question into the next revision of the initial QUIPs. :-) Cheers, Louai On 10/26/16, 11:50 PM, "Kai Koehne" wrote: Hi, I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories. Anyhow, it seems to me that we're stuck currently in the bootstrapping process of QUIPs: http://quips-qt-io.herokuapp.com/quip-0003.html >The minimum QUIP boostrapping process was discussed: > >1. Post QUIP 1 to qt-development mailing list for discussion. >2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) >3. Create new git repository to hold QUIPs So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git . Regards Kai > -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Tero Kojo > Sent: Monday, September 26, 2016 9:01 AM > To: Louai Al-Khanji ; development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi, > > This initiative is much appreciated, thank you Louai! > Having been in the session at QtCon, I don't have any problems with the > proposed format and process as outlined in the initial QUIPS. > > I'd like to request two QUIP numbers "Qt Community Code of Conduct", and > another one for "Code of Conduct for Qt Events". > I guess the repo isn't there yet, do we wait on the lazy agreement process > until it is created? > > Tero > > > -Original Message- > > From: Development [mailto:development-bounces+tero.kojo=qt.io@qt- > > project.org] On Behalf Of Louai Al-Khanji > > Sent: tiistai 20. syyskuuta 2016 1.45 > > To: development@qt-project.org > > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > > > Hi all, > > > > Here are my notes from the QUIPs session. Thank you for your patience. > > :-) > > > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > > > QUIP 1 introduces the general concept: > > > > http://quips-qt-io.herokuapp.com/quip-0001.html > > > > QUIP 2 details the Qt governance model, it’s simply the current wiki > > page converted into a QUIP: > > > > http://quips-qt-io.herokuapp.com/quip-0002.html > > > > QUIP 3 is an informational QUIP containing the session notes, which > > are repeated below: > > > > http://quips-qt-io.herokuapp.com/quip-0003.html > > > > The heroku domain is obviously a placeholder. > > > > I have also attached the source files for proposed QUIPs 1, 2, and 3 > > to this e- mail. > > > > One item left open was licensing of the QUIPs themselves. For these I > > propose Creative Commons CC0. > > > > Any and all feedback welcome. > > > > Cheers, > > Louai > > > > BEGIN NOTES > > > > At the Qt Contributor
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories. Anyhow, it seems to me that we're stuck currently in the bootstrapping process of QUIPs: http://quips-qt-io.herokuapp.com/quip-0003.html >The minimum QUIP boostrapping process was discussed: > >1. Post QUIP 1 to qt-development mailing list for discussion. >2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has >since been made available) >3. Create new git repository to hold QUIPs So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git . Regards Kai > -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Tero Kojo > Sent: Monday, September 26, 2016 9:01 AM > To: Louai Al-Khanji ; development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi, > > This initiative is much appreciated, thank you Louai! > Having been in the session at QtCon, I don't have any problems with the > proposed format and process as outlined in the initial QUIPS. > > I'd like to request two QUIP numbers "Qt Community Code of Conduct", and > another one for "Code of Conduct for Qt Events". > I guess the repo isn't there yet, do we wait on the lazy agreement process > until it is created? > > Tero > > > -Original Message- > > From: Development [mailto:development-bounces+tero.kojo=qt.io@qt- > > project.org] On Behalf Of Louai Al-Khanji > > Sent: tiistai 20. syyskuuta 2016 1.45 > > To: development@qt-project.org > > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > > > Hi all, > > > > Here are my notes from the QUIPs session. Thank you for your patience. > > :-) > > > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > > > QUIP 1 introduces the general concept: > > > > http://quips-qt-io.herokuapp.com/quip-0001.html > > > > QUIP 2 details the Qt governance model, it’s simply the current wiki > > page converted into a QUIP: > > > > http://quips-qt-io.herokuapp.com/quip-0002.html > > > > QUIP 3 is an informational QUIP containing the session notes, which > > are repeated below: > > > > http://quips-qt-io.herokuapp.com/quip-0003.html > > > > The heroku domain is obviously a placeholder. > > > > I have also attached the source files for proposed QUIPs 1, 2, and 3 > > to this e- mail. > > > > One item left open was licensing of the QUIPs themselves. For these I > > propose Creative Commons CC0. > > > > Any and all feedback welcome. > > > > Cheers, > > Louai > > > > BEGIN NOTES > > > > At the Qt Contributors' Summit 2016 in Berlin a session was held to > > discuss the idea of introducing QUIPs as a new process for Qt governance. > > > > The general idea was introduced by looking at QUIPs 1 and 2, and by > > looking at some Python PEPs. The general feedback was positive. An > > attempt was made to identify the minimum set of work required to > > bootstrap QUIP, which was the main theme of the session. > > > > The overall discussion is summarized below, in roughly chronological order. > > > > - Discussed background of QUIP, the process and the documents. > > Referred to > > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior > > to the > > session. > > > > - The idea is to have a new git repository with the QUIP text files > > > > - Managed through Qt's normal work flow, currently gerrit code > > review > > > > - The maintainer of the quips repository takes on required editorial > > duties > > - Agreed that the text documents should be limited to 80 character lines. > > > > - Agreed that care must be taken to ensure that QUIPs are written in > > "proper" > > English so as to be clear, understandable and concise. > > > > - Talked about how a new QUIP is introduced. The most important thing is > to > > reserve a number, which is the identifier of any one QUIP. The title can > > change, and is expected to do so from time to time. > > > > - New QUIP documents will go through a review process like any other > > patch to > > Qt. The author of the QUIP is responsible for logging this discussion in > > the > > evolving QUIP itself. > > > > - The important thing is to bootstrap the process. Once it is boots
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, This initiative is much appreciated, thank you Louai! Having been in the session at QtCon, I don't have any problems with the proposed format and process as outlined in the initial QUIPS. I'd like to request two QUIP numbers "Qt Community Code of Conduct", and another one for "Code of Conduct for Qt Events". I guess the repo isn't there yet, do we wait on the lazy agreement process until it is created? Tero > -Original Message- > From: Development [mailto:development-bounces+tero.kojo=qt.io@qt- > project.org] On Behalf Of Louai Al-Khanji > Sent: tiistai 20. syyskuuta 2016 1.45 > To: development@qt-project.org > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi all, > > Here are my notes from the QUIPs session. Thank you for your patience. :-) > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > QUIP 1 introduces the general concept: > > http://quips-qt-io.herokuapp.com/quip-0001.html > > QUIP 2 details the Qt governance model, it’s simply the current wiki page > converted into a QUIP: > > http://quips-qt-io.herokuapp.com/quip-0002.html > > QUIP 3 is an informational QUIP containing the session notes, which are > repeated below: > > http://quips-qt-io.herokuapp.com/quip-0003.html > > The heroku domain is obviously a placeholder. > > I have also attached the source files for proposed QUIPs 1, 2, and 3 to this > e- > mail. > > One item left open was licensing of the QUIPs themselves. For these I > propose Creative Commons CC0. > > Any and all feedback welcome. > > Cheers, > Louai > > BEGIN NOTES > > At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss > the idea of introducing QUIPs as a new process for Qt governance. > > The general idea was introduced by looking at QUIPs 1 and 2, and by looking > at some Python PEPs. The general feedback was positive. An attempt was > made to identify the minimum set of work required to bootstrap QUIP, > which was the main theme of the session. > > The overall discussion is summarized below, in roughly chronological order. > > - Discussed background of QUIP, the process and the documents. Referred > to > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to > the > session. > > - The idea is to have a new git repository with the QUIP text files > > - Managed through Qt's normal work flow, currently gerrit code review > > - The maintainer of the quips repository takes on required editorial duties > - Agreed that the text documents should be limited to 80 character lines. > > - Agreed that care must be taken to ensure that QUIPs are written in > "proper" > English so as to be clear, understandable and concise. > > - Talked about how a new QUIP is introduced. The most important thing is to > reserve a number, which is the identifier of any one QUIP. The title can > change, and is expected to do so from time to time. > > - New QUIP documents will go through a review process like any other patch > to > Qt. The author of the QUIP is responsible for logging this discussion in the > evolving QUIP itself. > > - The important thing is to bootstrap the process. Once it is bootstrapped, it > is possible to fine-tune the QUIP process through QUIPs. It is expected that > this will happen. > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough > overview of the different kinds of possible QUIPs. It is expected that the > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > - Like any other part of Qt, QUIPs are living documents. They can be updated, > amended or entirely superseded by later ones. > > - QUIP licensing was discussed. Python's PEPs are required to be either > placed > in the public domain or licensed under the Open Publication License. The > former is not possible in all jurisdictions and the latter has apparently > been superseded by the Creative Commons licenses the CC0 license was > suggested. > > - The minimum QUIP boostrapping process was discussed: > > 1. Post QUIP 1 to qt-development mailing list for discussion. > > 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io > has since been made available) > > 3. Create new git repository to hold QUIPs > > - The initial QUIP process was discussed: > > 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through > gerrit > > 2. The author gives notice of new QUIP by sending it to qt-development, > either
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
21.09.2016, 12:34, "Friedemann Kleint" : > Hi, > > technically speaking: is using the .rst format set in stone? I find this > difficult to handle; one needs a local web server to view it AFAIK. .md > comes to mind as alternative? Are you implying that you need local web server to view HTML? :) > > Regards, > Friedemann > > -- > Friedemann Kleint > The Qt Company GmbH > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On quarta-feira, 21 de setembro de 2016 11:34:02 PDT Friedemann Kleint wrote: > Hi, > > technically speaking: is using the .rst format set in stone? I find this > difficult to handle; one needs a local web server to view it AFAIK. .md > comes to mind as alternative? How is that different from .md? Don't you need a tool that converts it from the source format to HTML? -- 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] QCS2016 Session Notes - QUIPs for Qt
Hi, On 09/21/16 12:34, Friedemann Kleint wrote: > Hi, > > technically speaking: is using the .rst format set in stone? I find > this difficult to handle; one needs a local web server to view it > AFAIK. .md comes to mind as alternative? > We discussed this at QtCon and settled on ReStructured Text because it results in a cleaner plaintext document (i.e. more document-like, less markup-like) than markdown. It's also the format PIP uses, but note that it doesn't necessarily matter: each QUIP can declare its MIME type in the header. Anyway, I don't think you need a web server to view the formatted RST result. Docutils has examples on how to convert to HTML using Python: http://docutils.sourceforge.net/docs/user/tools.html#rst2html-py -- Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, technically speaking: is using the .rst format set in stone? I find this difficult to handle; one needs a local web server to view it AFAIK. .md comes to mind as alternative? Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On terça-feira, 20 de setembro de 2016 22:30:56 PDT Sergio Ahumada wrote: > which 5-year-old feature are we missing? The new UI. I want to see all comment, in all files, from all reviews, along with the review message, in one page. The new UI also has the ability to comment on multiple lines or sections of a line. -- 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] QCS2016 Session Notes - QUIPs for Qt
On 20.09.2016 21:26, Thiago Macieira wrote: On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: Really? Shouldn't be better to just announce a proposal on the mailing list and then shift the discussion and feedbacks on the codereview? It may come as a shock to you, but the Gerrit user interface is horrible. Reviewing discussions after they're done is very difficult, since there's no way to dump inline comments with the 5-year-old interface we're using (the one Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in progress is very difficult. Email is much easier. which 5-year-old feature are we missing? --comments? $ ssh codereview.qt-project.org gerrit query 171459 --patch-sets --comments --format JSON | python -c $'import json, sys; l=sys.stdin.readline();j=json.loads(l)\nfor i in j["patchSets"]:\n\tif "comments" in i: print i["comments"]' this shows both inline comments in https://codereview.qt-project.org/#/c/171459/1/src/plugins/platforms/vnc/qvnc.cpp -- Sergio Ahumada sahum...@texla.cl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
I could agree, but basically you're saying that the problem is the tool and not the idea to discuss the details on the codereview. At the end a proposal is for sure a document (thus a sort of source file) and so gerrit would help matching the discussion with the actual version of the document (imho this could be harder by email). Given that i'm ok in both codereview or email...maybe i'm too biased by github :) 2016-09-20 21:26 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: >> Really? >> Shouldn't be better to just announce a proposal on the mailing list >> and then shift the discussion and feedbacks >> on the codereview? > > It may come as a shock to you, but the Gerrit user interface is horrible. > Reviewing discussions after they're done is very difficult, since there's no > way > to dump inline comments with the 5-year-old interface we're using (the one > Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in > progress is very difficult. > > Email is much easier. > > -- > 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 -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: > Really? > Shouldn't be better to just announce a proposal on the mailing list > and then shift the discussion and feedbacks > on the codereview? It may come as a shock to you, but the Gerrit user interface is horrible. Reviewing discussions after they're done is very difficult, since there's no way to dump inline comments with the 5-year-old interface we're using (the one Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in progress is very difficult. Email is much easier. -- 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] QCS2016 Session Notes - QUIPs for Qt
My thinking. I’m fine to have initial discussions on the mailing list, but agreeing on and nailing down details will be a lot easier to do on codereview. Lars On 20/09/16 19:04, "Development on behalf of Filippo Cucchetto" wrote: Really? Shouldn't be better to just announce a proposal on the mailing list and then shift the discussion and feedbacks on the codereview? 2016-09-20 18:46 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: >> And it formalizes the way we can discuss and comment on things, as QUIPs >> would be reviewed in codereview, then approved there. I believe it’ll lead >> to a better workflow and better decision making in the project than >> discussions on the mailing list that often end somewhat inconclusive. > > Discussions on content still happen on the mailing list for maximum > reachability. The discussion on codereview is just the editorial workflow. > > -- > 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 -- Filippo Cucchetto ___ 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] QCS2016 Session Notes - QUIPs for Qt
Really? Shouldn't be better to just announce a proposal on the mailing list and then shift the discussion and feedbacks on the codereview? 2016-09-20 18:46 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: >> And it formalizes the way we can discuss and comment on things, as QUIPs >> would be reviewed in codereview, then approved there. I believe it’ll lead >> to a better workflow and better decision making in the project than >> discussions on the mailing list that often end somewhat inconclusive. > > Discussions on content still happen on the mailing list for maximum > reachability. The discussion on codereview is just the editorial workflow. > > -- > 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 -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: > And it formalizes the way we can discuss and comment on things, as QUIPs > would be reviewed in codereview, then approved there. I believe it’ll lead > to a better workflow and better decision making in the project than > discussions on the mailing list that often end somewhat inconclusive. Discussions on content still happen on the mailing list for maximum reachability. The discussion on codereview is just the editorial workflow. -- 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] QCS2016 Session Notes - QUIPs for Qt
> [*] https://wiki.qt.io/Template:QUIP > If someone with more Wiki-template-foo could please review this, I'm > sure it can be improved; in particular, it uses 000{{{1}}} where clearly > some analogue of formatting {{{1}}} with %03d would be more apt. Sorry, obviously I meant %04d ... Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Louai Al-Khanji wrote: > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > QUIP 1 introduces the general concept: > > http://quips-qt-io.herokuapp.com/quip-0001.html > > QUIP 2 details the Qt governance model, it’s simply the current wiki page > converted into a QUIP: > > http://quips-qt-io.herokuapp.com/quip-0002.html > > QUIP 3 is an informational QUIP containing the session notes, which are > repeated below: > > http://quips-qt-io.herokuapp.com/quip-0003.html > > The heroku domain is obviously a placeholder. In the interests of stability and to complete the Wiki's coverage of QtCon, I've turned the write-up at the end of your mail into: https://wiki.qt.io/QUIPs_for_Qt_at_QtCon_2016 I have concocted a crude Template:QUIP for use on the Wiki [*] and used it in this write-up. Thus there need only be one place on the Wiki that needs to change when the QUIPs find their new home. Just write {{QUIP|N}} to link to QUIP N. [*] https://wiki.qt.io/Template:QUIP If someone with more Wiki-template-foo could please review this, I'm sure it can be improved; in particular, it uses 000{{{1}}} where clearly some analogue of formatting {{{1}}} with %03d would be more apt. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On 20/09/16 09:27, "Development on behalf of Thiago Macieira" wrote: On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote: > So, could you please explain, preferably without relying on all the > acronyms, what problems this bureaucratization effort is trying to > resolve, and how it fits the rest of our work flow (like making feature > requests in Jira)? Basically, QUIP extends the governance by formalising decisions. The governance says decisions are made by consensus and meritocracy on the mailing list. But once the discussion ends, how do we know what we agreed upon? And two years later, how do we find out what we had decided? Can you remember the list of C++11 features we're allowed to use? We had a discussion on the mailing list. Do you remember why we decided not to have the Standard Library in our ABI? That discussion happened in 2012. The mailing list archives are searchable, but that doesn't mean it's easy to find what you're looking for. And it formalizes the way we can discuss and comment on things, as QUIPs would be reviewed in codereview, then approved there. I believe it’ll lead to a better workflow and better decision making in the project than discussions on the mailing list that often end somewhat inconclusive. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote: > So, could you please explain, preferably without relying on all the > acronyms, what problems this bureaucratization effort is trying to > resolve, and how it fits the rest of our work flow (like making feature > requests in Jira)? Basically, QUIP extends the governance by formalising decisions. The governance says decisions are made by consensus and meritocracy on the mailing list. But once the discussion ends, how do we know what we agreed upon? And two years later, how do we find out what we had decided? Can you remember the list of C++11 features we're allowed to use? We had a discussion on the mailing list. Do you remember why we decided not to have the Standard Library in our ABI? That discussion happened in 2012. The mailing list archives are searchable, but that doesn't mean it's easy to find what you're looking for. -- 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] QCS2016 Session Notes - QUIPs for Qt
Hi, Thanks for posting this, it finally cleared up a few postings by Thiago from just after the event. I wrestled my way through this whole thing, trying to get through the self-referential nature of all the acronyms. Somewhere in the middle I finally found what a QUIP is supposed to be. However, nowhere did I find an explanation of what problem it is supposed to solve, why it solves it, or how it integrates with the current work flow. So far, it seems to me like a solution from some management sphere without a problem to solve. So, could you please explain, preferably without relying on all the acronyms, what problems this bureaucratization effort is trying to resolve, and how it fits the rest of our work flow (like making feature requests in Jira)? Thanks, André Op 20/09/2016 om 00:45 schreef Louai Al-Khanji: Hi all, Here are my notes from the QUIPs session. Thank you for your patience. :-) QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. QUIP 1 introduces the general concept: http://quips-qt-io.herokuapp.com/quip-0001.html QUIP 2 details the Qt governance model, it’s simply the current wiki page converted into a QUIP: http://quips-qt-io.herokuapp.com/quip-0002.html QUIP 3 is an informational QUIP containing the session notes, which are repeated below: http://quips-qt-io.herokuapp.com/quip-0003.html The heroku domain is obviously a placeholder. I have also attached the source files for proposed QUIPs 1, 2, and 3 to this e-mail. One item left open was licensing of the QUIPs themselves. For these I propose Creative Commons CC0. Any and all feedback welcome. Cheers, Louai BEGIN NOTES At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the idea of introducing QUIPs as a new process for Qt governance. The general idea was introduced by looking at QUIPs 1 and 2, and by looking at some Python PEPs. The general feedback was positive. An attempt was made to identify the minimum set of work required to bootstrap QUIP, which was the main theme of the session. The overall discussion is summarized below, in roughly chronological order. - Discussed background of QUIP, the process and the documents. Referred to Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the session. - The idea is to have a new git repository with the QUIP text files - Managed through Qt's normal work flow, currently gerrit code review - The maintainer of the quips repository takes on required editorial duties - Agreed that the text documents should be limited to 80 character lines. - Agreed that care must be taken to ensure that QUIPs are written in "proper" English so as to be clear, understandable and concise. - Talked about how a new QUIP is introduced. The most important thing is to reserve a number, which is the identifier of any one QUIP. The title can change, and is expected to do so from time to time. - New QUIP documents will go through a review process like any other patch to Qt. The author of the QUIP is responsible for logging this discussion in the evolving QUIP itself. - The important thing is to bootstrap the process. Once it is bootstrapped, it is possible to fine-tune the QUIP process through QUIPs. It is expected that this will happen. - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough overview of the different kinds of possible QUIPs. It is expected that the content be further specified in revisions of QUIP 1 or in follow-up QUIPs. - Like any other part of Qt, QUIPs are living documents. They can be updated, amended or entirely superseded by later ones. - QUIP licensing was discussed. Python's PEPs are required to be either placed in the public domain or licensed under the Open Publication License. The former is not possible in all jurisdictions and the latter has apparently been superseded by the Creative Commons licenses the CC0 license was suggested. - The minimum QUIP boostrapping process was discussed: 1. Post QUIP 1 to qt-development mailing list for discussion. 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) 3. Create new git repository to hold QUIPs - The initial QUIP process was discussed: 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through gerrit 2. The author gives notice of new QUIP by sending it to qt-development, either inline or as a text attachment (things like this can be refined later through QUIPs) 3. Concurrently the author pushes the draft to gerrit where further discussion can take place. This discussion must be described in the QUIP. 4. Decisions are achieved through the same lazy consensus mechanism that is in place today. In that respect nothing changes. 5. A final +2 from the QUIP maintainer(s) is required. This di
[Development] QCS2016 Session Notes - QUIPs for Qt
Hi all, Here are my notes from the QUIPs session. Thank you for your patience. :-) QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. QUIP 1 introduces the general concept: http://quips-qt-io.herokuapp.com/quip-0001.html QUIP 2 details the Qt governance model, it’s simply the current wiki page converted into a QUIP: http://quips-qt-io.herokuapp.com/quip-0002.html QUIP 3 is an informational QUIP containing the session notes, which are repeated below: http://quips-qt-io.herokuapp.com/quip-0003.html The heroku domain is obviously a placeholder. I have also attached the source files for proposed QUIPs 1, 2, and 3 to this e-mail. One item left open was licensing of the QUIPs themselves. For these I propose Creative Commons CC0. Any and all feedback welcome. Cheers, Louai BEGIN NOTES At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the idea of introducing QUIPs as a new process for Qt governance. The general idea was introduced by looking at QUIPs 1 and 2, and by looking at some Python PEPs. The general feedback was positive. An attempt was made to identify the minimum set of work required to bootstrap QUIP, which was the main theme of the session. The overall discussion is summarized below, in roughly chronological order. - Discussed background of QUIP, the process and the documents. Referred to Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the session. - The idea is to have a new git repository with the QUIP text files - Managed through Qt's normal work flow, currently gerrit code review - The maintainer of the quips repository takes on required editorial duties - Agreed that the text documents should be limited to 80 character lines. - Agreed that care must be taken to ensure that QUIPs are written in "proper" English so as to be clear, understandable and concise. - Talked about how a new QUIP is introduced. The most important thing is to reserve a number, which is the identifier of any one QUIP. The title can change, and is expected to do so from time to time. - New QUIP documents will go through a review process like any other patch to Qt. The author of the QUIP is responsible for logging this discussion in the evolving QUIP itself. - The important thing is to bootstrap the process. Once it is bootstrapped, it is possible to fine-tune the QUIP process through QUIPs. It is expected that this will happen. - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough overview of the different kinds of possible QUIPs. It is expected that the content be further specified in revisions of QUIP 1 or in follow-up QUIPs. - Like any other part of Qt, QUIPs are living documents. They can be updated, amended or entirely superseded by later ones. - QUIP licensing was discussed. Python's PEPs are required to be either placed in the public domain or licensed under the Open Publication License. The former is not possible in all jurisdictions and the latter has apparently been superseded by the Creative Commons licenses the CC0 license was suggested. - The minimum QUIP boostrapping process was discussed: 1. Post QUIP 1 to qt-development mailing list for discussion. 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) 3. Create new git repository to hold QUIPs - The initial QUIP process was discussed: 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through gerrit 2. The author gives notice of new QUIP by sending it to qt-development, either inline or as a text attachment (things like this can be refined later through QUIPs) 3. Concurrently the author pushes the draft to gerrit where further discussion can take place. This discussion must be described in the QUIP. 4. Decisions are achieved through the same lazy consensus mechanism that is in place today. In that respect nothing changes. 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly from other parts of Qt as only the maintainer(s) can +2 changes to this repository. - Louai naively volunteered to convert existing material on the wiki into a series of QUIPs. - There was a question whether community guidelines could be described in a QUIP. The answer is a resounding yes. - The QUIP lifecycle was discussed. The following two items were explored: 1. Superseding QUIPs. These are QUIPs that both change some mechanism described in an earlier QUIP and change the content of that QUIP substantially. For small changes existing QUIPs can be updated. 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written to describe a change that occured in the past. For instance, an Implementation Track QUIP can be written after something has been added. QUIP: 1 Title: QUIP Purpose and Guidelines Ver