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

[ng0]

Schanzenbach, Martin transcribed 5.2K bytes:
> 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.

Why is it unreasonable to only use the CI?
I don't know what our angle is here. Just changing the CI? Or full conversion
to Gitlab to open up for people used to Gitlab-related workflows at the same
time / maintain less server software?
 
> > 
> > (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
> > 
> > 
> > 
> 



> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: PGP signature