| 1 |
Hi, |
| 2 |
|
| 3 |
On Mon, 18 Jul 2016 17:20:50 -0400 Rich Freeman wrote: |
| 4 |
> On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko <bircoph@g.o> wrote: |
| 5 |
> > |
| 6 |
> > On Fri, 15 Jul 2016 18:03:30 +0000 Robin H. Johnson wrote: |
| 7 |
> >> |
| 8 |
> >> The tolerances are presently set to: |
| 9 |
> >> - 5 seconds of clock drift. |
| 10 |
> > |
| 11 |
> > Set it for a minute or two. This will protect from commits from |
| 12 |
> > really out-of-sync systems (like 14 days mentioned above) and will |
| 13 |
> > keep usablity hight for others. |
| 14 |
> |
| 15 |
> I'll defer to infra on how much they can accept, but I tend to think |
| 16 |
> that we can afford to be a bit more liberal. However, I don't think |
| 17 |
> we want to accept things like systems coming out of suspend that are |
| 18 |
> off by hours. |
| 19 |
|
| 20 |
Nobody asks for hours :) 5 minutes should be fine and sane. |
| 21 |
|
| 22 |
> > |
| 23 |
> >> - 'git push' must be completed in 60 seconds. |
| 24 |
> > |
| 25 |
> > Why?! What is wrong if push will take 120 seconds? I often commit |
| 26 |
> > from quite an old box and git push takes 20-40 seconds, while this |
| 27 |
> > is within your limits, the margin is not safe. |
| 28 |
> > |
| 29 |
> > What if someone needs to commit via 2G GPRS or similar slow network |
| 30 |
> > link? Afaik we have developers on quite slow and unstable links. |
| 31 |
> > |
| 32 |
> > Just set this limit to 5 minutes to make it a sane protection of a |
| 33 |
> > stale push. |
| 34 |
> > |
| 35 |
> |
| 36 |
> Somebody can correct me if I'm wrong, but I'm pretty sure that only |
| 37 |
> one person can be pushing anything at time. |
| 38 |
|
| 39 |
Indeed so. |
| 40 |
|
| 41 |
> So, regardless of any |
| 42 |
> rsync limitations, I'm not sure we really want developers to be |
| 43 |
> spending 5 minutes doing a push. That means that if anybody else does |
| 44 |
> a commit during that 5 minutes they're going to have to rebase it. |
| 45 |
|
| 46 |
Let us consider which way we'll make more harm than good. |
| 47 |
|
| 48 |
If git push takes longer than a minute due to a slow box or a bad |
| 49 |
uplink, there is no way to fix this. If current limit will be |
| 50 |
enforced further, we'll actually ban developers with slow |
| 51 |
environment from contributing to Gentoo. |
| 52 |
|
| 53 |
As for rebasing, this is simple and can be automated by |
| 54 |
pull.rebase=true (it should be disabled during merge commits and |
| 55 |
can be done so on the command line of course, but random merge |
| 56 |
commits are not welcomed due to our git workflow policy, so this is |
| 57 |
a rare event). |
| 58 |
|
| 59 |
If I understand a reasoning behind the git push time constraint |
| 60 |
correctly, it is needed as a safeguard from stale pushes, so events |
| 61 |
where push takes > 1 minute should be very rare, thus a little harm |
| 62 |
can be done by raising git push limit to 5 minutes. |
| 63 |
|
| 64 |
Best regards, |
| 65 |
Andrew Savchenko |
Archives