Hi!
intrigeri <intrigeri@???> writes:
> Hi,
>
> Deadline if there are no major objections: January 9. This is because
> I'd like to do this migration before we start using blueprints
> intensively again while working on sponsor deliverables.
>
> In 2015 we decided to migrate our blueprints outside of our main
> Git repository.
>
> - Be able to push more documents to our blueprints (images, office
> documents, etc.) without polluting our main repo.
> - Lock down all web editing on our main website.
> - Allow more people to push changes to blueprints through Git if they
> prefer this to the web editor.
> - Maybe some day, host our website on servers that we don't trust to
> push to tails.git.
>
> The implementation option we had chosen back then (setting up a new
> ikiwiki) relied on sysadmin work, and never happened. Meanwhile, we
> migrated to GitLab, so 2 new options are readily available to us:
>
> - GitLab wiki
> - regular (non-wiki) Git repository hosted on GitLab
>
> I've compared these 3 options on
> https://gitlab.tails.boum.org/tails/tails/-/issues/18079
Thanks for the historic view and to all involved for the research.
> IMO we can eliminate 2 of these options right away, because of deal
> breakers, and I see no such blocker for the remaining option.
> Here are the deal breakers I've spotted:
>
> - ikiwiki:
>
> - Lacks a nice syntax to link to GitLab issues, MRs, and commits
> - Requires sysadmin work to migrate and maintain
>
> - non-wiki Git repository hosted on GitLab:
>
> - Lacks an easy way to attach files; this is one major use case for
> our blueprints
> - Lacks an easy way to create or rename a page
>
> So, my questions to you today are:
>
> - Do you agree that these are deal breakers?
Yes.
> - Is there a deal breaker that I missed for the "GitLab wiki" option?
Not that I see.
