RHELに機能拡張リクエストをだすためのノウハウ

RHELは当たり前のようにサポート窓口で機能拡張リクエストを受け付けるんですが、あまりそういうノウハウとか知られてない気がするのでメモ

ポリシー的に機能拡張が入れられるProduction 1の製品にリクエストを出す(今からならRHEL7)。

RHELにはライフサイクルポリシーがあります。この内機能拡張を入れることができるのはProduction 1とよばれる最初の4.5年間だけ。
今でているバージョンの次(時期によっては次の次)のバージョンがどのフェーズにあたるか確認すると無駄になりません。
Production 2以降では重大なバグの修正ならいいのですが機能拡張はポリシー上対応できません。

RHEL6のProduction1は2016年第2四半期におわるので、今から新規の機能をいれてと言うとほんとうにギリギリ。今からリクエストするならRHEL7が狙い目です。

できるだけ何をどうすればいいのか具体的にする(upstreamにパッチがあればそれを明記してとりこみをリクエスト) 

「それで結局何をどうしたいの？」というやりとりをやっている間に簡単に半年とかあっさり経過します。あらかじめ何をどうすればいいのか具体的なほうがよいです。

ただ自分でパッチを書くところは求められません。むしろupstreamのポリシーとずれたパッチをつくって「これ入れてくれ」というとあっさりrejectされてしまいます。対応方法ではなく目的がはっきりしていることが重要です。

リソースが潤沢にある場合にリクエストする側でできるベストの活動としては、upstreamのコミュニティに機能拡張を提案してパッチをつくりはじめ、並行してRHにリクエストをだす。というのがあります。なかなかここまでできるお客様はいらっしゃいませんが。。

そこまでできなくても「ぼくが欲しい出力のイメージはこんなの」みたいな例を書いてみるとか伝わりやすく工夫するのが大事です。

たくさんRH製品を買っている顧客の意見が重視されるのでたくさん買う(!)

文字通りです。レッドハットも商売なので。はははは。

自社ビジネスへのインパクトが大きいことを説明する

RHのサポートのあらゆる場面に言えることですが、基本的にインパクトが大きい人ほど優先して作業してもらえます。誰かの知的好奇心を満たすための説明や、審美眼的な問題、監視しづらいなどの理由だとないがしろにされ、サービスが停止してほんとうに困るという人が優先されます。

RH製品買ってない人はサポート窓口では対応できませんが  http://bugzilla.redhat.com には書けます

普通はおすすめできないのですが、bugzillaにアカウントをつくって直接レポートするという手段もあります。ただしサポート窓口経由でないというだけで優先度は地の底まで下がります。製品を買っている人はサポート窓口経由でケースを開いた方が良いです。

顧客ではない場合、対応してもらえるという約束はありません。期待せずに待ちつづける根気が必要です。お客様のサポートのついでにチラ見してもらえるくらいの気持ちで。ありがちな問題であれば顧客が同じ問題にぶつかって対応してもらえることもあります。

あきらかなバグや問題でちょろいやつならbugzillaに直接レポートしても勝算はあります。upstreamのパッチとりこみで副作用がほとんどないとかですね。

なおbugzillaにいきなり書くときには「英語しか読めないエンジニアが直接読むのだ」ということを意識して、あらかじめ明らかなバグや修正まで問題をおとしておかないと「アカウント担当にいけ、ここはサポート窓口じゃないぞ」と言われてあっさりケースがcloseされます。