DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
@noellabo うちだと best-friends ブランチを当時の最新から切ってて、そこにうちの変更と v*.*.* を merge していく形を取ってます。大体今の所上手くいってるし行ってきたけど、 v2.8.0 の時は Mastodon 側が master からの前進じゃないブランチ採用してたので rebase 起こって困ったりしましたね……
まず、誰かが公開してくれた便利な改造だけど、一回cherry-pickなりmergeなりするじゃん?
次の本体のリリースが来た時に、コンフリクトするワケですよ。
で、ちょっと落ち着いたら対応版を出してくれる。よし、適用しよう! ……どうやって?
--
自分でいじったコード、まぁcommitしておきますよね。で、master追従したり、次のリリースをmergeしていく。
まぁたまにコンフリクトするから直す。
これ、何回かやっているウチに最初のコミット埋もれちゃってて、あとでそこだけ取り出して別のリポジトリ(誰かにあげるとか、自分で別のサイト立ち上げるとか)に適用しようと思った時に、すごく扱いづらくなりませんか?
Github上でプルリクにしとけば拾える? どこからどこへやればいいんだろう……。
DTP鯖管
さんがブースト
こういう、わりとみんなが興味ありそうな話題だというのに、エアリプばかり。
言及を収集するとなると大変だし、みんなお互いのコメント読めなくてみんな不便じゃないの?
これってトリビアになりませんか?
DTP鯖管
さんがブースト
@noellabo 弊ぼっちインスタンスではブランチで独自改造とアップストリームからの更新を混ぜてます。
ブランチへのpushでHerokuがステージングアプリにデプロイして、ざっと動作確認してからプロダクションアプリにpromoteするようにしてます。アップストリームへの追随はfetchしてmergeしてpush https://gist.github.com/zunda/2189218dbf77e7f22c99094c567813a5 、独自改造はブランチ上で変更してpushするか、ブランチへのプルリクエストを作ってmergeすることになります。
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
Mastodonにしても、PleromaもMisskeyもみんなそうだけど、gitで最新版のソースをとってくるじゃん? 運用のために。(開発じゃなくて)
で、.gitignoreで管理対象外にしてある設定ファイルはともかく、やっぱりちょっとソースコードいじることあると思うんだけど、いじった時に、それをどのように公開したり、維持していったらいいか、こうやればいいよ!ってのある?
GitFlowとかGithubFlow、GitLabFlow、みんな開発のためのフローなのよね。
圧倒的な物量の本家の開発成果を利用し、更新に追従しながら、どこかから借りてきた改造と、自分のあてた小さなパッチ(コミット)を維持していくだけのフロー、だれか提案してない?
(私も色々考えてやっているけど、再発明してもしょうがないので)
Web上の記事でもそうだし、枠の小さい雑誌の紙面などではますますそうだけど、そもそもどこかを参照しないで自分で全部書き下せるということはないので、必ずどこかを参照先として提示しないといけないのだが……
Mastodonのサーバはいろいろあります、ここをみて下さい!ってjoinmastodon.org紹介しても、正直、覗きにきた人、帰っちゃうよね……。
Acrobat、ビジネスユーザーにとってアであるというのに、DTPユーザーにとってもアであって、担っている役割の割に、鬼っ子なのだ。
あやつ、DTPクラスタから見ると、PDFを編集できます!とか言い出す、最大の裏切り者であるw
たのむ……やめてさしあげろ……。 #dtp
DTP鯖管
さんがブースト
DTP・デザイン・印刷のテーマサーバ DTP-Mstdn.jpやってます。
#Illustrator #スクリーン印刷 #インクジェット #カラーマネジメント #運営
#searchable_by_all_users