のえる DTP鯖管 @noellabo@dtp-mstdn.jp

本家追従の運用サーバがやってるのって、本家の状態＋自分の改造なので、

アップデートの度にこの状態（本家の状態＋自分の改造）にリセットする（rebaseする）のが、考え方として正しいような気がするんだよね。

v2.8.4＋改造のブランチをrebaseで作ったら、それはそのまま公開し続けて、

v2.9.0rc1＋改造のブランチをrebaseで作ったら、それもそのまま公開し続けて、

サーバ上ではcheckoutするブランチを指定して切り替える運用にする。

master追従する場合は、追従するブランチは安定状態がないから、これはガンガン更新することにして、部外者がcherry-pickするのはご遠慮頂く。してもいいけどすぐ消える。

代わりに、リリースタグが来たらその時点のブランチを作って残していく（上述）

有用な改造は、本家にPR。取り込まれたら独自公開を中止する。

本家にマージされない類のものは、リリース＋改造ブランチで都度公開する。

これは、同一リリースにcherry-pickする限りはコンフリクトしないし、動くと期待できるので、皆が取り込みやすい。
#mastodev

今回は私もちょっと深入りして、シングルカラム対応でAdvanced UIの方も含めてCSSとDOM構造変えてしまったので、そこで不具合でたら私の仕業デス（判明したヤツは潰した／ザ・マッチポンプ） #mastodev

Mastodon、毎日地味な改善を積み上げてここまで来ています。

次はv2.9の見込みですが、目立った機能の改善の裏に、そういった地味な改善点が積み込まれているので、アプデしようね！

たとえば、こちらは、削除の転送の優先順位を下げて、安定を図るための最新コミットです。
Change priority of delete activity forwards for replies and reblogs
https://github.com/tootsuite/mastodon/commit/8746f4d17b2cfa364cbddd21c61ac06a645c4bc6

リモートのサーバで投稿が削除されると、その投稿の削除依頼が飛んできます。

Mastodonでは、その投稿が公開（PublicおよびUnlisted）で、自鯖の誰かが返信したりブーストしていた場合、他のサーバに配信していますから、責任をもって削除依頼を転送します。

まとまった数の削除依頼を受けると、それを転送するジョブがドカン！と増えます。

この転送はpushキューを使いますが、それが原因で他のジョブの送信が詰まります。

この修正では、この転送を優先度の低いpullキューに変更します。 #mastodev #mastodon

DTP鯖は、大体24時間以内の適当なタイミングでmaster追従しています。概ね半日以内です。時々masterより先行したfeature系ブランチがマージされていますw

ここ（添付画像）のfedibrird/dtp-mstdn-jpのリンクがGithubに置いてある最新のソースツリーになるようになっていて、現在はこんな感じです。
https://github.com/fedibird/dtp-mstdn-jp/tree/4f5f6131d6aabfc2fbbc031a85232158dcedfdf1

リポジトリは、Mastodon本家の最新ソースコードをベースに、独自の改造を最後にまとめて追加した状態を維持しています。コミット履歴を見ると、どんな改造を施しているか、一目で確認することができます。

ただし、常時rebaseしてpush -fしているので、毎日コミットハッシュが変わっています。ここからcherry-pickすることはお勧めしません。

別途、リリースバージョンに適用したリポジトリを用意して、コミュニティ向けにはそちらで公開する方法をとっています。（こちらについてはまた別途言及します） #mastodon #mastodev #dtp

Mastodonのユーザー設定ページを分割して整理する作業が始まっています。使いやすくなりそうですね。 #mastodev #mastodon
QT: https://mastodon.social/@Gargron/102220812706799296

その前に、今やっているPRをやっつけよう。これは例によってFedeloperで先に公開しようかな。
#mastodev #fedeloper

シングルカラムっていうだけなら足し算でいいと思うんだけど、

表示される情報を最小限にする、引き算のデザインをしているんじゃないのかな？

不慣れな人に親しみやすくするのが第一で、物足りない人はAdvanced UIにおいでっていう。

