Re: [VOTE] Primate as modern UI for CloudStack
Sounds interesting Gregor! Von meinem iPhone gesendet __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 10.10.2019 um 16:47 schrieb Riepl, Gregor (SWISS TXT) > : > > Automated UI testing is usually done by running a web browser, generating > artificial user input, then verifying the result either by DOM analysis or > image recognition on screenshots. > > Our devs have achieved good results with TestCafe: > https://devexpress.github.io/testcafe/ > It's very easy to write tests and run them in different browser engines. You > can even run certain browser engines in headless mode for automated testing. > > From: Rohit Yadav > Sent: 09 October 2019 11:58 > To: dev > Subject: Re: [VOTE] Primate as modern UI for CloudStack > > Hi Ivan, > > Thanks for your advice. > > I agree with the general idea of automating regression test for the UI, > however, I don't have the expertise around writing tests using best > practices, and I look forward to you or anyone else who can share some > pointers, examples or maybe a plan. Given the UI is largely config and data > driven, the number of components shouldn't be high except for any > customization we do for some views. > > > Regards, > > Rohit Yadav > > Software Architect, ShapeBlue > > https://www.shapeblue.com > > > From: Ivan Kudryavtsev > Sent: Wednesday, October 9, 2019 09:37 > To: dev > Subject: Re: [VOTE] Primate as modern UI for CloudStack > > Hello, community. I know it's just a voting process, but still... a piece > of wisdom from webdev company: > > 1. Manual testing is an extremely bad idea, you've meet a lot of > regression, much more than the backend typically has. > > 2. In our teams frontend/backend ratio have shifted from 1/1 to 2/1, > without UI automation QA engineers, so 3/1 is average ratio for real life > high quality web UIs. > > 3. Try to use/invent some sort of Django-like UI generator frameworks, no > code manually. I see the high risk of fail without that. May be need to add > some sort of metadata to backend first. The Cloudmonkey approach is a great > basic idea... Oracle also has certain frameworks for that. Ideally, to > define the forms and sitemap and generate everything else from the ORM. > > 4. Happy to see the initiative, as it could help to decrease the pace of > backend changes and increase the stability, as certain amount of > influencers turn into frontend JS developers. > > > > ср, 9 окт. 2019 г., 7:45 Anurag Awasthi : > >> +1 >> >> Kind Regards, >> Anurag Awasthi >> >> From: Marco Sinhoreli >> Sent: Wednesday, October 9, 2019 4:10 AM >> To: dev@cloudstack.apache.org ; >> us...@cloudstack.apache.org ; >> priv...@cloudstack.apache.org >> Subject: Re: [VOTE] Primate as modern UI for CloudStack >> >> +1 >> >> >> Marco Sinhoreli >> Latam Technical Director >> marco.sinhor...@shapeblue.com >> mobile: +55 11 95656-3636 >> >> Rua Gomes de Carvalho, 911 – Sala 316 >> Vila Olímpia, São Paulo, SP, Brasil, 04547-003 >> Phone: + 55 11 2818-3419 >> http://www.shapeblue.com/ | twitter: @shapeblue >> >> Em 07/10/2019 08:31, "Rohit Yadav" escreveu: >> >>All, >> >>The feedback and response has been positive on the proposal to use >> Primate as the modern UI for CloudStack [1] [2]. Thank you all. >> >>I'm starting this vote (to): >> >> * Accept Primate codebase [3] as a project under Apache CloudStack >> project >> * Create and host a new repository (cloudstack-primate) and follow >> Github based development workflow (issues, pull requests etc) as we do with >> CloudStack >> * Given this is a new project, to encourage cadence until its >> feature completeness the
Re: [VOTE] Primate as modern UI for CloudStack
Automated UI testing is usually done by running a web browser, generating artificial user input, then verifying the result either by DOM analysis or image recognition on screenshots. Our devs have achieved good results with TestCafe: https://devexpress.github.io/testcafe/ It's very easy to write tests and run them in different browser engines. You can even run certain browser engines in headless mode for automated testing. From: Rohit Yadav Sent: 09 October 2019 11:58 To: dev Subject: Re: [VOTE] Primate as modern UI for CloudStack Hi Ivan, Thanks for your advice. I agree with the general idea of automating regression test for the UI, however, I don't have the expertise around writing tests using best practices, and I look forward to you or anyone else who can share some pointers, examples or maybe a plan. Given the UI is largely config and data driven, the number of components shouldn't be high except for any customization we do for some views. Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com From: Ivan Kudryavtsev Sent: Wednesday, October 9, 2019 09:37 To: dev Subject: Re: [VOTE] Primate as modern UI for CloudStack Hello, community. I know it's just a voting process, but still... a piece of wisdom from webdev company: 1. Manual testing is an extremely bad idea, you've meet a lot of regression, much more than the backend typically has. 2. In our teams frontend/backend ratio have shifted from 1/1 to 2/1, without UI automation QA engineers, so 3/1 is average ratio for real life high quality web UIs. 3. Try to use/invent some sort of Django-like UI generator frameworks, no code manually. I see the high risk of fail without that. May be need to add some sort of metadata to backend first. The Cloudmonkey approach is a great basic idea... Oracle also has certain frameworks for that. Ideally, to define the forms and sitemap and generate everything else from the ORM. 4. Happy to see the initiative, as it could help to decrease the pace of backend changes and increase the stability, as certain amount of influencers turn into frontend JS developers. ср, 9 окт. 2019 г., 7:45 Anurag Awasthi : > +1 > > Kind Regards, > Anurag Awasthi > > From: Marco Sinhoreli > Sent: Wednesday, October 9, 2019 4:10 AM > To: dev@cloudstack.apache.org ; > us...@cloudstack.apache.org ; > priv...@cloudstack.apache.org > Subject: Re: [VOTE] Primate as modern UI for CloudStack > > +1 > > > Marco Sinhoreli > Latam Technical Director > marco.sinhor...@shapeblue.com > mobile: +55 11 95656-3636 > > Rua Gomes de Carvalho, 911 – Sala 316 > Vila Olímpia, São Paulo, SP, Brasil, 04547-003 > Phone: + 55 11 2818-3419 > http://www.shapeblue.com/ | twitter: @shapeblue > > Em 07/10/2019 08:31, "Rohit Yadav" escreveu: > > All, > > The feedback and response has been positive on the proposal to use > Primate as the modern UI for CloudStack [1] [2]. Thank you all. > > I'm starting this vote (to): > > * Accept Primate codebase [3] as a project under Apache CloudStack > project > * Create and host a new repository (cloudstack-primate) and follow > Github based development workflow (issues, pull requests etc) as we do with > CloudStack > * Given this is a new project, to encourage cadence until its > feature completeness the merge criteria is proposed as: > * Manual testing against each PR and/or with screenshots from > the author or testing contributor, integration with Travis is possible once > we get JS/UI tests > * At least 1 LGTM from any of the active contributors, we'll > move this to 2 LGTMs when the codebase reaches feature parity wrt the > existing/old CloudStack UI > * Squash and merge PRs > * Accept the proposed timeline [1][2] (subject to achievement of > goals wrt Primate technical release and GA) > * the first technical preview targetted with the winter 2019 > LTS release (~Q1 2020) and release to serve a deprecation notice wrt the > older UI > * define a release approach before winter LTS > * stop taking feature FRs for old/existing UI after winter 2019 > LTS release, work on upgrade path/documentation from old UI to Primate > * the first Primate GA targetted wrt summer LTS 2020 (~H2 > 2019), but still ship old UI with a final deprecation notice > * old UI codebase removed from codebase in winter 2020 LTS > release > > The vote will be up for the next two weeks to give enough time for PMC > and the community to gather consensus and still have room for questions, > feedback and discussions. The results to be shared on/after 21th October > 2019. > > For sanity in tallying the vote, can PMC members please be sure to > indicate "(binding)" with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > >
Re: [DISCUSS][PROPOSAL]merge policy ratification
We are here talking about the one who presses the trigger (merge), not the one submitting PR/code/etc - merge action has to be considered if it is OK to merge or not. On Thu, 10 Oct 2019 at 13:53, Sven Vogel wrote: > > Catching inefficient or poorly written code is important, but no one > will care that the code is beautifully written, if the SSVM deletes a > users' VMs because what looked good in theory didn't work in practice. > > Agree Paul. > > --trust > > maybe I was misunderstood. if a person has a lot of commits there is more > trust more then a person who has the first commit. I know that mistakes are > the normal course of life and experienced developer and committer can also > produce mistakes. :) > > Sanity check if possible, code check, manually testing is the best. > > Cheers > Sven > > > > > __ > > Sven Vogel > Teamlead Platform > > EWERK DIGITAL GmbH > Brühl 24, D-04109 Leipzig > P +49 341 42649 - 99 > F +49 341 42649 - 98 > s.vo...@ewerk.com > www.ewerk.com > > Geschäftsführer: > Dr. Erik Wende, Hendrik Schubert, Frank Richter > Registergericht: Leipzig HRB 9065 > > Zertifiziert nach: > ISO/IEC 27001:2013 > DIN EN ISO 9001:2015 > DIN ISO/IEC 2-1:2011 > > EWERK-Blog | LinkedIn | Xing | Twitter | Facebook > > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. > > Disclaimer Privacy: > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist > vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der > bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte > informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie > die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. > Vielen Dank. > > The contents of this e-mail (including any attachments) are confidential > and may be legally privileged. If you are not the intended recipient of > this e-mail, any disclosure, copying, distribution or use of its contents > is strictly prohibited, and you should please notify the sender immediately > and then delete it (including any attachments) from your system. Thank you. > > Am 10.10.2019 um 12:49 schrieb Paul Angus : > > > > Yes, the 'independent verification' could come from one of the LGTM > committers, although an explanation (+'proof') would still be required for > sanity checking. Catching inefficient or poorly written code is > important, but no one will care that the code is beautifully written, if > the SSVM deletes a users' VMs because what looked good in theory didn't > work in practice. > > > > It's not about trust, people make mistakes, have bad days, or even get > lazy occasionally, we have to catch mistakes where we can to make > CloudStack as good as we can to keep people using it. > > > > > > paul.an...@shapeblue.com > > www.shapeblue.com > > Amadeus House, Floral Street, London WC2E 9DPUK > > @shapeblue > > > > > > > > > > -Original Message- > > From: Sven Vogel > > Sent: 10 October 2019 10:48 > > To: dev@cloudstack.apache.org > > Cc: priv...@cloudstack.apache.org > > Subject: Re: [DISCUSS][PROPOSAL]merge policy ratification > > > > I think 2 LGTM should be ok if anyone of them has tested it. > > > > The main thing is you need to trust anyway that the person if he has > tested it E.g. manually. > > > > That’s live and trust from committers I think. Apache is also a chain of > trust. > > > > Von meinem iPhone gesendet > > > > > > __ > > > > Sven Vogel > > Teamlead Platform > > > > EWERK DIGITAL GmbH > > Brühl 24, D-04109 Leipzig > > P +49 341 42649 - 99 > > F +49 341 42649 - 98 > > s.vo...@ewerk.com > > www.ewerk.com > > > > Geschäftsführer: > > Dr. Erik Wende, Hendrik Schubert, Frank Richter > > Registergericht: Leipzig HRB 9065 > > > > Zertifiziert nach: > > ISO/IEC 27001:2013 > > DIN EN ISO 9001:2015 > > DIN ISO/IEC 2-1:2011 > > > > EWERK-Blog | LinkedIn | Xing | Twitter | Facebook > > > > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. > > > > Disclaimer Privacy: > > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) > ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der > bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte > informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie > die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. > Vielen Dank. > > > > The contents of this e-mail (including any attachments) are confidential > and may be legally privileged. If you are not the intended recipient of > this e-mail, any disclosure, copying, distribution or use of its contents > is strictly prohibited, and you should please notify the sender immediately > and then delete it (including any attachments) from your system. Thank you. > >> Am 10.10.2019 um 11:43 schrieb Andrija Panic : > >> > >> Is there a way to
Re: [DISCUSS][PROPOSAL]merge policy ratification
> Catching inefficient or poorly written code is important, but no one will > care that the code is beautifully written, if the SSVM deletes a users' VMs > because what looked good in theory didn't work in practice. Agree Paul. --trust maybe I was misunderstood. if a person has a lot of commits there is more trust more then a person who has the first commit. I know that mistakes are the normal course of life and experienced developer and committer can also produce mistakes. :) Sanity check if possible, code check, manually testing is the best. Cheers Sven __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 10.10.2019 um 12:49 schrieb Paul Angus : > > Yes, the 'independent verification' could come from one of the LGTM > committers, although an explanation (+'proof') would still be required for > sanity checking. Catching inefficient or poorly written code is important, > but no one will care that the code is beautifully written, if the SSVM > deletes a users' VMs because what looked good in theory didn't work in > practice. > > It's not about trust, people make mistakes, have bad days, or even get lazy > occasionally, we have to catch mistakes where we can to make CloudStack as > good as we can to keep people using it. > > > paul.an...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > > > -Original Message- > From: Sven Vogel > Sent: 10 October 2019 10:48 > To: dev@cloudstack.apache.org > Cc: priv...@cloudstack.apache.org > Subject: Re: [DISCUSS][PROPOSAL]merge policy ratification > > I think 2 LGTM should be ok if anyone of them has tested it. > > The main thing is you need to trust anyway that the person if he has tested > it E.g. manually. > > That’s live and trust from committers I think. Apache is also a chain of > trust. > > Von meinem iPhone gesendet > > > __ > > Sven Vogel > Teamlead Platform > > EWERK DIGITAL GmbH > Brühl 24, D-04109 Leipzig > P +49 341 42649 - 99 > F +49 341 42649 - 98 > s.vo...@ewerk.com > www.ewerk.com > > Geschäftsführer: > Dr. Erik Wende, Hendrik Schubert, Frank Richter > Registergericht: Leipzig HRB 9065 > > Zertifiziert nach: > ISO/IEC 27001:2013 > DIN EN ISO 9001:2015 > DIN ISO/IEC 2-1:2011 > > EWERK-Blog | LinkedIn | Xing | Twitter | Facebook > > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. > > Disclaimer Privacy: > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist > vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der > bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte > informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die > E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen > Dank. > > The contents of this e-mail (including any attachments) are confidential and > may be legally privileged. If you are not the intended recipient of this > e-mail, any disclosure, copying, distribution or use of its contents is > strictly prohibited, and you should please notify the sender immediately and > then delete it (including any attachments) from your system. Thank you. >> Am 10.10.2019 um 11:43 schrieb Andrija Panic : >> >> Is there a way to "force" some text into the PR description - i.e. >> like we do for ISSUES (there is some predefined text when creating one). >> My idea ^^^ is to make those rules visible in every PR - besides >> having rules more explicit, they need to be more visible (as a >> reminder) to humans pulling the merge trigger. >> >> (I also like the idea of regression-test pass being considered just a >> starting point for any
RE: [DISCUSS][PROPOSAL]merge policy ratification
Yes, the 'independent verification' could come from one of the LGTM committers, although an explanation (+'proof') would still be required for sanity checking. Catching inefficient or poorly written code is important, but no one will care that the code is beautifully written, if the SSVM deletes a users' VMs because what looked good in theory didn't work in practice. It's not about trust, people make mistakes, have bad days, or even get lazy occasionally, we have to catch mistakes where we can to make CloudStack as good as we can to keep people using it. paul.an...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Sven Vogel Sent: 10 October 2019 10:48 To: dev@cloudstack.apache.org Cc: priv...@cloudstack.apache.org Subject: Re: [DISCUSS][PROPOSAL]merge policy ratification I think 2 LGTM should be ok if anyone of them has tested it. The main thing is you need to trust anyway that the person if he has tested it E.g. manually. That’s live and trust from committers I think. Apache is also a chain of trust. Von meinem iPhone gesendet __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 10.10.2019 um 11:43 schrieb Andrija Panic : > > Is there a way to "force" some text into the PR description - i.e. > like we do for ISSUES (there is some predefined text when creating one). > My idea ^^^ is to make those rules visible in every PR - besides > having rules more explicit, they need to be more visible (as a > reminder) to humans pulling the merge trigger. > > (I also like the idea of regression-test pass being considered just a > starting point for any further testing of the PR) > > My objection for some observed PRs: > 2 x LGTM from purely code review should NOT be enough for merging > (assuming regression testing was fine) - perhaps in some realy edge > cases where it's 100% clear there is no reason for manual testing > (typos fix, simple GUI changes etc). > At least one LGTM needs to come from the person who did explicit > testing - "worksOnMyComputer" (from the submitter of the PR) is not enough > IMHO. > > Best, > Andrija > > > >> On Thu, 10 Oct 2019 at 10:25, Paul Angus wrote: >> >> BUMP. >> >> Hey Guys, >> >> We have a lot of new people in the community these days; this seems >> like an important exercise to ensure that we're all on the same page, >> whether that ends up simply re-signing up to the existing practices >> or evolving them. >> >> _personally_ I'd like the conditions to be more explicit that there >> needs to be some independent verification that the change does what >> it's supposed to (and doesn't do anything that it's not supposed to). >> It looks to me that sometimes passing regression tests is seen as the >> change has been tested. IMO regression test passing is a >> prerequisite of a PR being ready for anyone other than the author(s) to >> start reviewing the PR. >> >> Cheers >> >> >> Paul. >> >> >> >> paul.an...@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue >> >> >> >> >> -Original Message- >> From: Daan Hoogland >> Sent: 02 October 2019 12:37 >> To: dev >> Subject: [DISCUSS][PROPOSAL]merge policy ratification >> >> LS, >> in the past we had set a set of rules in the community under which PR >> could be merged. I want to reiterate them here as it seems we are kind of >> slacking. Please chime in if there are any issues or omissions: >> >> For a PR to be merged it has to adhere to the following conditions: >> - In any case >> -- A PR has to have had two approving reviews >> -- A PR has to have no outstanding requests for changes. A request for >> changes is regarded no
Re: [DISCUSS][PROPOSAL]merge policy ratification
I think 2 LGTM should be ok if anyone of them has tested it. The main thing is you need to trust anyway that the person if he has tested it E.g. manually. That’s live and trust from committers I think. Apache is also a chain of trust. Von meinem iPhone gesendet __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 10.10.2019 um 11:43 schrieb Andrija Panic : > > Is there a way to "force" some text into the PR description - i.e. like we > do for ISSUES (there is some predefined text when creating one). > My idea ^^^ is to make those rules visible in every PR - besides having > rules more explicit, they need to be more visible (as a reminder) to humans > pulling the merge trigger. > > (I also like the idea of regression-test pass being considered just a > starting point for any further testing of the PR) > > My objection for some observed PRs: > 2 x LGTM from purely code review should NOT be enough for merging (assuming > regression testing was fine) - perhaps in some realy edge cases where it's > 100% clear there is no reason for manual testing (typos fix, simple GUI > changes etc). > At least one LGTM needs to come from the person who did explicit testing - > "worksOnMyComputer" (from the submitter of the PR) is not enough IMHO. > > Best, > Andrija > > > >> On Thu, 10 Oct 2019 at 10:25, Paul Angus wrote: >> >> BUMP. >> >> Hey Guys, >> >> We have a lot of new people in the community these days; this seems like >> an important exercise to ensure that we're all on the same page, whether >> that ends up simply re-signing up to the existing practices or evolving >> them. >> >> _personally_ I'd like the conditions to be more explicit that there needs >> to be some independent verification that the change does what it's supposed >> to (and doesn't do anything that it's not supposed to). It looks to me >> that sometimes passing regression tests is seen as the change has been >> tested. IMO regression test passing is a prerequisite of a PR being ready >> for anyone other than the author(s) to start reviewing the PR. >> >> Cheers >> >> >> Paul. >> >> >> >> paul.an...@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK >> @shapeblue >> >> >> >> >> -Original Message- >> From: Daan Hoogland >> Sent: 02 October 2019 12:37 >> To: dev >> Subject: [DISCUSS][PROPOSAL]merge policy ratification >> >> LS, >> in the past we had set a set of rules in the community under which PR >> could be merged. I want to reiterate them here as it seems we are kind of >> slacking. Please chime in if there are any issues or omissions: >> >> For a PR to be merged it has to adhere to the following conditions: >> - In any case >> -- A PR has to have had two approving reviews >> -- A PR has to have no outstanding requests for changes. A request for >> changes is regarded no longer outstanding if the requester stops responding >> on the PR discussions. >> -- A PR has to have a review with verification description. Depending on >> the type of PR this can be a test description, an automated test included, >> screenshots in case of UI changes. If it is a tetual change it must be >> verified to not apply to logs or events. >> - any commiter can merge a PR if it adheres to those conditions >> -- unless a freeze has been called by a the branch it is to be merged on >> by a community appointed release manager for that branch >> >> hope this is short and complete enough at the same time. It has been >> agreed upon in the past but I am too lazy to find the mail thread in the >> archives. >> If anyone disagrees we'll have to go there. They seem reasonable and >> self-evident to me. I am also not sure if these should be stated in bylaws >> or on github, so comments in that
Re: [DISCUSS][PROPOSAL]merge policy ratification
Is there a way to "force" some text into the PR description - i.e. like we do for ISSUES (there is some predefined text when creating one). My idea ^^^ is to make those rules visible in every PR - besides having rules more explicit, they need to be more visible (as a reminder) to humans pulling the merge trigger. (I also like the idea of regression-test pass being considered just a starting point for any further testing of the PR) My objection for some observed PRs: 2 x LGTM from purely code review should NOT be enough for merging (assuming regression testing was fine) - perhaps in some realy edge cases where it's 100% clear there is no reason for manual testing (typos fix, simple GUI changes etc). At least one LGTM needs to come from the person who did explicit testing - "worksOnMyComputer" (from the submitter of the PR) is not enough IMHO. Best, Andrija On Thu, 10 Oct 2019 at 10:25, Paul Angus wrote: > BUMP. > > Hey Guys, > > We have a lot of new people in the community these days; this seems like > an important exercise to ensure that we're all on the same page, whether > that ends up simply re-signing up to the existing practices or evolving > them. > > _personally_ I'd like the conditions to be more explicit that there needs > to be some independent verification that the change does what it's supposed > to (and doesn't do anything that it's not supposed to). It looks to me > that sometimes passing regression tests is seen as the change has been > tested. IMO regression test passing is a prerequisite of a PR being ready > for anyone other than the author(s) to start reviewing the PR. > > Cheers > > > Paul. > > > > paul.an...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > > > -Original Message- > From: Daan Hoogland > Sent: 02 October 2019 12:37 > To: dev > Subject: [DISCUSS][PROPOSAL]merge policy ratification > > LS, > in the past we had set a set of rules in the community under which PR > could be merged. I want to reiterate them here as it seems we are kind of > slacking. Please chime in if there are any issues or omissions: > > For a PR to be merged it has to adhere to the following conditions: > - In any case > -- A PR has to have had two approving reviews > -- A PR has to have no outstanding requests for changes. A request for > changes is regarded no longer outstanding if the requester stops responding > on the PR discussions. > -- A PR has to have a review with verification description. Depending on > the type of PR this can be a test description, an automated test included, > screenshots in case of UI changes. If it is a tetual change it must be > verified to not apply to logs or events. > - any commiter can merge a PR if it adheres to those conditions > -- unless a freeze has been called by a the branch it is to be merged on > by a community appointed release manager for that branch > > hope this is short and complete enough at the same time. It has been > agreed upon in the past but I am too lazy to find the mail thread in the > archives. > If anyone disagrees we'll have to go there. They seem reasonable and > self-evident to me. I am also not sure if these should be stated in bylaws > or on github, so comments in that respect are welcome as well. Let's first > again agree on them. > > regards, > > -- > Daan > -- Andrija Panić
RE: [DISCUSS][PROPOSAL]merge policy ratification
BUMP. Hey Guys, We have a lot of new people in the community these days; this seems like an important exercise to ensure that we're all on the same page, whether that ends up simply re-signing up to the existing practices or evolving them. _personally_ I'd like the conditions to be more explicit that there needs to be some independent verification that the change does what it's supposed to (and doesn't do anything that it's not supposed to). It looks to me that sometimes passing regression tests is seen as the change has been tested. IMO regression test passing is a prerequisite of a PR being ready for anyone other than the author(s) to start reviewing the PR. Cheers Paul. paul.an...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Daan Hoogland Sent: 02 October 2019 12:37 To: dev Subject: [DISCUSS][PROPOSAL]merge policy ratification LS, in the past we had set a set of rules in the community under which PR could be merged. I want to reiterate them here as it seems we are kind of slacking. Please chime in if there are any issues or omissions: For a PR to be merged it has to adhere to the following conditions: - In any case -- A PR has to have had two approving reviews -- A PR has to have no outstanding requests for changes. A request for changes is regarded no longer outstanding if the requester stops responding on the PR discussions. -- A PR has to have a review with verification description. Depending on the type of PR this can be a test description, an automated test included, screenshots in case of UI changes. If it is a tetual change it must be verified to not apply to logs or events. - any commiter can merge a PR if it adheres to those conditions -- unless a freeze has been called by a the branch it is to be merged on by a community appointed release manager for that branch hope this is short and complete enough at the same time. It has been agreed upon in the past but I am too lazy to find the mail thread in the archives. If anyone disagrees we'll have to go there. They seem reasonable and self-evident to me. I am also not sure if these should be stated in bylaws or on github, so comments in that respect are welcome as well. Let's first again agree on them. regards, -- Daan
RE: [VOTE] Primate as modern UI for CloudStack
That sounds great Ivan! You can see the code at https://github.com/shapeBlue/primate Hopefully within a couple of weeks it'll be able to be included in the Apache repo. paul.an...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Ivan Kudryavtsev Sent: 09 October 2019 11:08 To: dev Subject: Re: [VOTE] Primate as modern UI for CloudStack Rohit, we can not afford full-time QA allocation for the project, but let me know when you would produce the first piece of the the code, and I'll dedicate someone from the QA with Cloudstack experience, who can help you to establish the testing environment, choose the tools and write some tests to build a foundation, so in the future you and other involved can act by example. ср, 9 окт. 2019 г. в 16:59, Rohit Yadav : > Hi Ivan, > > Thanks for your advice. > > I agree with the general idea of automating regression test for the > UI, however, I don't have the expertise around writing tests using > best practices, and I look forward to you or anyone else who can share > some pointers, examples or maybe a plan. Given the UI is largely > config and data driven, the number of components shouldn't be high > except for any customization we do for some views. > > > Regards, > > Rohit Yadav > > Software Architect, ShapeBlue > > https://www.shapeblue.com > > > From: Ivan Kudryavtsev > Sent: Wednesday, October 9, 2019 09:37 > To: dev > Subject: Re: [VOTE] Primate as modern UI for CloudStack > > Hello, community. I know it's just a voting process, but still... a > piece of wisdom from webdev company: > > 1. Manual testing is an extremely bad idea, you've meet a lot of > regression, much more than the backend typically has. > > 2. In our teams frontend/backend ratio have shifted from 1/1 to 2/1, > without UI automation QA engineers, so 3/1 is average ratio for real > life high quality web UIs. > > 3. Try to use/invent some sort of Django-like UI generator frameworks, > no code manually. I see the high risk of fail without that. May be > need to add some sort of metadata to backend first. The Cloudmonkey > approach is a great basic idea... Oracle also has certain frameworks > for that. Ideally, to define the forms and sitemap and generate everything > else from the ORM. > > 4. Happy to see the initiative, as it could help to decrease the pace > of backend changes and increase the stability, as certain amount of > influencers turn into frontend JS developers. > > > > ср, 9 окт. 2019 г., 7:45 Anurag Awasthi : > > > +1 > > > > Kind Regards, > > Anurag Awasthi > > > > From: Marco Sinhoreli > > Sent: Wednesday, October 9, 2019 4:10 AM > > To: dev@cloudstack.apache.org ; > > us...@cloudstack.apache.org ; > > priv...@cloudstack.apache.org > > Subject: Re: [VOTE] Primate as modern UI for CloudStack > > > > +1 > > > > > > Marco Sinhoreli > > Latam Technical Director > > marco.sinhor...@shapeblue.com > > mobile: +55 11 95656-3636 > > > > Rua Gomes de Carvalho, 911 – Sala 316 Vila Olímpia, São Paulo, SP, > > Brasil, 04547-003 > > Phone: + 55 11 2818-3419 > > http://www.shapeblue.com/ | twitter: @shapeblue > > > > Em 07/10/2019 08:31, "Rohit Yadav" > escreveu: > > > > All, > > > > The feedback and response has been positive on the proposal to > > use Primate as the modern UI for CloudStack [1] [2]. Thank you all. > > > > I'm starting this vote (to): > > > > * Accept Primate codebase [3] as a project under Apache > CloudStack > > project > > * Create and host a new repository (cloudstack-primate) and > follow > > Github based development workflow (issues, pull requests etc) as we > > do > with > > CloudStack > > * Given this is a new project, to encourage cadence until its > > feature completeness the merge criteria is proposed as: > > * Manual testing against each PR and/or with screenshots from > > the author or testing contributor, integration with Travis is > > possible > once > > we get JS/UI tests > > * At least 1 LGTM from any of the active contributors, we'll > > move this to 2 LGTMs when the codebase reaches feature parity wrt > > the existing/old CloudStack UI > > * Squash and merge PRs > > * Accept the proposed timeline [1][2] (subject to achievement of > > goals wrt Primate technical release and GA) > > * the first technical preview targetted with the winter 2019 > > LTS release (~Q1 2020) and release to serve a deprecation notice wrt > > the older UI > > * define a release approach before winter LTS > > * stop taking feature FRs for old/existing UI after winter > 2019 > > LTS release, work on upgrade path/documentation from old UI to Primate > > * the first Primate GA targetted wrt summer LTS 2020 (~H2 > > 2019), but still ship old UI with a final deprecation notice > >
