[QE-developers] using git

[Ye Luo]

Hi all,

Here is the dev doc for QMCPACK. Hope you can find something useful.
https://github.com/QMCPACK/qmcpack/wiki/Development-workflow
We moved to github a year ago. By using all the software engineering
practice, we really see significant improvements in code and productivity.
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.
Now, everyone loves it.

In my experience, master is only necessary to track release. There is no
need to update it frequently.
git tags are separated from branches. it doesn't belongs the default branch.
So using develop as default is preferred.
Why not put the buildbot on develop since its purpose is to automate
testing and find issue as early as possible.
*"I only  run parallel tests on intel and gfortran before merging develop
to master."*
The buildbot should save your time on this.

Pushing to master or develop should be reserved only for very special cases
and the permission should be removed from all developers but maintainers.
Looking at the commits this week, many small commits are only meant by the
develop for intermediate use.
Develops are free to stage changes as frequent as they like but not
necessary recording every detail in develop and pushed to develop
immediately.
For this reason, working on a fork and then using pull request is a better
way and a code review can be added.
A code review is really important to improve the code quality. Everyone is
knowledge is limited and suggestions from others are often helpful.
Squashing has its downside. I prefer not to do it.

Happy easter,
Ye

===================
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory

2018-03-30 4:41 GMT-05:00 Pietro Delugas <pdelugas at sissa.it>:

> Ciao Lorenzo
>
>
> there is this too brief thing in the repository
>
> https://gitlab.com/QEF/q-e/blob/master/CONTRIBUTING.md
>
> any improvement is warmly welcome !!!
>
>
> All new commits should be pushed   on   the develop branch.
>
> 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 ...
>
> 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.
>
> 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.
>
> The merge or pull request procedure using a fork is the recommended one.
>
> Pushing directly to develop or master I think should be reserved to
> maintenance or urgent bug fixes.
>
> 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.
>
> thanks again
>
> greetings - Pietro
>
>
>
>
> On 30/03/2018 10:22, Lorenzo Paulatto wrote:
>
>> Hello,
>> 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).
>>
>> 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.
>>
>> 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?
>>
>> cheers
>>
>>
>>
> _______________________________________________
> developers mailing list
> developers at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20180330/ceac576e/attachment.html>