<div dir="ltr"><div><div><div>Hello all, <br><br></div>Actually, I changed that a few days ago and now Buildbot does test the "develop" branch instead of "master" ==> <a href="http://130.186.13.198:8010/#/builders">http://130.186.13.198:8010/#/builders</a><br><br></div><div>It crashes everywhere at the moment, in part because of EPW. For some reasons buildbot keep reverting to what is in master for the test-suite although it does correctly pull the latest develop revision. Will look at this in more depth next week. <br></div><div><br></div>Best wishes, <br></div>Samuel<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2018 at 17:23, Ye Luo <span dir="ltr"><<a href="mailto:xw111luoye@gmail.com" target="_blank">xw111luoye@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi all,<br><br>Here is the dev doc for QMCPACK. Hope you can find something useful.<br><a href="https://github.com/QMCPACK/qmcpack/wiki/Development-workflow" target="_blank">https://github.com/QMCPACK/<wbr>qmcpack/wiki/Development-<wbr>workflow</a><br></div><div>We moved to github a year ago. By using all the software engineering practice, we really see significant improvements in code and productivity.<br></div><div>In the beginning, people thought this add extra burden on everyone. We have a smaller group of developers than QE and the overhead is supposed to be more.<br></div><div>Now, everyone loves it.<br></div><div><br></div></div></div></div>In my experience, master is only necessary to track release. There is no need to update it frequently.<br></div><div>git tags are separated from branches. it doesn't belongs the default branch.<br></div><div>So using develop as default is preferred.<br></div><div>Why not put the buildbot on develop since its purpose is to automate testing and find issue as early as possible.<span class=""><br><i>"I only run parallel tests on intel and gfortran before merging develop to master."</i><br></span></div><div>The buildbot should save your time on this.<br><br></div>Pushing to master or develop should be reserved only for very special cases and the permission should be removed from all developers but maintainers.<br></div>Looking at the commits this week, many small commits are only meant by the develop for intermediate use.<br></div>Develops are free to stage changes as frequent as they like but not necessary recording every detail in develop and pushed to develop immediately.<br></div>For this reason, working on a fork and then using pull request is a better way and a code review can be added.<br></div><div>A code review is really important to improve the code quality. Everyone is knowledge is limited and suggestions from others are often helpful.<br></div><div>Squashing has its downside. I prefer not to do it.<br><br></div><div>Happy easter,<br></div><div>Ye<br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-6688381081394264463gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">===================<br>
Ye Luo, Ph.D.<br>
Leadership Computing Facility<br>
Argonne National Laboratory</div></div></div><div><div class="h5">
<br><div class="gmail_quote">2018-03-30 4:41 GMT-05:00 Pietro Delugas <span dir="ltr"><<a href="mailto:pdelugas@sissa.it" target="_blank">pdelugas@sissa.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao Lorenzo<br>
<br>
<br>
there is this too brief thing in the repository<br>
<br>
<a href="https://gitlab.com/QEF/q-e/blob/master/CONTRIBUTING.md" rel="noreferrer" target="_blank">https://gitlab.com/QEF/q-e/blo<wbr>b/master/CONTRIBUTING.md</a><br>
<br>
any improvement is warmly welcome !!!<br>
<br>
<br>
All new commits should be pushed on the develop branch.<br>
<br>
About once a week, if there are not particular issues, the master branch is aligned to the develop one. I just did the alignment this morning after almost 2 weeks ...<br>
<br>
The automatic testing with the buildbot is currently done on the master in order to test a significant number of changes all together. I only run parallel tests on intel and gfortran before merging develop to master.<br>
<br>
Tags for releases are obviously pushed directly to the master branch, and download of zipped archives should also be done from the master branch. This is why master is still the default branch on the repository.<br>
<br>
The merge or pull request procedure using a fork is the recommended one.<br>
<br>
Pushing directly to develop or master I think should be reserved to maintenance or urgent bug fixes.<br>
<br>
It would be also nice to simplify as most as possible the commit history of the branch, or when appropriate, use the squash-in-one-commit option when submitting the merge request.<br>
<br>
thanks again<br>
<br>
greetings - Pietro<span class="m_-6688381081394264463im m_-6688381081394264463HOEnZb"><br>
<br>
<br>
<br>
<br>
On 30/03/2018 10:22, Lorenzo Paulatto wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
I'm trying to understand once again how we are supposed to use the gitlab repository specifically for qe, and to write a mini-guide in the process (I could not find any).<br>
<br>
I have a question: are we using the develop or the master branch by default? Commits seem to go to both more or less at the same time.<br>
<br>
Also, do yuo confirm that the official way to get commits into the repo is fork -> commit -> pull request, and even if some of us have write access to the QEF/q-e repo, it is better to avoid pushing to it directly?<br>
<br>
cheers<br>
<br>
<br>
</blockquote>
<br></span><div class="m_-6688381081394264463HOEnZb"><div class="m_-6688381081394264463h5">
______________________________<wbr>_________________<br>
developers mailing list<br>
<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espre<wbr>sso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso<wbr>.org/mailman/listinfo/develope<wbr>rs</a><br>
</div></div></blockquote></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
developers mailing list<br>
<a href="mailto:developers@lists.quantum-espresso.org">developers@lists.quantum-<wbr>espresso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-<wbr>espresso.org/mailman/listinfo/<wbr>developers</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><font color="#888888"><pre cols="72">------------------------------------------------------------------------------------------------
Dr. Samuel Poncé
Department of Materials
University of Oxford
Parks Road
Oxford OX1 3PH, UK
Phone: +44 1865 612789<br> email: <a href="mailto:samuel.ponce@materials.ox.ac.uk" target="_blank">samuel.ponce@materials.ox.ac.uk</a> <a href="mailto:fabio.caruso@materials.ox.ac.uk" target="_blank"></a>
web: <a href="http://giustino.materials.ox.ac.uk/index.php/Site/SamuelPonc%e9" target="_blank">http://giustino.materials.ox.ac.uk/index.php/Site/SamuelPonc%e9</a>
------------------------------------------------------------------------------------------------</pre></font></span></div></div>
</div>