Re: Reproducer for failing shepherd startup

[Attila Lendvai <attila@lendvai.name>]

> > i stopped rebasing my shepherd commits. abandoning them does feel like
> > an enormous waste, but i'm cutting my losses at this point.
>
>
> You were probably right to do so.
>
> From what I remember, Ludo' did not like debugging statements all over
> the place. There was a disconnect that prevented a productive
> cooperation between Ludo' and you.


well, unless i lack some occult knowledge, the observability of shepherd is lacking badly. this is a major hindrance every time i try to debug an unexpected behavior, even as day-to-day sysadmin work.

my contribution made that substantially better, or at least so i believe, but the only feedback i got was that the log statements are "baroque"... while the logs are only part of the entire patchset that also contains extensive changes to compartmentalize exceptions and with that make shepherd much more resilient.

and these are not random hacks of passion. they were driven by real world situations while i was working on my service code.


> Also, Ludo' is probably getting ready to cut 1.0 at this point and turn
> the Shepherd over to someone for Goblins and actor enhancements. The
> code base may depart even further.
>
> It may not have been a waste, however. One day your understanding of
> the Shepherd's internals may help you to offer features the maintainer
> is excited about!


well, that assumes that my motivation is not affected by past encounters... but i have a principle that until error handling, observability, and thus debuggability of a project is good enough, i refuse to work on anything else, because i'll just waste my time in inefficient and frustrating debugging sessions.

and given that my patches were ignored that improve the above mentioned properties, let alone that they were recorded while i was working my way towards an actual fix for an actual bug... that leaves me with little motivation to hack on shepherd at this point.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Applicants must also have extensive knowledge of Unix, although they should have sufficiently good programming taste to not consider this an achievement.”
	— Hal Abelson (1947–), MIT job advertisement