Migrations

[chiraag-nataraj]

Let's use this to document the proposed migrations (so we don't have a million of these floating around):

• Travis CI -> Github Actions (Consider migrating from Travis-CI to Github Actions #2208)
• Wordpress -> Github Pages (Switch from Wordpress site to Github Pages #2713)
• Read The Docs (Our documentation #2090)
• Wiki for FAQs/tips (Github wiki for FAQs/tips? #2717)

[netblue30]

I would say let's start the Wiki! I'll do some reading about it.

[Fred-Barclay]

• GitHub -> GitLab? 😜

Just kidding of course -- I am a big fan of GitLab but I'm not seriously suggesting this.

[chiraag-nataraj]

Honestly @Fred-Barclay, we actually should consider it, in my opinion. But that's a far bigger migration than setting up a wiki or switching any of the stuff listed here...

[Vincent43]

We have build community here on github. We have quite a lot more or less active contributors. Moving to different place would mean starting from scratch.

[chiraag-nataraj]

@Vincent43, yes, that would be the main reason against switching.

[TheDarkTrumpet]

Mentioned this in the pull request, but also in #2730. I'd make use of the readme/contrib on top of the wiki, but only as the table of contents so to speak. So something along these lines:

Wiki Base: Table of contents (Use, command arguments, profiles, firecfg, etc all linked off into separate pages). Goal of the TOC (or readme, or contrib) is to be concise and fit it all in one screen. It needs to be small.
Wiki Pages: Split out into domain. Basic use (linking to advanced use from the basic use), contributing (one for profiles, one for source code contributions), and so on.

If the wiki is the best place for this, then the readme/contrib can simply be a link to the wiki page. Having documentation duplicated would create problems in keeping everything updated.

I'm pretty passionate about documentation and am more than willing to help with this.

[netblue30]

Wiki is up! It is set to allow only collaborators to write directly, I assume it goes through the regular pull request process for everybody else. Should we open it for everybody? I would go for this option.

[TheDarkTrumpet]

It looks like it's open for everyone right now, or I'm able to write to it. I'm just a collaborator, so it looks like they too can add. Added https://github.com/netblue30/firejail/wiki/Creating-Profiles based off my recent contribution.

[netblue30]

Yes, all open!

[rusty-snake]

Since I couldn't find a discuss function in the wiki, I suggest to use a separate discuss issue for each wiki page. Maybe with a new label like "wiki discussion".

[chiraag-nataraj]

Done! I called it wiki for simplicity.

[chiraag-nataraj]

@rusty-snake Good idea! Let's make a habit of creating the issue and linking to it from the ToC/main page when we create the page.

[edit] I created some instructions for editing the wiki (slightly different depending on whether we're adding a new page or editing an existing one). Feel free to edit.

[chiraag-nataraj]

@netblue30 How would you feel about transitioning the FAQ on the WordPress site to a page on the Wiki? That way, the maintenance burden isn't just on one person :)

[netblue30]

@chiraag-nataraj - re FAQ: all done!

[Hocuri]

Travis CI -> Github Actions (#2208)
Wordpress -> Github Pages (#2713)

I would do neither of these because we would depend on GitHub even more (because this would make it even more difficult up to impossible to switch to an alternative)

[Vincent43]

Yes, however migrating will provide better integration which will benefit the project.

[Fred-Barclay]

@Hocuri I agree with @Vincent43 that we'll have better integration, but there are some other benefits too I think.
We already use two CI services (Travis and GitLab). Adding a third shouldn't be an issue and actually will help quite a bit if either of the others became unviable for any reason.

I think the move from Wordpress to GitHub Pages actually helps us be more flexible too. The html source will all be publicly available and easy to hack as needed (currently @netblue30 has to make every single change). And once we have it integrated into the repo (or a separate repo?) it's pretty straightforward to move to another provider (i.e. GitLab pages) if we needed to.

So instead of making us depend on GitHub even more, I see these as giving us more flexibility and openness.

Cheers!
Fred

[matu3ba]

re FAQ, Profiles done (need review and renaming),
Migration and ideas for Guidelines needs advice

[rusty-snake]

Situation of CI

Travis CI

We use it actualy on travis-ci.org, builds triggered by commits, PR, ... but

1. the integration in GH is broken no green or red icon on commits/PRs
2. @netblue30 say: that it test only 55% of the code Consider migrating from Travis-CI to Github Actions #2208 (comment) (dist: bionic is possible aviable on travis)

GitLab CI

Here also GH integration is broken but builds are triggered.

LGTM

#2851 (comment)

GitHub Actions

https://github.com/features/actions

[rusty-snake]

GH-Actions is now out of beta.

[rusty-snake]

Now we have GH-Actions, should we remove Travis and GitLab?

[rusty-snake]

Switch from Wordpress site to Github Pages #2713

• Wordpress -> Github Pages (Switch from Wordpress site to Github Pages #2713)

I made a draft.
Source: https://github.com/rusty-snake/firejail/tree/gh-pages
View: https://rusty-snake.github.io/firejail/

Well, the links are broken ATM. You need to insert /firejail: https://rusty-snake.github.io/download/ -> https://rusty-snake.github.io/firejail/download/. Fixed!

[SkewedZeppelin]

- [ ] Wordpress -> Github Pages (#2713)

What about all the comments on the Wordpress pages?

[rusty-snake]

I was asking myself too. Perhaps we should archive the ones worth to be archived on a separate page.

[rusty-snake]

Inputs? Anyone?

Outstanding tasks:

• add the images to git and fix the links
• change the links to other wordpress sites
• the few other fixmes
• write a short CONTRIBUTING.md and README.md
• find a solution for the comments
• select a header
• push it
• update README and everything else.

Update: updated task list below.

[SkewedZeppelin]

Inputs?

@rusty-snake It looks fantastic so far! Site migrations like that are very time consuming and tedious. Thanks! - The "blog" I've always found questionable, as they are mostly just "pingbacks" or whatever WP calls them. But they do have an SEO value, which I assume is their point. - The pictures there only seem to be two of. Not all too necessary imo for a CLI like this. If anything, maybe the main header picture should be a before/after of Firefox(/Iceweasel) instead.

change the links to other wordpress sites

That might be an uphill battle?

find a solution for the comments

This is going to be difficult. And is an important communication channel for a group of users. We could fairly easily generate a simple RO archive of it, but what would replace it? The important bit about it is how low barrier it is. ie. no need to create a forum account or anything.

[tredondo]

@SkewedZeppelin: I've answered some of your questions about the blog in the issue about Wordpress.

[rusty-snake]

• Move all the images from wordpress to github
• Change all links (in the markdown files) still pointing to wordpress
• Visit all FIXMEs/TODOs
• Write a short CONTRIBUTING.md and README.md (local previewing, etc.)
• Find a solution for the comments on wordpress
• Select a title
• Update Features/*, Documentation/*, Support
• Update youtube videos
• (Optional) Fully remove G-Fonts (ATM they are blocked via CSP)
• Improve mobile view and accessibility
• Push it to https://netblue30.github.io/firejail (or https://firejail.github.io if we want)
• Update the Internet.

[kmk3]

@rusty-snake commented on Aug 13:

• Find a solution for the comments on wordpress

For new comments: Considering the following:

• The rewrite website is static
• We do not have a mailing list
• GitHub discussions is already being used

For every existing/new blog post, open a GitHub discussion and add a link to it
on the relevant post. Example: "Comment on $url".

The main disadvantage is that, unlike Wordpress, this requires an account
(i.e.: on GitHub) to comment. Commenting without accounts might be possible
with third-party embeds, such as Disqus, though personally I'd prefer to avoid
more dependencies on such services.

Sort of relevant discussion: #4456.

After this, make the Wordpress comment section read-only/delete-only.

Then, for every existing comment on the Wordpress site:

Copy the author/date/content into a new comment in the relevant discussion.

Now that I think about it, this would be one very useful use case for GitHub
discussions. If there was an easy way to embed them just like with other
commenting platforms, I'm sure many software projects would use it. I'd still
consider self-hosting and etc to be better in most cases, but if a project is
going to offload the costs to somebody else anyways...

• Push it to https://netblue30.github.io/firejail (or
  https://firejail.github.io if we want)

It might be better as a separate repo (either by @netblue30 or under a firejail
org), as having just a gh-pages branch is not very discoverable IMO. Also,
this would allow having all PRs relevant to the website in one place, and not
mixed with the PRs intended for a different codebase (i.e.: firejail itself),
which is nicer for organization IMO.

Perhaps it could be named something like "firejail-www". Anyway, I'd just
personally try to avoid using a domain name for it as domain names are not
exactly set in stone and having it differ from the actual website is a bit
confusing.