2017.11.30 14:00 "Re: [Tiff] Switching to gitlab ?", by

On 2017-11-30 13:22, Olivier Paquet wrote:

2017-11-30 5:31 GMT-05:00 Roger Leigh <rleigh@codelibre.net>:

For gitlab, while it's possible to use in the same style as CVS (direct push to the master branch), it's also possible to prevent direct pushes and require all changes to go via a merge request. The workflow is entirely up to what you prefer. The merge request workflow has the benefit of running continuous integration builds and tests, so you can validate the change before merging it into master. It's also

Do we have that setup? I see a merge request from you on that topic. I have zero familiarity with that system but it looks like it sets up automatic build on merge requests. Is that about it? If I'm reading the script correctly, it also runs the tests through the autoconf build, right?

Yes, it should all be set up and ready to go! I opened that merge request to test it out, and it all seems to be working. This is building on Unix with autoconf, and cmake, and on Windows with cmake (MSVC, Cygwin, MinGW) for a variety of configurations. This should cover all the common cases and give high confidence that there are no regressions. The full set of testcases is run in all cases.

If we're OK with proceeding with the switch, if anyone wanted to take a look at https://gitlab.com/libtiff/libtiff/merge_requests/1 and hit the "Merge" button if happy, that should test the remainder of the workflow: you should see it kick off a build of the master branch once done, which should also pass and turn green.

While this is in place and ready to use, it's not at all enforced at the moment. If it's considered acceptable for safety, we can disable direct pushes. If you have access to the project, you can push directly. I think the classification of the different project roles comes into play here, e.g. giving you push rights, the ability to merge open merge requests etc.

Another benefit of going through merge resquests is that it's a good spot for code review and comments. It's always a good thing have two sets of eyeballs go over the code before it gets permanently integrated. Although given how little time we sometimes have to put on the project, I'm not sure we can manage to always do them in a reasonable time frame.

Given the size of the project, it's likely fine to merge your own merge requests if there isn't anyone to review it in a timely manner. It should be possible to subscribe to be notified of new merge requests though, or even have it post to the list.

Unless someone objects, I would like to change the README to mention the new gitlab home, given that both gitlab and github show that file as a home page for a project. It would be a start in getting it to at least show up in a web search for libtiff.

Sounds good to me. If you wanted to give the gitlab workflow a try out, you could open it as a merge request! It would also test that the appveyor and gitlab CI test runners work in a forked project (I'm not sure mine counts since I set up the runners on the main instance).

By the way, if you were to rename it to README.md, gitlab will render the markdown on the main libtiff project page which will allow you to use hyperlinks rather than raw URLs, and have it look nicer as well: you can use section headers, verbatim text blocks etc.

Another thing to consider is that gitlab also provides libtiff.github.io/libtiff as hosted web space for the project; the HTML docs etc. could be put there if you wanted. I haven't yet tried this out but setup instructions are on https://about.gitlab.com/2016/04/07/gitlab-pages-setup/

Regards,
Roger