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