Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Glitch-soc Yunohost app : how to join force with the mastodon app ? #146

Open
lapineige opened this issue May 21, 2019 · 19 comments

Comments

Projects
4 participants
@lapineige
Copy link
Member

commented May 21, 2019

Hello,

I'm currently thinking of (and gathering people) the creation of a Glitch-soc app for Yunohost (https://glitch-soc.github.io/docs).

I wonder in which way we could join forces between the 2 apps. As far as I understand, Glitch-soc is based on Mastodon master, and upgrading to Glitch-soc from Mastodon is as "simple" as updating Mastodon.

That said: I suppose both packages could share the same basis (installation process, nginx config and so on), while only the sources would be different.

This way both apps contributors could work on the Mastodon package (to upgrade it for instance) for let's say 90% of the work, and only some little extra work on the Glitch-soc package would be required.
I also wonder how PRs from Mastodon to Glitch-soc (and maybe the other way ?) could be managed.

What do you think ? 🙂

ping @ThibG

@ThibG

This comment has been minimized.

Copy link

commented May 21, 2019

glitch-soc closely follows Mastodon, and I can only think of very few technical differences. The most problematic things would probably be:

  • There are no glitch-soc releases
  • The assets precompilation phase is a bit more resource-intensive as we build two front-ends (one which is almost exactly upstream's, and one which is the default glitch-soc one)

The database schema diverges a bit, but nothing that cannot be migrated by going from Mastodon to glitch-soc. Migrating from any Mastodon release to glitch-soc should just be a matter of changing the source repo, checking out to the new source and do the usual migration steps.

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 21, 2019

There are no glitch-soc releases

Then how can we know that, for instance, mastodon 2.8.3 is released, and gitch-soc is now up-to-date ?

The assets precompilation phase is a bit more resource-intensive as we build two front-ends (one which is almost exactly upstream's, and one which is the default glitch-soc one)

But that only apply during first install, I guess ?

@ThibG

This comment has been minimized.

Copy link

commented May 21, 2019

There are no glitch-soc releases

Then how can we know that, for instance, mastodon 2.8.3 is released, and gitch-soc is now up-to-date ?

I guess currently you'd have to check manually. The version tag is also currently the same as it's in the most recent merge from upstream. However the version tag is usually incremented in the branches and not master.

The assets precompilation phase is a bit more resource-intensive as we build two front-ends (one which is almost exactly upstream's, and one which is the default glitch-soc one)

But that only apply during first install, I guess ?

It applies during every update involving asset changes.

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 21, 2019

However the version tag is usually incremented in the branches and not master.

You mean Glitch-soc master, right ?


So in theory, integrating Glitch-soc to Yunohost would be possible as a kind of fork of the Mastodon app repo, with some additional changes to the source ?
And it would be possible to work on the Mastodon package to update it to a new version, then apply the same changes to Glitch-soc (+ new source), without any extra work ? (apart from testing it)

@ThibG

This comment has been minimized.

Copy link

commented May 21, 2019

I mean that Mastodon patch versions are usually incremented in tootsuite (upstream) branches and not tootsuite master. glitch-soc follows tootsuite master, and we currently don't go out of our way to change the version.

I have not checked how the Yunohost package for Mastodon woks, but if it pulls the source from git, yeah, the only change I can think of is changing the repo. But since there is no release, it would need to track explicit commits instead of tagged versions.

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 21, 2019

I mean that Mastodon patch versions are usually incremented in tootsuite (upstream) branches and not tootsuite master. glitch-soc follows tootsuite master, and we currently don't go out of our way to change the version.

Oh ok, you mean that for instance branch 2.8 correspond to version 2.8, and the master to the current development version (then merged into 2.8 branch, then 2.9, and so on) ?

But since there is no release, it would need to track explicit commits instead of tagged versions.

Ok, then we would need to track which master commit is the one corresponding to [some version], and work with this commit "branch" in glitch-soc repo, did I understand it correctly ?

@yalh76

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

Hello,

I'm currently thinking of (and gathering people) the creation of a Glitch-soc app for Yunohost (https://glitch-soc.github.io/docs).

I wonder in which way we could join forces between the 2 apps. As far as I understand, Glitch-soc is based on Mastodon master, and upgrading to Glitch-soc from Mastodon is as "simple" as updating Mastodon.

That said: I suppose both packages could share the same basis (installation process, nginx config and so on), while only the sources would be different.

This way both apps contributors could work on the Mastodon package (to upgrade it for instance) for let's say 90% of the work, and only some little extra work on the Glitch-soc package would be required.
I also wonder how PRs from Mastodon to Glitch-soc (and maybe the other way ?) could be managed.

What do you think ? 🙂

ping @ThibG

I think there could be two options:

  1. make a fork of mastodon_ynh to a new package glitch-soc_ynh
  2. adding an option during mastodon_ynh install to be able to install glitch-soc as an option of mastodon
@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

adding an option during mastodon_ynh install to be able to install glitch-soc as an option of mastodon

Hey, good idea !
But I wonder if it would be clear for the users ?
I guess people wanting to install glitch-soc would already know the difference, but for classical mastodon users ?

How could we manage updates ? (and package name ?)

Comparatively, how hard would it be to manage both solutions ?

(And what about the Continuous Integration ?)

@yalh76

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

Having glitch-soc as an option for mastodon will be less explicite for the user than having is own package.

If glitch-soc follow mastodon update it will be simple just updating mastodon and glitch-soc versions in the package.

Having glitch-soc_ynh as a fork of mastodon_ynh could work also, all changes applied on mastodon_ynh can be applied on glitch-soc_ynh

For continuous integration, if glitch-soc is an option for masrodon_ynh, the best way is to test installing mastodon_ynh with the option glitch-soc, if it’s ok, that could mean that mastodon and glitch-soc are ok.

But that are just ideas, maybe i’m not enough git/mastodon/glitch-soc expert.

@yalh76 yalh76 added the question label May 22, 2019

@yalh76 yalh76 added this to To do in General via automation May 22, 2019

@yalh76 yalh76 self-assigned this May 22, 2019

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

Having glitch-soc as an option for mastodon will be less explicite for the user than having is own package.

I think so too.
If technically it's not more complicated (if we can merge all changes from Mastodon_ynh to Glitch-soc_ynh easily), then I think it's better to have 2 repos.

For continuous integration, if glitch-soc is an option for masrodon_ynh, the best way is to test installing mastodon_ynh with the option glitch-soc, if it’s ok, that could mean that mastodon and glitch-soc are ok.

Yeah, but does the CI supports this ?

@ThibG : I don't know git(hub) enough, is it possible to download the source from a github repo, from a precise commit ? And using a web URL ? (as for the releases, then we can sha256sum it and so on)

@yalh76 yalh76 removed their assignment May 22, 2019

@ThibG

This comment has been minimized.

Copy link

commented May 29, 2019

@lapineige it seems downloading https://github.com/glitch-soc/mastodon/archive/<commit-id>.zip would work, not sure if there's any rate-limiting though. There doesn't appear to be a checkshum available for this.

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

Both :
https://codeload.github.com/glitch-soc/mastodon/zip/commit/<commit-id>
https://github.com/glitch-soc/mastodon/archive/<commit-id>.zip
works for me :)

We do the checksum by ourselves, that's ok.

not sure if there's any rate-limiting though

Hum, good question… I suppose if there is a limit it won't be that low to block our users… people won't install nor upgrade that often.

Then I think we have everything needed to open a new repo, forked from this one 🙂

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

@YunoHost-Apps/apps-group how can we transfer a repo to Yunohost-app repo ?

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

Ok, I've made an initial version here: https://github.com/lapineige/glitch-soc_ynh
I'd like to transfer it in Yunohost-Apps repository before asking people to contribute.

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

@lapineige use "Transfer ownership" into Settings tab.

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

Oh… YunoHost-Apps already has a repository in the YunoHost-Apps/mastodon_ynh network
It can't work with a fork, even renamed ? :(

Should I recreate a repo ? :/
Could we use a mirror ?

@lapineige

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

Also, one thing I did not realise is that the fork can't have its own issues.
@yalh76 is that ok if the issues related to glitch-soc stay here ? (I don't want pollute you with unrelated content, even if I suppose most of the issues will be in common between the 2 repositories)

edit: my bad, this can be activated in the settings.

@yalh76

This comment has been minimized.

Copy link
Collaborator

commented Jun 12, 2019

Did this issue needs to stay open ?

@lapineige

This comment has been minimized.

Copy link
Member Author

commented Jun 12, 2019

Can we keep it open until this is setup correctly ?
(It's almost done)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.