かなりの過疎
ジャンゴジャ
June 09, 2010 ~ May 22, 2012
200 messages
11 (r'^media/(?P<path>.*)$', 'django.views.static.serve',
12 dict(document_root=settings.MEDIA_ROOT)),
<pre> 11 (r'^media/(?P<path>.*)$', 'django.views.static.serve', 12 dict(document_root=settings.MEDIA_ROOT)), </pre>
MEDIA_ROOT = os.path.join(BASE_PATH, 'media')
<pre>MEDIA_ROOT = os.path.join(BASE_PATH, 'media') </pre>
MEDIA_ROOT = os.path.join(BASE_PATH, 'media')
のmediarootの中身は、あっておるんですか
<pre>MEDIA_ROOT = os.path.join(BASE_PATH, 'media') のmediarootの中身は、あっておるんですか</pre>
42 (r'^static/(?P<path>.*)$',
43 'django.views.static.serve',
44 {'document_root': settings.MEDIA_ROOT}),
<pre> 42 (r'^static/(?P<path>.*)$', 43 'django.views.static.serve', 44 {'document_root': settings.MEDIA_ROOT}), </pre>
urlpatterns += patterns('',
staticほげほげ
urlpatterns = patterns('',
<pre>urlpatterns += patterns('', staticほげほげ urlpatterns = patterns('',</pre>
/static/<path> django.views.static.serve
<pre>/static/<path> django.views.static.serve </pre>
Sphinxのバージョンって _ext/djangodocs.py をアップデートすれば最新版で行ける気がする
<pre>Sphinxのバージョンって _ext/djangodocs.py をアップデートすれば最新版で行ける気がする</pre>
ローカルで確認するときに_ext/djangodocs.pyいじって頑張りました。作業する側は早めに_ext/djangodocs.pyが更新されてた方が楽かも。
<pre>ローカルで確認するときに_ext/djangodocs.pyいじって頑張りました。作業する側は早めに_ext/djangodocs.pyが更新されてた方が楽かも。</pre>
<pre>http://djangoproject.jp/doc/ja/1.0/ref/contrib/sites.html</pre>
"verbose name" が文中に複数回でると、「分かりやすい名前」というのは分かりにくくなってしまいます。
<pre>"verbose name" が文中に複数回でると、「分かりやすい名前」というのは分かりにくくなってしまいます。</pre>
うむむ、やはり_ext/djangodocs.py更新したほうが良いですか。やってみます
<pre>うむむ、やはり_ext/djangodocs.py更新したほうが良いですか。やってみます</pre>
当方 Lionにbrewしたvirtualenvに1.1.3ですが、ビルドエラーでるのでデバッグする前に質問させていただいた次第でございます。
<pre>当方 Lionにbrewしたvirtualenvに1.1.3ですが、ビルドエラーでるのでデバッグする前に質問させていただいた次第でございます。</pre>
今気づきましたが私が言ったのは django-docs-ja の話です。勘違いしてたらごめんなさい
<pre>今気づきましたが私が言ったのは django-docs-ja の話です。勘違いしてたらごめんなさい</pre>
遅くなってすみません。_ext/djangodocs.py を更新しました。
手元では Sphinx 1.1.3 でビルドできてます。
既に古いものを使っているかたは
pip install sphinx --upgrade
でアップグレードをお願いします。
<pre>遅くなってすみません。_ext/djangodocs.py を更新しました。 手元では Sphinx 1.1.3 でビルドできてます。 既に古いものを使っているかたは pip install sphinx --upgrade でアップグレードをお願いします。</pre>
@HidekiNara Sphinx 1.1.3 でビルドできるようになりましたので、すみませんがアップグレードお願いします
<pre>@HidekiNara Sphinx 1.1.3 でビルドできるようになりましたので、すみませんがアップグレードお願いします</pre>
初めまして、織田と申します。是非翻訳プロジェクトに携わりたいと思うのですが、何かに登録していただく必要はありますか?よくお世話になってる
<pre>初めまして、織田と申します。是非翻訳プロジェクトに携わりたいと思うのですが、何かに登録していただく必要はありますか?よくお世話になってる</pre>
@keiko713 初めまして、清原です。翻訳に参加したいということですね、とても嬉しいです。GitHubのdjango-docs-jaのメンバに登録しますので、まずはこちらのWikiを見てください。 https://github.com/django-docs-ja/django-docs-ja
<pre>@keiko713 初めまして、清原です。翻訳に参加したいということですね、とても嬉しいです。GitHubのdjango-docs-jaのメンバに登録しますので、まずはこちらのWikiを見てください。 https://github.com/django-docs-ja/django-docs-ja</pre>
@hirokiky 反応ありがとうございます!Wikiについてはひと通り読んで、作業内容は理解しました。自分にissueをアサインする用におそらくメンバ登録が必要かなと思いました。ということで、清原さんの代わりにどなたかぜひ!
<pre>@hirokiky 反応ありがとうございます!Wikiについてはひと通り読んで、作業内容は理解しました。自分にissueをアサインする用におそらくメンバ登録が必要かなと思いました。ということで、清原さんの代わりにどなたかぜひ!</pre>
@keiko713 GitHubのCommittersに登録しました。よろしくお願いします!
<pre>@keiko713 GitHubのCommittersに登録しました。よろしくお願いします!</pre>
@michisu 確認しました!ありがとうございます。こちろこそよろしくおねがします。 @hirokikyさんもありがとうございました。ML投げる前に気付いてもらえました :)
<pre>@michisu 確認しました!ありがとうございます。こちろこそよろしくおねがします。 @hirokikyさんもありがとうございました。ML投げる前に気付いてもらえました :)</pre>
作業の進め方について質問なのですが、wikiの手順だとpull requestしてIssueをクローズして終わりとなっていますが、pull request自体を自分自身でマージする必要はないでしょうか?いろいろ人によってやり方が違うようなので、もし新参者は要レビューなどなにかお約束があったらぜひ教えて頂けると助かります。
<pre>作業の進め方について質問なのですが、wikiの手順だとpull requestしてIssueをクローズして終わりとなっていますが、pull request自体を自分自身でマージする必要はないでしょうか?いろいろ人によってやり方が違うようなので、もし新参者は要レビューなどなにかお約束があったらぜひ教えて頂けると助かります。</pre>
@keiko713 コミット権を持っている人は自分でpushする(不安がある場合はissueをwaiting for reviewにする)、そうでない人はpull-requestを出して取り込まれるのを待つ、と想定してました。私は自信があったらpushしちゃっていいと思いますが、皆さんどうでしょうか。あとで全体の見直しは必要ですが。
<pre>@keiko713 コミット権を持っている人は自分でpushする(不安がある場合はissueをwaiting for reviewにする)、そうでない人はpull-requestを出して取り込まれるのを待つ、と想定してました。私は自信があったらpushしちゃっていいと思いますが、皆さんどうでしょうか。あとで全体の見直しは必要ですが。</pre>
コミット権を持っていない人はissueを自分にassignできないんでしたっけ。手順を考え直したほうがいいのかな
<pre>コミット権を持っていない人はissueを自分にassignできないんでしたっけ。手順を考え直したほうがいいのかな</pre>
コミット権がある場合、pushしてwaiting for reviewにするのとpull-requestの使い分けはどちらがいいでしょうね。pull-requestのほうが気がつかれやすいしコードを汚さないという利点がありますt@
<pre>コミット権がある場合、pushしてwaiting for reviewにするのとpull-requestの使い分けはどちらがいいでしょうね。pull-requestのほうが気がつかれやすいしコードを汚さないという利点がありますt@</pre>
コミット権を持っていない人はissueを自分にassignできません。なので、参画する方は基本的にコミット権を持っていると見做してもいいのではないかと思っています。
<pre>コミット権を持っていない人はissueを自分にassignできません。なので、参画する方は基本的にコミット権を持っていると見做してもいいのではないかと思っています。</pre>
私も、自身があったらpushしちゃっていい、というのには賛成です。レビューを待ちたい場合は、個人的にはpull-requestのほうがレビューもつけやすいですし、いいのではないかと思います。
<pre>私も、自身があったらpushしちゃっていい、というのには賛成です。レビューを待ちたい場合は、個人的にはpull-requestのほうがレビューもつけやすいですし、いいのではないかと思います。</pre>
ただ、必ずpull-requestで!となると今forkせずに作業してる方はちょっと面倒くさいと思うので、そのへんの兼ね合いもあると思いますが…
<pre>ただ、必ずpull-requestで!となると今forkせずに作業してる方はちょっと面倒くさいと思うので、そのへんの兼ね合いもあると思いますが…</pre>
メンバの人は issue にアサイン、push 、不安なら waiting-for-review ですかね。
<pre>メンバの人は issue にアサイン、push 、不安なら waiting-for-review ですかね。</pre>
ただ waiting-for review でなくて pull-request でもいいかなーと。あんまり深く考えていなかったです。
<pre>ただ waiting-for review でなくて pull-request でもいいかなーと。あんまり深く考えていなかったです。</pre>
メジャーな開発プロセスを知らないので聞きたいのですが、「フォーク->ブランチング->ブランチからマスターにプルリクエスト」として、「本家でブランチング->ブランチからマージ」としないのは何故でしょうか。そうしないのは本家のブランチ名が増えすぎないようにするためですか?
<pre>メジャーな開発プロセスを知らないので聞きたいのですが、「フォーク->ブランチング->ブランチからマスターにプルリクエスト」として、「本家でブランチング->ブランチからマージ」としないのは何故でしょうか。そうしないのは本家のブランチ名が増えすぎないようにするためですか?</pre>
私自身は仕事でgithubを使ったことがないですが、仕事で使っている友人の話では、「本家で各々ブランチ作成->pull-request(基本的に全てに対して要レビューのため)->pull-requestからマージ」という手順のようです。本家にブランチが大量に残ることになりますが、数ヶ月毎に古いものは削除するらしいです。今回、私も最初はそれでやろうと思ったのですが、見る限り本家に皆さんブランチを作成していなかったようなので、いつでもpull-requestしやすいように「フォーク->ブランチ作成->本家にpull-request」という手順にしました。
<pre>私自身は仕事でgithubを使ったことがないですが、仕事で使っている友人の話では、「本家で各々ブランチ作成->pull-request(基本的に全てに対して要レビューのため)->pull-requestからマージ」という手順のようです。本家にブランチが大量に残ることになりますが、数ヶ月毎に古いものは削除するらしいです。今回、私も最初はそれでやろうと思ったのですが、見る限り本家に皆さんブランチを作成していなかったようなので、いつでもpull-requestしやすいように「フォーク->ブランチ作成->本家にpull-request」という手順にしました。</pre>
ですので、個人的にはフォーク先の自分のレポジトリでブランチを作成しての作業を続けて、「自信があったらpush」という方針に決まったら、「自信があったらpull-requestを自分でマージ」という風にしようかなと思っていました。
<pre>ですので、個人的にはフォーク先の自分のレポジトリでブランチを作成しての作業を続けて、「自信があったらpush」という方針に決まったら、「自信があったらpull-requestを自分でマージ」という風にしようかなと思っていました。</pre>
そうですね、私も @hirokiky さんの意見に賛成です。ブランチ作るとまずいのかな、というのは多分ただの私の思い込みだと思うので…本家でブランチを作るほうがすっきりしますね。私も他の方の意見をぜひ聞きたいです。
<pre>そうですね、私も @hirokiky さんの意見に賛成です。ブランチ作るとまずいのかな、というのは多分ただの私の思い込みだと思うので…本家でブランチを作るほうがすっきりしますね。私も他の方の意見をぜひ聞きたいです。</pre>
その場合ブランチをpushするのと、pull-requestをマージするのって同じ権限でできますよね。自分でpull-requestをマージするのと、ローカルブランチを手元でmasterにマージしてpushするのとがそれほど変わりない。レビューしてもらいやすいという利点はありますので、同じリポジトリ内でpull-requestを発行するルールにするのはありだと思いますが、特に強制力はない感じですね
<pre>その場合ブランチをpushするのと、pull-requestをマージするのって同じ権限でできますよね。自分でpull-requestをマージするのと、ローカルブランチを手元でmasterにマージしてpushするのとがそれほど変わりない。レビューしてもらいやすいという利点はありますので、同じリポジトリ内でpull-requestを発行するルールにするのはありだと思いますが、特に強制力はない感じですね</pre>
自信があって最初から自分でマージする想定であれば、pull-requestを経ないほうがいいかなぁ。レビューを必要としているものと混ざらないように。
<pre>自信があって最初から自分でマージする想定であれば、pull-requestを経ないほうがいいかなぁ。レビューを必要としているものと混ざらないように。</pre>
本家でのブランチ可否について言えば、個々の方が本家でブランチ切って作業するのは全く問題ないと思います。ただ、まだまだ未訳部分が多いですし、システム開発と違って一つのミスで全体を破壊するリスクが低いので、1.4翻訳が完了に近づくまではmasterへの直接作業もありでいいと思っています。落ち着いてきたら安定ブランチと作業ブランチを分ければいいかなと。
<pre>本家でのブランチ可否について言えば、個々の方が本家でブランチ切って作業するのは全く問題ないと思います。ただ、まだまだ未訳部分が多いですし、システム開発と違って一つのミスで全体を破壊するリスクが低いので、1.4翻訳が完了に近づくまではmasterへの直接作業もありでいいと思っています。落ち着いてきたら安定ブランチと作業ブランチを分ければいいかなと。</pre>




