Hi Jaromil et al,

Thank you Jaromil for setting this up.

I suggest this list should be kept to general discussions and tasks
individual tasks should still be managed via gitlab...

However it might be good to add this list as a subscriber to gitlab and
so we can subscribe it to some of the gitlab projects so that new &
updated issues on key projects will appear here.

Anyway have some very urgent issues to deal with:

SSL certificates and HSTS.

HSTS should be disabled or reconfigured so that it doesn't infect all
subdomains of devuan.org and cause browsers that have visited some
devuan subdomains to enforce https on all devuan subdomains at the
browser.

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'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.

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.)

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.

3) If you're going to be unavailable for a period or just busy and
unable to contribute your time; make sure that you hand off your
responsibilities and current work in progress to others and make sure
that someone else has the tools and knowledge to step in and carry on in
your absence.

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.

Daniel.





On 04/04/16 05:55, Jaromil wrote:
>
>
> dears,
>
> I have finally created this list which is invite-only and includes all
> people that have made significant contributions to Devuan in a way or
> another (not just technical). I hope you don't find it odd and spare
> the modesty, the project wouldn't have been what it is today without
> your help! Please let me know if I forgot someone, so far here we are
> with me, Franco, Daniel, Alberto, Godefrius and Hellekin.
>
> we are very close to a beta release, will likely happen this month and
> we'll have then a lot of attention and perhaps things to do. Please if
> you have time take care to contribute to the documentation of what you
> did so far first and foremost...
>
> I wish you a great sunday, whatever timezone you area
> ciao!
>
>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722