Release rbtools 0.5
Review Request #3974 — Created March 18, 2013 and submitted
| Information | |
|---|---|
| smacleod | |
| RBTools | |
| master | |
| Reviewers | |
| rbtools | |
| chipx86 | |
Release rbtools 0.5 Provide the release notes for 0.5, and bump the version number.
Built the documentation with 'make html'
| Description | From | Last Updated |
|---|---|---|
|
Two blank lines. |
 chipx86
|
|
|
"RBTools" |
chipx86
|
|
|
Maybe just say "The new rbt command line tool provides ..." |
chipx86
|
|
|
Thinking these should be, for this release, listed as a child of the "rbt" header. In fact, I'd say we … |
chipx86
|
|
|
Missing period. Same on other similar lines. |
chipx86
|
|
|
Capitalize the sentence. Comma after "optionally" |
chipx86
|
|
|
:option:`--close-type` |
chipx86
|
|
|
"Print" shouldn't be capitalized. I'd actually leave out the "standard out" bit. Too technical. "To the screen" would be fine. |
chipx86
|
|
|
:option:`--diff-revision` |
chipx86
|
|
|
post-review's |
chipx86
|
|
|
directory's |
chipx86
|
|
|
Comma after "Optionally" |
chipx86
|
|
|
"repository" |
chipx86
|
|
|
:envvar:`P4PORT` |
chipx86
|
|
|
That's an internal note. Let's not put it in the release notes. |
chipx86
|
|
|
ClearCase. This doesn't really tell me what the implications of this fix are. It should tell the user why this … |
chipx86
|
|
|
This is an internal thing only we care about (for the most part), and "shebang" is not a very commonly … |
chipx86
|
|
|
Too many blank lines. |
chipx86
|
|
|
"Perforce" |
chipx86
|
|
|
Comma after "file". "Review Board" I'd also change this sentence to be past-tense. "If you made ... Review Board would … |
chipx86
|
|
|
:command:`p4 info` |
chipx86
|
|
|
Past-tense. :command:`p4 info` Actually, this whole description is confusing and doesn't really tell me much of anything. It should be … |
chipx86
|
|
|
ClearCase. |
chipx86
|
|
|
ClearCase. This isn't so much about post-review now, so I'd say "posting review requests." Same with the description below. |
chipx86
|
|
|
"snapshot views" We shouldn't say things like "Changes were made." Rather, we should describe what the bug was. |
chipx86
|
|
|
Internal implementation. Nuke it. Users don't care. |
chipx86
|
|
|
2 blank lines. |
chipx86
|
|
|
:command:`svn` |
chipx86
|
|
|
This is going into imlementation. Just focus on what the problem was and that it's now fixed. |
chipx86
|
|
|
2 blank lines. |
chipx86
|
|
|
Internal changes aren't something we generally put in release notes. If people care, they can look at commits. Our release … |
chipx86
|
|
|
March 19 now :( |
chipx86
|
-
-
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Maybe just say "The new rbt command line tool provides ..."
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Thinking these should be, for this release, listed as a child of the "rbt" header. In fact, I'd say we should structure this like: rbt === This is the initial release of our new command line tool, rbt. It provides blah blah. There are a number of built-in sub-commands. rbt attach ~~~~~~~~~~ etc.
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Capitalize the sentence. Comma after "optionally"
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) "Print" shouldn't be capitalized. I'd actually leave out the "standard out" bit. Too technical. "To the screen" would be fine.
-
-
-
-
-
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) That's an internal note. Let's not put it in the release notes.
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) ClearCase. This doesn't really tell me what the implications of this fix are. It should tell the user why this matters.
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) This is an internal thing only we care about (for the most part), and "shebang" is not a very commonly known term (it might actually be pretty misleading). Let's nuke it.
-
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Comma after "file". "Review Board" I'd also change this sentence to be past-tense. "If you made ... Review Board would choke ..." We also shouldn't include the "suspect it's a regression" part.
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Past-tense. :command:`p4 info` Actually, this whole description is confusing and doesn't really tell me much of anything. It should be rewritten to be clear about how it impacted me as a user.
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) ClearCase. This isn't so much about post-review now, so I'd say "posting review requests." Same with the description below.
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) "snapshot views" We shouldn't say things like "Changes were made." Rather, we should describe what the bug was.
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Internal implementation. Nuke it. Users don't care.
-
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) This is going into imlementation. Just focus on what the problem was and that it's now fixed.
-
-
docs/releasenotes/rbtools/0.5.txt (Diff revision 1) Internal changes aren't something we generally put in release notes. If people care, they can look at commits. Our release notes are much more user-facing.
This is a review from Review Bot. Tool: PEP8 Style Checker Processed Files: rbtools/__init__.py Ignored Files: docs/releasenotes/rbtools/0.5.txt docs/releasenotes/rbtools/index.txt