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

[Schanzenbach, Martin]

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 <address@hidden> wrote:
> 
> Signed PGP part
> 
> 
>> 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