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.

Sign up for GitHub

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

Jump to bottom

ミニゲーム類をこのモノレポから別のレポジトリに切り分けてほしい #13051

Open
KisaragiEffective opened this issue Jan 20, 2024 · 28 comments
Open

ミニゲーム類をこのモノレポから別のレポジトリに切り分けてほしい #13051

KisaragiEffective opened this issue Jan 20, 2024 · 28 comments
Labels
💬Discussion Being discussed or needs discussion

Comments

@KisaragiEffective
Copy link
Sponsor Member

KisaragiEffective commented Jan 20, 2024 •
edited
Loading

要旨

ミニゲーム類をこのモノレポから別のレポジトリに切り分けてほしい

動機

  1. 最小構成で動かすときのフットプリントを小さくするため
  2. ミニゲームの特定のバージョンを選択したいときに便利かもしれない
  3. ミニゲームのビルドが落ちているためにデプロイが阻害されるべきではない (←運用によっては全てのパッケージのビルドが成功しないと更新をしない、という選択をする組織があるかもしれない)

具体的な運用の提案

  1. packages/misskey-bubble-game、packages/misskey-reversi、及び将来取り込まれるであろうミニゲームをこのモノレポではなく別のレポジトリに移管する
  2. packages/以下のディレクトリはgit submoduleとしてそれらのレポジトリを参照する
  3. 参照先のレポジトリのビルドが成功する、など更新できるタイミングで更新する

運用の変更点

  • 利用者はGitからインストールする時、サブモジュールを初期化するかどうか選択する必要が生まれる (明示的に初期化しないと内容が入ってこない)
    • 多分利便性のためにgit clone --recursiveやgit submodule init --recursiveを案内することになる
  • Dockerのパッケージを少し更新する必要がある
@kakkokari-gtyih
Copy link
Contributor

kakkokari-gtyih commented Jan 20, 2024 •
edited
Loading

ゲームの一部実装はバックエンドと密結合であり、切り出すのは困難だと考えます（現在ゲームのリプレイをフロント・バック両方で再現する等の理由でゲームの演算などのロジック部分をpackageとして分離していますが、ゲーム結果の記録などはバックエンドで行う作業でしかないため分離するほどではないかと。ゲームを消すなりoptionalにしたいといった要望なら話は別ですが）

@VillSnow
Copy link

ビルドが失敗したり重かったりするのを回避したいということなら DI で ReversiService にダミーを入れられるようにするとか？
今別のサービスに入れ替えられるようになってましたっけ？

@kakkokari-gtyih kakkokari-gtyih added the 💬Discussion Being discussed or needs discussion label Jan 20, 2024
@tamaina
Copy link
Member

tamaina commented Jan 20, 2024

Q. そもそもどうして単純なものなのにビルドに失敗するのか
A. productionでビルドしようとして@typesがなくてコケる

@samunohito

This comment was marked as off-topic.

Sign in to view
@kakkokari-gtyih

This comment was marked as off-topic.

Sign in to view
@kakkokari-gtyih

This comment was marked as off-topic.

Sign in to view
@fruitriin

This comment was marked as off-topic.

Sign in to view
@kakkokari-gtyih

This comment was marked as off-topic.

Sign in to view
@samunohito

This comment was marked as off-topic.

Sign in to view
@kakkokari-gtyih

This comment was marked as off-topic.

Sign in to view
@kakkokari-gtyih kakkokari-gtyih mentioned this issue Jan 21, 2024
Closed
@KisaragiEffective
Copy link
Sponsor Member Author

現在 @syuilo 氏が麻雀を手元で実装しているようですが、レビューをせずに本体へマージすることは強く反対します。
理由は上述したとおりです。ご自身でも認められている通り、ステート数、条件ともに非常に複雑であり、第三者によるレビューを介せずにコミットした場合にデプロイラインの遅れにつながる可能性が非常に強く存在すると考えます。

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

デプロイラインの遅れ

もうすでに手遅れです

@KisaragiEffective
Copy link
Sponsor Member Author

デプロイラインの遅れ

もうすでに手遅れです

開発体制に詳しくないのですが、少なくともそれをしないことによって遅れを開かせないようにすることはできると思います。

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

少なくともそれをしないことによって遅れを開かせないようにすることはできると思います。

大変同意するけどしゅいろを止めることはほとんど誰にも不可能

@KisaragiEffective
Copy link
Sponsor Member Author

少なくともそれをしないことによって遅れを開かせないようにすることはできると思います。

大変同意するけどしゅいろを止めることはほとんど誰にも不可能

実際問題そうかもしれませんが、Request Changesを出すことで少なくとも明確に反対するという意見の表明はできると思います。

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

Request Changesを出すことで

PRを経由せずそのままマージされちゃったら太刀打ちできないわね

@KisaragiEffective
Copy link
Sponsor Member Author

その場合はRevert commitを打てばいいと思うのですが、どうでしょう？

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

そんなんクーデターやん

@KisaragiEffective
Copy link
Sponsor Member Author

KisaragiEffective commented Jan 29, 2024 •
edited
Loading

現在 @syuilo 氏が麻雀を手元で実装しているようですが、レビューをせずに本体へマージすることは強く反対します。 理由は上述したとおりです。ご自身でも認められている通り、ステート数、条件ともに非常に複雑であり、第三者によるレビューを介せずにコミットした場合にデプロイラインの遅れにつながる可能性が非常に強く存在すると考えます。

ところで、:confused: をつける理由が何かを知りたいです。

@KisaragiEffective
Copy link
Sponsor Member Author

そんなんクーデターやん

あくまで仮定の話ですが、権限をもって権限を制すという手法があると示したかっただけです。とはいえ、従前の体制は何らかの形で発展的に解消される必要があると考えています。

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

「レビューせず本体へマージする」ことと「デプロイラインの遅れにつながる」は直接関係ないかも

（デプロイラインの遅れは、麻雀の開発を一旦休憩して他のPRを幾つかマージしたらリリースすればいい話）

@KisaragiEffective
Copy link
Sponsor Member Author

直接は関係ないですが、間接的にはバグ報告の調査→PR提出→マージまでのタイムラグで遅れにつながることが考えられます。
(統計的なデータを持ち合わせていないので予想の域を出ません)

@syuilo
Copy link
Member

syuilo commented Jan 29, 2024

(ちなみにPRのレビュー・マージ含むMisskey本体の開発の休憩・やる気がない時の暇つぶしとして麻雀開発してるから自分が麻雀の開発を一旦やめたところでMisskey本体の開発が進むわけではない)

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

何がともあれ麻雀は2024.2.0に含めて欲しくない

@syuilo
Copy link
Member

syuilo commented Jan 29, 2024

多分麻雀が完成するのは2ヶ月後くらいになる

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

それはそれで永久にマージされることがなさそうな感じが…（やはり無理なのか）

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

→ #13045 (comment)

@tamaina
Copy link
Member

tamaina commented Jan 29, 2024

直接は関係ないですが、間接的にはバグ報告の調査→PR提出→マージまでのタイムラグで遅れにつながることが考えられます。
(統計的なデータを持ち合わせていないので予想の域を出ません)

バグがある程度出て直るまで最低10日かかるはず（開発期間と同程度という感じかもしれない）

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
💬Discussion Being discussed or needs discussion
Projects
[FEATURE] Misskey Games
Status: Triage
Milestone
No milestone
Development

No branches or pull requests
7 participants
@syuilo @tamaina @VillSnow @fruitriin @samunohito @KisaragiEffective @kakkokari-gtyih