gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] estimated 0.11 release or next rc?


From: Christian Grothoff
Subject: Re: [GNUnet-developers] estimated 0.11 release or next rc?
Date: Mon, 28 Jan 2019 00:45:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 1/28/19 12:28 AM, Schanzenbach, Martin wrote:
> Hi dvn,
> 
> I had a discussion wrt gitlab offlist with grothoff as well.
> tl;dr I am also a proponent of gitlab instead of BB+mantis. Even considering 
> its problems.
> I also think that docker is a good and solid solution to keep services 
> running and up to date.
> To be honest, to me guixsd seems to me like its ready for prime time almost 
> as much as gnunet...
> 
> @grothoff: let's give it a try? It is a reasonable short-term solution.

As I thought I had made clear (to both you and dvn): if you set it up
and it works well, I won't mind ;-).  But let me elaborate:

(1) I think BB can do the CI work for us, but maybe Gitlab can work for
CI as well. I don't know enough about GitLab to be sure which one is
better for CI.

(2) I don't like integrated tools.  A bugtracker should track bugs. A CI
should do CI. I should be able to switch CI without switching bug
trackers, and vice versa. Systemd is disliked for good reasons by some
(admittedly, integration also has advantages).

(3) I am very hesitant about migrating away from Mantis. We should
update to a current version, but migration would be costly (a lot of
work) or lossy (no data migration).  I would dislike ending up with two
bug trackers.

(4) What we do affects more than GNUnet.  GNU Taler, pEp, libmicrohttpd,
GNU libextractor and other projects also depend on availability and
functionality of what we do. Please consider them as well.

(5) As for VMs/docker: I generally avoid them (unless for portability
testing), as I don't believe VMs add to security. Least priviledge does,
kvm is too close to the CPU for VMs to be considered 'least priviledge'.
If we can get Guix to deliver on its promise, we shouldn't need them to
"manage" conflicting dependencies/versioning.  VMs also badly cost
performance, and will make it harder to migrate to less powerful systems
in an emergency (i.e. HW failure). So BB buildslaves in VMs were OK, but
primary services I prefer to have managed by the primary OS
configuration, and updated regularly (and not "forgotten", which happens
too often when you run 50 VMs).  That said, until Guix is ready,
intermediary solutions are of course acceptable -- just describing my
"ideal" world.

(6) Last but not least: it is conceivable for me that we could end up:

(a) only using the CI of Gitlab, but not the bugtracker (and keep Gitolite)

(b) running the CI of Gitlab for some tasks, and BB for others (say if
Gitlab cannot be programmed freely enough for some of the CI tasks we
would like to see); that said, more tools == more work.

As for "short term solutions", anything goes. But please don't waste a
year trying to migrate the Mantis database to Gitlab to then just find
out that we need BB after all ;-).


Finally, please let me know if you need DNS entries and/or accounts
and/or reverse proxies on either machine...

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]