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 |