Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues

[Raphael Arias]

Hi,

On 08.04.19 16:12, Christian Grothoff wrote:
> On 4/8/19 3:37 PM, Schanzenbach, Martin wrote:
>> No, we don't. We dvn et al are faced with unreasonable requirements for the 
>> use of gitlab which include:
>>
>> - Migration of Mantis issues -> completely unnecessary. Mantis could remain 
>> read-only for the "legacy" issues and gitlab used for new issues.
> Makes sense, except then Mantis has to remain. That means we have to
> keep securing the installation, backing up the database, etc. For how
> long? How well will this be done for a legacy system that is rarely
> used? Just today I got a report on libmicrohttpd that related to a #32xx
> bug which, when re-reading the ancient bug, helped me understand why the
> code was written the way it was written. Loosing this memory would be a
> major loss, likely more significant than loosing the commit history! So
> I think some effort to try to preserve it properly is worth it. And
> again, Gitlab was primarily proposed as "better CI", so if its
> introduction has other costs, it makes sense to try to minimize those,
> right?
>
I don't see why the database of a read-only legacy system would need to
be regularly backed up. If it remains online purely as an archive
(possibly with a note to go see the gitlab issue tracker) history is
preserved while not forcing anyone to do regular backups. Am I missing
something? If Mantis cannot be run as readonly, maybe an archived
version of it [0]?

I would like to add my voice to Martin's regarding usage of gitlab.

I've been extensively using gitlab at work for the last couple of years
and it is *really* powerful. I get that GNUnet's main purpose of
migrating to it is its CI which is really configurable; if your
branch/commit introduces changes that require a change to how the CI
behaves, then you just change the .gitlab-ci.yml along with your other
changes and the CI will run jobs according to those changes. I'm not
really familiar with the current tooling GNUnet uses but at least I
remember, coming from Jenkins, Gitlab CI was heaven.

I have a minor doubt regarding wording: is everyone aware that there are
*pull requests* and *merge requests* in gitlab?

The -- in my opinion -- most common workflow in gitlab uses *merge
requests* where you develop inside a feature branch in the main
repository and then create a merge request, requesting to merge your
branch into master. The repository can be arbitrarily configured to
- allow a specific set of people to merge
- only allow merging if CI passes
- only allow merging when a certain number of approvals are given
- only allow merging once all discussions are resolved
- only allow merging when the branch is rebased on top of the target (to
allow fast-forward merges or just a clean history)
- create a fast-forward merge or create a merge commit
- (I might be missing something) ...

As I said, that is configurable, so if it's undesirable to forcibly
require two approvals by maintainers or core devs, you don't need to
enable that option. But this process is incredibly helpful to review the
scope of the whole changeset. I often review my own MR before asking
colleagues to do so. I *don't think* it is a good idea to generally
*push directly to master*. That should happen only in very few
exceptional cases.

Anyway, yes there are also forking and pull requests but tbh I have not
used those features and for day-to-day development by the "core
contributors" that already have git access on gitolite currently, I
don't think forking and pull requests should be the workflow. Granted,
for people who are new to the project and want to make some changes in
their own repo first, it's still a nice feature to have.

Hope those comments help.

Cheers,
R

[0] https://www.archive-it.org/