mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2729] Migrations #1717
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1717
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chiraag-nataraj on GitHub (May 29, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2729
Let's use this to document the proposed migrations (so we don't have a million of these floating around):
@netblue30 commented on GitHub (May 30, 2019):
I would say let's start the Wiki! I'll do some reading about it.
@Fred-Barclay commented on GitHub (May 31, 2019):
Just kidding of course -- I am a big fan of GitLab but I'm not seriously suggesting this.
@chiraag-nataraj commented on GitHub (May 31, 2019):
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 on GitHub (May 31, 2019):
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 on GitHub (May 31, 2019):
@Vincent43, yes, that would be the main reason against switching.
@TheDarkTrumpet commented on GitHub (Jun 4, 2019):
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 on GitHub (Jun 5, 2019):
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 on GitHub (Jun 5, 2019):
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 on GitHub (Jun 5, 2019):
Yes, all open!
@rusty-snake commented on GitHub (Jun 5, 2019):
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 on GitHub (Jun 5, 2019):
Done! I called it
wikifor simplicity.@chiraag-nataraj commented on GitHub (Jun 5, 2019):
@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 on GitHub (Jun 22, 2019):
@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 on GitHub (Jun 30, 2019):
@chiraag-nataraj - re FAQ: all done!
@Hocuri commented on GitHub (Jul 3, 2019):
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 on GitHub (Jul 3, 2019):
Yes, however migrating will provide better integration which will benefit the project.
@Fred-Barclay commented on GitHub (Jul 4, 2019):
@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 on GitHub (Jul 9, 2019):
re FAQ, Profiles done (need review and renaming),
Migration and ideas for Guidelines needs advice
@rusty-snake commented on GitHub (Aug 22, 2019):
Situation of CI
Travis CI
We use it actualy on travis-ci.org, builds triggered by commits, PR, ... but
dist: bionicis 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 on GitHub (Nov 20, 2019):
GH-Actions is now out of beta.
@rusty-snake commented on GitHub (Oct 1, 2020):
Now we have GH-Actions, should we remove Travis and GitLab?
@rusty-snake commented on GitHub (Nov 10, 2020):
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 insertFixed!/firejail:https://rusty-snake.github.io/download/->https://rusty-snake.github.io/firejail/download/.@SkewedZeppelin commented on GitHub (Nov 10, 2020):
What about all the comments on the Wordpress pages?
@rusty-snake commented on GitHub (Nov 10, 2020):
I was asking myself too. Perhaps we should archive the ones worth to be archived on a separate page.
@rusty-snake commented on GitHub (Dec 7, 2020):
Inputs? Anyone?
Outstanding tasks:
Update: updated task list below.
@SkewedZeppelin commented on GitHub (Dec 7, 2020):
@rusty-snake
It looks fantastic so far!
Site migrations like that are very time consuming and tedious.
Thanks!
or whatever WP calls them. But they do have an SEO value, which I assume is
their point.
like this. If anything, maybe the main header picture should be a before/after
of Firefox(/Iceweasel) instead.
That might be an uphill battle?
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 on GitHub (Mar 14, 2021):
@SkewedZeppelin: I've answered some of your questions about the blog in the issue about Wordpress.
@rusty-snake commented on GitHub (Aug 13, 2021):
https://netblue30.github.io/firejail(orhttps://firejail.github.ioif we want)@kmk3 commented on GitHub (Aug 14, 2021):
@rusty-snake commented on Aug 13:
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...
It might be better as a separate repo (either by @netblue30 or under a firejail
org), as having just a
gh-pagesbranch 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.