Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [january-dev] overly restrictive restrictions on merging

For me, Travis is the main problem as by early afternoon UK time, jobs rarely start and so have to be left to run overnight.

Needing the branch up-to-date with master is definitely too much: as long as it merges without conflict, there will be only odd problems.

Peter


-----Original Message-----
From: january-dev-bounces@xxxxxxxxxxx [mailto:january-dev-bounces@xxxxxxxxxxx] On Behalf Of Jonah Graham
Sent: 04 April 2017 10:07
To: january developer discussions <january-dev@xxxxxxxxxxx>
Subject: [january-dev] overly restrictive restrictions on merging

Hi folks,

I have been trying the current settings where we are quite restrictive on allowing commits to be merged. Current PRs must:
- pass IP validation
- pass travis build.
- be up to date with master

However with all of these checks on together we end up with a perfect storm when more than one person is trying to work on January at the same time.

- The IP validation process does not deal with noreply@xxxxxxxxxx, but we are allowed to merge such commits, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=496885. This means if you press the "Update Branch" button, you have made your PR unmergable. The only way out is to rebase your changes. Additionally as we rebase changes on to master, these noreply commits are dropped anyway.

- The travis build can sometimes take hours to run, depending on other activity at eclipse.
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14309.html.

- Unrelated commits are effectively being treated as conflicts because of requirement to be up to date with master. Therefore if 2 people are working on unrelated code, they are constantly having to update to each other.

- If someone else (e.g. a committer) presses Update Branch, it actually modifies the submitter's git repo.

Therefore I propose that we remove the restriction on committers merging and leave it up to committer responsibility to review submissions.

Any objections?

Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
_______________________________________________
january-dev mailing list
january-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/january-dev

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom



Back to the top