アカウント名:
パスワード:
リリースをしたものの中に壊れたものが混入したことが原因だと思うのでリリースのペースも大事かもしれないけど、チェック体制的なものをどうこうしたほうがいいんじゃなのか？
リリースのペースを緩めようがどうしようが混入する可能性が否めない以上はリリースペースの問題じゃないように見えるが・・・
作業要員はそう簡単に増やせないから、リリース当たりの作業時間を延ばしてチェック体制の強化を考えてるんだろ。それで作業時間を長くとれるようにリリース間隔を広げようという話でしょう。
この程度は相手の話を聞いて説明されなくても汲み取るべき。
一般論を記述します。自動でチェックする、あるいは、壊れないような仕組みを作れば宜しい。
# 最近の人はQC活動とかしてないの？
これもその後続く一般論ですが。
では将軍様、自動でチェックしますのでチェックツールください。壊れないような仕組みを作ってください。
仕組みを作る努力もせずに、リリース間隔を延ばせばいいって判断することが安直で頭悪いという話では？
うーん、一般論としての「自動でチェックすればよい」は、猫に鈴つければいいじゃん、と同じに聞こえる、つまり、なにも解決につながらない一般論であって、「うまくやればいいじゃん」と言っているのと同じ、という指摘なのでは？
> うーん、一般論としての「自動でチェックすればよい」は、> 猫に鈴つければいいじゃん、と同じに聞こえる
そんなことを言ってるのはあんただけでは？、
私は別人だけど、私もそんな感じに聞こえる。さらに加えるなら「鈴つける努力しろ」とも。まあ、一般論で語ることが既に間違いなんだとは思うけどね。
というか自動チェックって具体的にどんなの考えてるの？テスト駆動とかそういうのしか思い浮かばないけど、それだと、じゃ、誰がテスト書くの？書いてくれるの？っていう。そんな努力するなら、そう、努力するならチェック期間伸ばせばいいじゃん。っていうか、やりたきゃ君がすればいいじゃん、っていう言い出しっぺの法則が出てくるんだけどね。
それこそ意味なくない？だって間隔広げたら解決するわけじゃないんだしさ。広げたことによる弊害とか出てくるわけだし。間隔広げてチェックの時間に余裕を持たせるってのはこの場合の解決策とは違う気がする。
なんで？作業増やすのになんでそのための時間を取ろうとしない？マゾ？ていうかどんな場合を想定してどんな解決策を想定してるの？1日で発見解決出来るようなものだよ？その時間あれば解決出来たわけだよ？あとは目の数を考慮するだけだよね？
そんなわけで、変なパッチいれちゃった→チェック期間が必要だね（リリース間隔伸びるけど）→RCだそうRC2までにしよう3ヵ月は勘弁（何の話？）いやsnapshotで……という話みたいですが。
じゃあ1日延ばせば解決だから議論する余地なくね？
あとは目の数を考慮するだけだよね？
日本だとこういうブラックジョークってなかなかわかりにくいよね。
ここでいきなりアラスカの話をされてもわからんからな。気をつけておくれよ。
目の数を確保すれば、リリース間隔は今のままてもいいんじゃね？
結局、目の数を増やすには「しょっちゅうリリース」するのが覿面なわけで、リリース間隔を広げようってわけじゃなくて、「これ外伝でナンバリングタイトルじゃないから全年齢対象でなくてもいいよね」的なリリースを導入しようって話？
また良く分からん喩えをwまあRCがリリースならそーだね頭痛が痛くない的な？
つかkernel.orgの感覚とか分からんけれども間隔くらい分かるだろ？的コメント多数？それともRCがリリースだJKむしろリリースがRCだJC的な？
間隔広げたら解決に向かえるでしょ。その時間をチェックに注ぎ込むこともできるんだしさ。
「この場合の解決策とは違う気がする」ってのは、具体的にどういうこと?
投入するヒューマンパワーの質と量に依存するものは解決策ではないって考え方が根底にあるのでは。もっと汎用性と網羅性を保障するテクニカルなロジックで解決しないと、同系別種の問題が再発します。
実際にこれでは時間が足りなくて十分にチェックできないという声が上がっていたのならともかく、そうでないのなら「これからはチェック時間を増やします」という報告は再提出させるけどなぁ。
リリース後、次のリリースまでは最低でも１ヶ月、間隔を空けるべきだ！
#目的と手段を取り違えてるって意味だと思うよ
そういう風に時間をかければ解決とかバカなこといってるから突っ込まれるんだろう。
より多くの時間を費やすのは解決策ではない対応策だよ。対応策であるからあらゆる問題に対応してマイナスにはならない万能手法でもある。なんでその程度も読み違えるのかと。
時間を費やさないことで余計に発生しうる問題を費やすことで事前に回避する効果も期待するわけだよ。そして解決策が即時適用可能ならよいが、おそらく人材を探したりツールを開発したり、解決策で新たに別の問題が発生しないかどうかの検証など時間がかかると予想される。となれば即時に適用できる万能手法たる時間をかけようという話が出てくるのは自然な流れであろう。
対応策だけで解決策をたてないからバカだといわれてるのでは？
それとも間隔を延ばすって対応策だけでなく、具合的な解決策が記事にかかれてる？
あんたの妄想でないの？
「リリース後12時間はチェック期間」とかにすれば人柱が勝手にチェックしてくれるんじゃね？安定版を欲する人はその後にダウンロードしてね♪ って。
入念にテストした筈なのに、リリース依頼出した直後、バグを見つけてしまう。
#ありすぎて困る
そこからさらに+12時間すればいい。
＃終わらねえ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
リリースのスピードが問題なのではなく (スコア:5, すばらしい洞察)
リリースをしたものの中に壊れたものが混入したことが原因だと思うので
リリースのペースも大事かもしれないけど、チェック体制的なものをどうこうしたほうがいいんじゃなのか？
リリースのペースを緩めようがどうしようが混入する可能性が否めない以上はリリースペースの問題じゃないように見えるが・・・
Re: (スコア:0)
作業要員はそう簡単に増やせないから、リリース当たりの作業時間を延ばして
チェック体制の強化を考えてるんだろ。
それで作業時間を長くとれるようにリリース間隔を広げようという話でしょう。
この程度は相手の話を聞いて説明されなくても汲み取るべき。
Re:リリースのスピードが問題なのではなく (スコア:1)
一般論を記述します。
自動でチェックする、あるいは、壊れないような仕組みを作れば宜しい。
# 最近の人はQC活動とかしてないの？
Re: (スコア:0)
これもその後続く一般論ですが。
では将軍様、
自動でチェックしますのでチェックツールください。
壊れないような仕組みを作ってください。
Re: (スコア:0)
仕組みを作る努力もせずに、リリース間隔を延ばせばいいって判断することが安直で頭悪いという話では？
Re: (スコア:0)
うーん、一般論としての「自動でチェックすればよい」は、
猫に鈴つければいいじゃん、と同じに聞こえる、つまり、なにも解決に
つながらない一般論であって、「うまくやればいいじゃん」と言っているのと
同じ、という指摘なのでは？
Re: (スコア:0)
> うーん、一般論としての「自動でチェックすればよい」は、
> 猫に鈴つければいいじゃん、と同じに聞こえる
そんなことを言ってるのはあんただけでは？、
Re: (スコア:0)
私は別人だけど、私もそんな感じに聞こえる。
さらに加えるなら「鈴つける努力しろ」とも。
まあ、一般論で語ることが既に間違いなんだとは思うけどね。
というか自動チェックって具体的にどんなの考えてるの？
テスト駆動とかそういうのしか思い浮かばないけど、それだと、じゃ、誰がテスト書くの？書いてくれるの？っていう。
そんな努力するなら、そう、努力するならチェック期間伸ばせばいいじゃん。
っていうか、やりたきゃ君がすればいいじゃん、っていう言い出しっぺの法則が出てくるんだけどね。
Re: (スコア:0)
って知らない？
Re: (スコア:0)
それこそ意味なくない？
だって間隔広げたら解決するわけじゃないんだしさ。
広げたことによる弊害とか出てくるわけだし。
間隔広げてチェックの時間に余裕を持たせるってのはこの場合の解決策とは違う気がする。
Re: (スコア:0)
なんで？作業増やすのになんでそのための時間を取ろうとしない？マゾ？
ていうかどんな場合を想定してどんな解決策を想定してるの？
1日で発見解決出来るようなものだよ？その時間あれば解決出来たわけだよ？あとは目の数を考慮するだけだよね？
そんなわけで、
変なパッチいれちゃった→チェック期間が必要だね（リリース間隔伸びるけど）→RCだそうRC2までにしよう3ヵ月は勘弁（何の話？）いやsnapshotで……
という話みたいですが。
Re: (スコア:0)
じゃあ1日延ばせば解決だから議論する余地なくね？
Re: (スコア:0)
あとは目の数を考慮するだけだよね？
Re: (スコア:0)
日本だとこういうブラックジョークってなかなかわかりにくいよね。
Re: (スコア:0)
ここでいきなりアラスカの話をされてもわからんからな。
気をつけておくれよ。
Re: (スコア:0)
目の数を確保すれば、リリース間隔は今のままてもいいんじゃね？
Re: (スコア:0)
結局、目の数を増やすには「しょっちゅうリリース」するのが覿面なわけで、
リリース間隔を広げようってわけじゃなくて、
「これ外伝でナンバリングタイトルじゃないから全年齢対象でなくてもいいよね」
的なリリースを導入しようって話？
Re: (スコア:0)
また良く分からん喩えをw
まあRCがリリースならそーだね頭痛が痛くない的な？
つかkernel.orgの感覚とか分からんけれども間隔くらい分かるだろ？的コメント多数？
それともRCがリリースだJKむしろリリースがRCだJC的な？
Re: (スコア:0)
間隔広げたら解決に向かえるでしょ。
その時間をチェックに注ぎ込むこともできるんだしさ。
「この場合の解決策とは違う気がする」ってのは、具体的にどういうこと?
Re: (スコア:0)
投入するヒューマンパワーの質と量に依存するものは解決策ではないって考え方が根底にあるのでは。
もっと汎用性と網羅性を保障するテクニカルなロジックで解決しないと、同系別種の問題が再発します。
Re: (スコア:0)
実際にこれでは時間が足りなくて十分にチェックできないという声が上がっていたのならともかく、そうでないのなら「これからはチェック時間を増やします」という報告は再提出させるけどなぁ。
全面的に同意 (スコア:0)
リリース後、次のリリースまでは最低でも１ヶ月、
間隔を空けるべきだ！
#目的と手段を取り違えてるって意味だと思うよ
Re: (スコア:0)
そういう風に時間をかければ解決とかバカなこといってるから突っ込まれるんだろう。
Re: (スコア:0)
より多くの時間を費やすのは解決策ではない対応策だよ。対応策であるからあらゆる問題に対応してマイナスにはならない万能手法でもある。なんでその程度も読み違えるのかと。
時間を費やさないことで余計に発生しうる問題を費やすことで事前に回避する効果も期待するわけだよ。
そして解決策が即時適用可能ならよいが、おそらく人材を探したりツールを開発したり、解決策で新たに別の問題が発生しないかどうかの検証など時間がかかると予想される。となれば即時に適用できる万能手法たる時間をかけようという話が出てくるのは自然な流れであろう。
Re: (スコア:0)
対応策だけで解決策をたてないからバカだといわれてるのでは？
それとも間隔を延ばすって対応策だけでなく、具合的な解決策が記事にかかれてる？
あんたの妄想でないの？
Re: (スコア:0)
「リリース後12時間はチェック期間」とかにすれば人柱が勝手にチェックしてくれるんじゃね？
安定版を欲する人はその後にダウンロードしてね♪ って。
なんたらの法則 (スコア:0)
入念にテストした筈なのに、
リリース依頼出した直後、
バグを見つけてしまう。
#ありすぎて困る
Re: (スコア:0)
そこからさらに+12時間すればいい。
＃終わらねえ…