[announce] supervision-scripts to be retired

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Sat, 21 Nov 2015 13:35:54 -0800

Since I began what amounts to my first open source project - ever - I
have learned a lot in the process, met several interesting characters,
and hopefully provided some insights to a few others as well. To
everyone over the last year and half that have put up with me, thank you
for giving me an ad-hoc education, being patient with my silly and often
inane questions, and tolerating some of my goofy responses.

When I started supervision-scripts, I had a vision of a set of ./run
files that could be used with many different supervisors, in different
environments. It was, at the time, an admitted reactive approach to
dealing with unpleasant actions in the Linux community. I have since
changed my view and approach to this.

Along the way, I also found that there were issues that would prevent
both the completion and use of the current scripts on other
distributions. One of those problems was the use of different user
account names; different distributions use their own namings and none of
them easily align with their peers in any fashion. Another problem was
the use of daemons that required "settings after installation", which I
do not have a current provision for. To make matters worse, much has
happened in my personal life that has obstructed me from continuing work
on the current version of supervision-scripts. I have given some
thought to this, and between the current lack of time and the
constructive criticism received from various parties, I will be unable
to continue adding new definitions as I had planned.

The existing arrangement I came up with, using indirection and program
renaming, is viable for installations that use a supervisor only. At
first I thought I could incorporate it into system or state management,
but I now see that will not be possible - yet another design flaw that
prevents me from reaching the project's goals. The other issue is the
embedded user accounts used by various daemons, which currently are all
Debian-mapped, making the project still intimately tied to Debian when I
do not want it to be so.

Despite all of those limitations, it has been easy for me to create new
definitions quickly, and use them for my own purposes at home. In the
sense that this shows a proof-of-concept, it validates some of my
assumptions about making portable ./run files.

So, the current project is entering "maintenance". By this I mean that
I may occasionally add new definitions to the project but overall, there
will be no further code changes, and no changes to the structure of how
it works. The documentation will be adjusted to reflect this, along
with the current design flaws. Once the documentation is complete, the
project will "retire", rarely updating.

I still believe that process supervision has a future; that for that
future to become a reality, there needs to be an easy way for
distributions, packagers, and end-user to incorporate supervision into
existing arrangements; and that the current, easiest method for doing so
is to have pre-written definitions that can be quickly installed and
used. I am not fully admitting defeat in this process. This specific
battle was lost, but this isn't over.

As time goes on, I will take what little spare time I have left and put
it towards a new design. The design will be fully implemented "on
paper" first, and I will ask for peer review in the vain hope that more
experienced eyes besides my own will be able to discern problems on
paper before they solidify in code. This new design will incorporate
what I have learned from supervision-scripts, but it will take an
entirely different approach, one that I hope achieves the original
objective of a portable set of ./run files for supervision.

Until then, I will stay in the background, content to observe.
Received on Sat Nov 21 2015 - 21:35:54 UTC