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

[Schanzenbach, Martin]

> On 28. Jan 2019, at 12:17, address@hidden wrote:
> 
> 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?
> 

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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP