search

netblue30 / firejail

Linux namespaces and seccomp-bpf sandbox
https://firejail.wordpress.com
GNU General Public License v2.0
5.8k stars 567 forks source link

Migrations #2729

Open chiraag-nataraj opened 5 years ago

chiraag-nataraj commented 5 years ago

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

netblue30 commented 5 years ago

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

Fred-Barclay commented 5 years ago

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

chiraag-nataraj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

TheDarkTrumpet commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Yes, all open!

rusty-snake commented 5 years ago

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 commented 5 years ago

Done! I called it wiki for simplicity.

chiraag-nataraj commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@chiraag-nataraj - re FAQ: all done!

Hocuri commented 5 years ago

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 commented 5 years ago

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

Fred-Barclay commented 5 years ago

@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 commented 5 years ago

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

rusty-snake commented 5 years ago

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 https://github.com/netblue30/firejail/issues/2208#issuecomment-431675914 (dist: bionic is possible aviable on travis)

GitLab CI

Here also GH integration is broken but builds are triggered.

LGTM

https://github.com/netblue30/firejail/pull/2851#issuecomment-510705073

GitHub Actions

https://github.com/features/actions

rusty-snake commented 4 years ago

GH-Actions is now out of beta.

rusty-snake commented 4 years ago

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

rusty-snake commented 3 years ago

Switch from Wordpress site to Github Pages #2713

  • [ ] Wordpress -> 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 commented 3 years ago
  • [ ] Wordpress -> Github Pages (#2713)

What about all the comments on the Wordpress pages?

rusty-snake commented 3 years ago

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

rusty-snake commented 3 years ago

Inputs? Anyone?

Outstanding tasks:

Update: updated task list below.

SkewedZeppelin commented 3 years ago

Inputs?

@rusty-snake

It looks fantastic so far!

Site migrations like that are very time consuming and tedious. Thanks!

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 commented 3 years ago

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

rusty-snake commented 3 years ago
kmk3 commented 3 years ago

@rusty-snake commented on Aug 13:

  • [ ] Find a solution for the comments on wordpress

For new comments: Considering the following:

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.