[QE-developers] using git

[Paolo Giannozzi]

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:
- since git is so complex, the flow of development must be kept as simple
as possible; and
- I have already wasted too much time with git

Paolo

On Fri, Mar 30, 2018 at 5:23 PM, Ye Luo <xw111luoye at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> developers mailing list
> developers at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/developers
>
>


-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20180404/078fd66a/attachment.html>