Schanzenbach, Martin transcribed 5.2K bytes: > Hi, > > > On 28. Jan 2019, at 00:45, Christian Grothoff <[email protected]> > > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: PGP signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
