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

[Schanzenbach, Martin]

Hi,

> On 28. Jan 2019, at 00:45, Christian Grothoff <address@hidden> wrote:
> 
> Signed PGP part
> 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.

This might actually cause headaches.

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

I think this is unreasonable and the biggest pain point IMO (apart from issue 
tracking).
Well. I guess we _could_ mirror gitolite repos into gitlab. But that is dirty.
We need to scrap gitolite if we switch to gitlab.

> 
> (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
> 
> 
>

signature.asc
Description: Message signed with OpenPGP