Re: GitLab postmortem

[Carlos Soriano <csoriano gnome org>]

Now that it has settled down, thanks all for the feedback! It's really useful for me (and I believe for everyone else) to have a general feeling and what things are in common as biggest struggles and positives.

Cheers

On Wed, 2 Jan 2019 at 16:22, Germán Poo-Caamaño <gpoo gnome org> wrote:

On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list
wrote:
> On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote:
> > 3. I’d like to see continued movement towards disallowing direct
> > pushes to git, and requiring all commits to go through MRs (and
> > CI).
>
>       Hi,
> I hope this won't go through without a good research and reasoning.
>
> Any such requirement would be kind of showstopper for me personally.
> It would be just double work for me when coding (issue is not merge
> request), causing awful commit history, resulting in unbelievably
> harder effort required to produce NEWS file content (yes, I do use
> commit messages to fill the NEWS files in a semi-automated way saving
> my time, which I can spend on more productive things). To name a few
> major obstacles at least.

The history would be the same if you set up the Merge Request for your
project as "Fast-forward merge".


   "No merge commits are created and all merges are fast-forwarded,
   which means that merging is only allowed if the branch could be
   fast-forwarded.
   When fast-forward merge is not possible, the user is given the
   option to rebase."

I do also generate the NEWS file from the git history, and it is not
any different after having that change (which I did as soon as it was
possible to do).

FWIW, I do both, direct commit and MR. The former for quick commits,
and the latter if someone can jump in to review them.


> I also cannot imagine any such thing enabled for 'work-in-progress'
> branches. That would be awful for any porting/cleanup/larger efforts.

Try to not break master, and merge once the CI passes. That is the
point.

I have seen one corner case, which required to update the CI first.
Also, you can let the CI fail without blocking the MR (exceptionally or
when it is a secondary issue)

--
Germán Poo-Caamaño
http://calcifer.org/
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list