Hello,
Are you saying your solution to a submit queue for tests and IP checks being slow, is to remove it?
I think that is a backwards step. Some observations:
1.
If you merge and push up locally, then the IP bug is worked around. This basically just means that the update button on github should not be used
but the workflow is not blocked, you just to it locally. It also means that it is easier for the original PR submitted to do than other people, they just have to know to do it.
2.
Tests must pass before code is merged. If the tests are slow to run, suggest change from travis to the eclipse foundation’s Hudson. January tests
are simple and that will be <1 day to do I estimate!
All the best,
Matt
From: january-dev-bounces@xxxxxxxxxxx [mailto:january-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tracy Miranda
Sent: 04 April 2017 12:00
To: january developer discussions
Subject: Re: [january-dev] overly restrictive restrictions on merging
+1, no objections.
This is a barrier to new contributors so suggest we remedy ASAP.
On Tue, Apr 4, 2017 at 10:06 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
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
|