#mastodev
#でっていう

ちゃんと認識できてなかったけど、シングルカラムの編集パネル（左側の投稿フォーム）ってリプライ刷る時にフォームが画面外に追い出されて何もできなくなるとか、マジ使い物にならないトコあったんだね……。

これ、mastodon.socialでリプライしようとしたところだけど、投稿フォームが画面外にでちゃって操作できないw

ここまで深刻にヒドイとは思ってなかったよ。

これ本家に投げたPRなんだけど、一応解決してる。テストが不十分なので [WIP]（作ってる最中の意）つけてあるんだけど、それもあってか、まだレビューされてない段階。
https://github.com/tootsuite/mastodon/pull/10917

乱暴だけど、masterにmergeして皆に使ってもらいながらバグ潰していった方がいいかもしれんな……。

Done is better than perfect
多分動くと思うからリリースしようぜ
#mastodev

シングルカラム表示で、左右のパネルの縦が収まりきらない場合に、なんとか綺麗に収めよう、という提案です。

あとで本家にPR投げますが、とりあえずここにあげとくので見といてくれると助かります ＞ @mayaeh さん他、興味のあるみなさま #mastodev

リプライ元の表示は、バランスで最小は見出しだけに縮小します。×が表示されてないとキャンセルできないので、このへんが落とし所かと。

リプライ元の情報は真ん中みて下さいって感じで。

限界を超えたら画面はみ出させます。これはもうあきらめてもらう。

他、地味に、右側のナビゲーションパネルも、収まりきらない場合はスクロールするようにしてあります。

スクリーンショットはこちら。
https://dtp-mstdn.jp/@noellabo/102194143825862291

よし、だいたいできたかな……
#mastodev

これ、何が大変かって、試行錯誤がそのまま保存されているからで、追加したものをあとからキャンセルしたり、同じトコロを何度も変更したりするからなんだよね……。

変更が分割されているから大変、ということではなかったりする。綺麗に分かれていれば、分かれている方が直しやすい。
#mastodev

複数コミットで構成された改造（ローカルタイムラインをデフォルトタグのハッシュタグタイムラインにするヤツとか）って、制作時のバージョンと現在のバージョンが離れてくると、マージするのが大変過ぎるっていうか現実的じゃないんだよね。あれは一つずつやるものではない……。

squashしたコミットログに、元のコミットと作者をずらずら並べるしかないかなぁ。
#mastodev

方針変更。問題だらけのPRは撤回して（とっくに撤回している）、全体をスクロールさせよう……。

本当はこれじゃなくて、別の機能開発してたハズなのだが……cssむずいのう……。 #mastodev

さて、昨日のPRの不具合なおすか…… #mastodev

ドックフーディングの類で、シングルカラムを使い続けているけど、不便なところはやはり不便よね。

リプライ・メンションもらっても、ホームの最上段にでもいない限り、音はするけど内容が見えない。

まぁ、気が散らなくて良いという面もあるけどw #mastodev

格闘してたヤツ、プルリク投げた。

シングルカラムで、投稿フォームが下まで延びて、スクロールバー出すヤツ。
https://github.com/tootsuite/mastodon/pull/10841
#mastodev

紛れ込み #星ドラ #mastodev

絵文字追加ボタンが、スクロールすると画面外に消えちゃうんだよなぁ。順番変えて、固定方法を変更しちゃうか……。 #mastodev

いま、シングルカラムレイアウトの投稿入力するトコ（compose-form）がmax-height: 300px; で固定されてるの、不便だから、広がっていって、縦にスペース足りなくなったらスクロールバーでるようにいじっている。

ちょっと前までは、マルチカラムの時みたいに縦に延びたんだけど、そのままだと、シングルカラムって全体が縦スクロールしないので、投稿ボタンとか画面外にいっちゃって操作できなくなっちゃうのね。

それで、はみ出るから直してって言ったら、300pxに固定してくれたんだけど……。 #mastodev