[QE-developers] using git
Lorenzo Paulatto
paulatz at gmail.com
Thu Apr 5 11:01:15 CEST 2018
This is a little document I have done for some people here, I've really
tried to make it s short as simple as possible. Let me know if there is
anything wrong, if you want to put it somewhere in the website, to
convert it to html or whatever format is fancy this week.
On 04/04/18 22:30, Paolo Giannozzi wrote:
> 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
> <mailto: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
> <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
> <mailto: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
> <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
> <mailto:developers at lists.quantum-espresso.org>
> https://lists.quantum-espresso.org/mailman/listinfo/developers
> <https://lists.quantum-espresso.org/mailman/listinfo/developers>
>
>
>
> _______________________________________________
> developers mailing list
> developers at lists.quantum-espresso.org
> <mailto:developers at lists.quantum-espresso.org>
> https://lists.quantum-espresso.org/mailman/listinfo/developers
> <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
>
>
>
> _______________________________________________
> developers mailing list
> developers at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/developers
>
--
Lorenzo Paulatto - Paris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: git-workflow.odt
Type: application/vnd.oasis.opendocument.text
Size: 137367 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20180405/db8e5cb2/attachment-0001.odt>
More information about the developers
mailing list