Back to '''[[Software/Meeting/Overview|Overview]]''' - Next protocol '''[[Software/Meeting/20190118]]''' = Summary of developer meeting at 2019-01-04 = <> == Discussions and Outcomes == Ted and Brian has some discussions, mostly about using git, Karl-Heinz gave some comments. * Ted created an "empty" server database for Brian. "Empty" means that the structure is complete but there are no account or logging data in it. But later reports from Brian imply that too much has been deleted, investigations are not yet completed. * Concerning usage of branches in git for your own (in this case Brian's) development/test environment: * See also [[Software/WorkingWithGit]] (found this after the meeting) * Check out the "integration" branch from git://git.cacert.org/cacert-devel.git. Note, this branch is read-only for developers, it should reflect the "base state" of the testserver. * Create a new branch for your testserver based on the "integration" branch, let's call it "my-test" for reference. This will be your private branch to play with, normally there's no need to push this branch on one of the servers. * Now, if you want to test the fixes for one or more bugs, merge the corresponding bug-xxxx branches into your "my-test" branch. Since all the bug-xxxx branches should be based on the "integration" branch, there should be no merge conflicts when merging in a single bug-xxxx branch. But of course, this is theroy only... :-\ * If you notice a bug during the test that you can fix yourself, fix it in the bug-xxxx branch, and then merge the bug-xxxx branch into your my-test branch once more. * If you are done with testing, or want to test other unrelated bugfixes, reset your my-test branch to the integration branch, and start with merging in the other bug-yyyy branch(es). This way you start your test with a "clean" basis. * Alternatively you may also start a new branch "my-test-yyyy" based on the integration branch. * Occasionally (every time a bug is handed off for installation) the integration branch will change, and you'll have to "pull" the changes from the server again. If this happens while you are still testing, you should "rebase" your my-test branch(es) to the new integration branch. This way the changes to the integration branch are also incorporated into your my-test branch(es). * Normally it makes sense to work with (at least) two "remote repositories". One should point at https://github.com/CAcertOrg/cacert-devel.git, the other at git://git.cacert.org/cacert-devel.git. In communication these repositories are called the "github repository" and the "CAcert repository" (no real surprise, isn't it? :-) ) * If you do not (yet) have write access to the github repository, it makes sense that you fork https://github.com/CAcertOrg/cacert-devel.git into your own github account and use this as a third "private" repository, so you can push changes into it, and then send a "pull request", so developers with write access can easily merge your changes into the other repositories. == Questions == === Open Questions === ''Questions which still have to be answered. Should those of the previous meetings be repeated if still open?'' === Answered Questions === ''Questions (may be from earlier meetings) which have been answered)'' == Logfile of the meeting == ''Please check first if the log was not declared private, this may happen when security issues are discussed. The log may be added as attachment or on its own page at Software/Meeting/YYYYMMDDlog'' == Next Meeting == The next meeting was proposed to be held on Jan 18, 2019, once more at 20:00 (UTC) = Done Work = ''This paragraph may be modified after the meeting to document progress'' * YYYY-MM-DD: Someone fixed some problem ---- . CategorySoftwareMeeting