<div dir="ltr"><div><div><div>Thank you for your suggestions. I have collected in the developer manual the current idea of how the development should proceed. I have no strong opinions about it, except these two:<br></div>- since git is so complex, the flow of development must be kept as simple as possible; and<br></div>- I have already wasted too much time with git<br><br></div>Paolo<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 30, 2018 at 5:23 PM, 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_207244940653366200gmail_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_207244940653366200im m_207244940653366200HOEnZb"><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_207244940653366200HOEnZb"><div class="m_207244940653366200h5">
______________________________<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"><div><div dir="ltr"><div>Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone +39-0432-558216, fax +39-0432-558222<br><br></div></div></div></div></div>
</div>