Maybe this is useful in the context of a mantis migration: https://github.com/nonplus/mantis2gitlab
> On 28. Jan 2019, at 13:40, Schanzenbach, Martin <mschanzenb...@posteo.de> > wrote: > > Signed PGP part > > >> On 28. Jan 2019, at 12:17, n...@n0.is wrote: >> >> Schanzenbach, Martin transcribed 5.2K bytes: >>> Hi, >>> >>>> On 28. Jan 2019, at 00:45, Christian Grothoff <christ...@grothoff.org> >>>> 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? >> > > Well gitlab comes with its own git service. Running gitlab + gitolite means > running two git services. Which is unreasonable. > You cannot run the gitlab CI on a remote git repo. It must be a gitlab git > repo. > So if we want to use gitlab CI we _at least_ have to mirror the gitolite > repos into it. > OTOH gitlab only really shines when used as git repo + CI + issue tracker > because of it's cross-referencing: > You can comment on commits and even individual lines, for example, and create > issues out of them. > You can also reference issues from commit messages and they get automatically > referenced in the issue w/o having to touch it. > And finally, you get the CI bells and whistles which you would have to build > yourself in BB. > > My angle would be that managing gitlab instead of BB+mantis+gitolite is: > 1. Less maintenance overhead (A single solution) > 2. Better integration (see above) > 3. Better overall quality and appearance (subjectively) > > While I really would prefer gitolite and it is a shame that you cannot use > gitolite with gitlab (anymore!) I am not impressed with mantis and BB > personally. > > >>>> >>>> (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 >>> GNUnet-developers@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers