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 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 +, 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
