On Mon, 04 Apr 2016, Daniel Reurich wrote:

> Also Let-encrypt - this is a major frustration we can't afford to wait
> around for that and have broken websites for the duration. Just buy
> some certs and look at it in years time. Not being able access to
> files.devuan.org or browse packages.devuan.org for over a week is
> terrible. My clients would fire me if I let their sites do that for a
> day!!!

I absolutely second this observation. This is ridicolous and we cannot
go further waiting for lets-encrypt. I'm surprised we did so far. I'm
rather depressed and frustrated by it. Its ruining every single new
day and I'll take over the task if there is no immediate solution
tomorrow.

> I'm so tempted to quit devuan because it's just so hard to get the
> necessary stuff done (due to key people not being available and not
> making sure there are others that can step in if issues arise).
> I've spent hundreds of hours on Devuan and right now I'm so
> embarrased and ashamed at the state of our websites, and the state
> or our infrastructure that I'm considering whether to pull the plug
> on my involvement.

Daniel please do not quit. there is a serious horizon of success, lets
push it to the beta and then draw conclusions. I'm determined to
support this and if necessary to form a new team. I also know that
Franco has little time but will stick around for sure.

> Here is a start on our core infrastructure principles which are needed
> in order to sort out the "key man" problems we are having.

> 1) No Devuan server or service should have only one "key man".
> There must be a minimum of 2 active and easily contactable people
> with root access to any server. If you don't want to hand keys over
> due to concerns of exposing other non-devuan related systems, then
> it's time to move those Devuan services to a Devuan exclusive
> service or server. This goes especially for things like DNS and SSL
> cert accounts. (We should setup a team to deal with handling those
> anyway.)

agree.

I can setup the DNS handling on a git repository of zone text entries.

Also Alberto has a professional service to handle DNS and open it to
more people, he has offered to me this service already.

> 2) All Devuan code should be in gitlab - including in development code
> before deployment. This allows for better design and discussion and
> also reduces the likelyhood of "key man" issues and replication of
> efforts to solve the same problem.

agree.

> I'm sorry this is a bit of a rant, but we're close to beta and keep
> hitting and being held up by very basic issues that should make any
> VUA ashamed to be associated.

I think on your side it feels and looks worst than it is. I keep in
touch with Franco who is very responsive on urgent issues, but mostly
in Italian language since that is quicker. But you are right on all
points above and I believe we all rely and love this project enough to
make an effort and let go to put it in the middle and and the hands of
others.


but now, enough with the long term, we need a short term solution to
the SSL problem. I'm asking hellekin about this since he has been
closer following the issue, but will have to take it up myself if its
not solved tomorrow, making a certificate and changing the
configuration.


Franco: please do reply to this and enable us on DNS and all hosts,
else we'll also have to switch the domain to something else. Loosing
developers and their agency right now is the worst thing that can
happen. I have done my best to activate everyone towards beta but what
is happening in fact is the worst slow down and boycotting as
possible, I'm sure not intended, but that's the outcome of lack of
action.

ciao