Gentoo Archives: gentoo-portage-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-portage-dev@l.g.o
Cc: Zac Medico <zmedico@g.o>
Subject: Re: [gentoo-portage-dev] [PATCH 0/4] rsync: add key refresh retry (bug 649276)
Date: Sun, 01 Apr 2018 18:30:15
Message-Id: 1522607399.2613.15.camel@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH 0/4] rsync: add key refresh retry (bug 649276) by Zac Medico
1 W dniu nie, 01.04.2018 o godzinie 08∶59 -0700, użytkownik Zac Medico
2 napisał:
3 > On 04/01/2018 03:57 AM, Michał Górny wrote:
4 > > W dniu sob, 31.03.2018 o godzinie 19∶46 -0700, użytkownik Zac Medico
5 > > napisał:
6 > > > Since key refresh is prone to failure, retry using exponential
7 > > > backoff with random jitter. This adds the following sync-openpgp-*
8 > > > configuration settings:
9 > > >
10 > > > sync-openpgp-key-refresh-retry-count = 40
11 > > >
12 > > > Maximum number of times to retry key refresh if it fails. Between
13 > > > each key refresh attempt, there is an exponential delay with a
14 > > > constant multiplier and a uniform random multiplier between 0 and 1.
15 > > >
16 > > > sync-openpgp-key-refresh-retry-delay-exp-base = 2
17 > > >
18 > > > The base of the exponential expression. The exponent is the number
19 > > > of previous refresh attempts.
20 > > >
21 > > > sync-openpgp-key-refresh-retry-delay-max = 60
22 > > >
23 > > > Maximum delay between each retry attempt, in units of seconds. This
24 > > > places a limit on the length of the exponential delay.
25 > > >
26 > > > sync-openpgp-key-refresh-retry-delay-mult = 4
27 > > >
28 > > > Multiplier for the exponential delay.
29 > > >
30 > > > sync-openpgp-key-refresh-retry-overall-timeout = 1200
31 > > >
32 > > > Combined time limit for all refresh attempts, in units of seconds.
33 > > >
34 > > > Bug: https://bugs.gentoo.org/649276
35 > > >
36 > > > Zac Medico (4):
37 > > > Add ForkExecutor (bug 649588)
38 > > > Add ExponentialBackoff and RandomExponentialBackoff
39 > > > Add retry decorator (API inspired by tenacity)
40 > > > rsync: add key refresh retry (bug 649276)
41 > > >
42 > > > cnf/repos.conf | 5 +
43 > > > man/portage.5 | 19 +++
44 > > > pym/portage/repository/config.py | 22 ++++
45 > > > pym/portage/sync/modules/rsync/rsync.py | 16 ++-
46 > > > pym/portage/sync/syncbase.py | 85 +++++++++++-
47 > > > pym/portage/tests/util/futures/test_retry.py | 147 +++++++++++++++++++++
48 > > > pym/portage/util/_eventloop/EventLoop.py | 45 ++++++-
49 > > > pym/portage/util/backoff.py | 48 +++++++
50 > > > pym/portage/util/futures/executor/__init__.py | 0
51 > > > pym/portage/util/futures/executor/fork.py | 130 +++++++++++++++++++
52 > > > pym/portage/util/futures/futures.py | 6 +
53 > > > pym/portage/util/futures/retry.py | 178 ++++++++++++++++++++++++++
54 > > > 12 files changed, 697 insertions(+), 4 deletions(-)
55 > > > create mode 100644 pym/portage/tests/util/futures/test_retry.py
56 > > > create mode 100644 pym/portage/util/backoff.py
57 > > > create mode 100644 pym/portage/util/futures/executor/__init__.py
58 > > > create mode 100644 pym/portage/util/futures/executor/fork.py
59 > > > create mode 100644 pym/portage/util/futures/retry.py
60 > > >
61 > >
62 > > This essentially looks like ~700 lines of code to try to workaround
63 > > broken networking. I would rather try to do that using 5 lines of code
64 > > but that's just me, and my programs aren't enterprise quality. I just
65 > > hope it actually solves as many problems as it's going to introduce.
66 >
67 > The vast majority of this code is generic and reusable, and I do intend
68 > to reuse it. For example, the executor support will be an essential
69 > piece for the asyncio.AbstractEventLoop for bug 649588.
70
71 Sure it is and sure you will. But tell me: who is going to maintain it
72 all? Because as far as I can see, we're still dealing with a bus factor
73 of one and all you're doing is making it worse. More code, more
74 complexity, more creeping featurism and hacks.
75
76 Last time you went away, you left us with a horribly unmaintainable
77 package manager full of complexity, hacks and creeping featurism
78 and a Portage team whose members had barely any knowledge of the code.
79 Just when things started moving again, you came back and we're back to
80 square one.
81
82 Today Portage once again is a one-developer project, full of more
83 complexity, more hacks and more creeping featurism. And we once again
84 have a bus factor of one -- one developer who apparently knows
85 everything, does everything and tries to be nice to everyone, except he
86 really ignores others, makes a lot of empty promises and consistently
87 makes the health of the project go from bad to worse.
88
89 So, please tell me: what happens when you leave again? How have you used
90 your time in the project? What have you done to make sure that
91 the project stays alive without you? Because as far as I can see, adding
92 few thousand of lines of practically unreviewed code every month does
93 not help with that.
94
95 I forked Portage because I didn't want to fight with you. When I forked
96 it, I declared that I will merge mainline changes regularly for
97 the benefit of my users. But after a week, I really start feeling like
98 that's going to be a really bad idea. Like it's time to forget about
99 mainline Portage as a completely dead end, and go our separate ways.
100
101 I'm seriously worried about the future of Gentoo. I'd really appreciate
102 if you started focusing on that as well. I get that all this stuff looks
103 cool on paper but few months or years from now, someone will curse
104 'whoever wrote that code' while trying to fix some nasty bug. Or get
105 things moving forward. Or implement EAPI 8.
106
107 --
108 Best regards,
109 Michał Górny

Replies