Hi.

...

I'd also like to see a way to get it all in one html page so I could potentially print it. Call me old-fashioned. ;^) I'll use recycled paper.

The planned conversion to DocBook [1] should help out with this and other publishing-related issues: http://openjdk.java.net/guide/intro.html The guide is presently written in raw html. It will be converted into docbook format soon. Since we're moving to another format, I didn't spent too much time obsessing over various annoying cosmetic issues. iris [1] http://www.docbook.org/

A workflow diagram sounds useful but different. It's good detail for the person trying to navigate through the process, to figure out what to do next when something goes wrong. For my part, a quick reference guide is useful, more details than a flow chart, but less detailed than multiple pages of info. I've been developing one for myself and other compiler folk. Having it be hyperlinked into more detailed pages would be good. I'll attach the one I've been using for myself, as an example. Obviously, this one is specific to the compiler team, but you get the idea. -- Jon iris clark wrote:

Hi, Jon.

...

The Guide currently has the potential for a lot of detail about the process workflow, spread over many pages. It would also be nice to have a shorter summary "checklist" page, particularly for all the steps to get code back into a repository once you have prepared the new code. There's a lot of steps there: test, get approvals (CCC, Core), review, fix white space, create putback message, update repository (i.e. pull), create changeset, deal with conflicts, and finally, push. Phew.

Fantastic idea! As you say, there's quite a bit of text and I don't expect that people are going to want to read it often. I was hoping that the "Process Workflow" section [TBD] with associated diagrams would address most of this problem:

http://openjdk.java.net/guide/processWorkflow.html

But also I really like the idea of having up-to-date checklist(s?) which reference the more detailed portions of the guide as necessary. I could also see some kind of "Quick Reference Guide".

Do you have an initial list we can start with? From your message, I'm seeing something like this:

- test - get approvals (CCC, Core) - review - fix white space - create putback message - update repository (i.e. pull) - create changeset - deal with conflicts, - push

I know that they don't exist yet, but is this checklist just another representation for the Process Workflow diagrams?

Thanks, iris

- run regression tests jtreg -jdk:XXX -Xbootclasspath/p:javac.jar -verbose:summary -k:\!ignore -s test/tools/javac use -gui option to view results interactively, or use firefox JTreport/index.html to browse report - check for updates hg incoming - get updates hg pull hg update (or hg merge) rebuild: ant -f make/build.xml - check whitespace fixwhite.sh - review create webrev http://sa.sfbay - approvals CCC: http://ccc.sfbay, Core team - putback message <bugid>: <synopsis-of-symptom> Summary: <summary-of-code-change> Reviewed-by: <reviewer>+ # User OpenJDK user names Contributed-by: <contributor-email> # First Last <user at domain> - final check for updates; get updates, try to commit hg commit # will run jcheck if hook set up - push hg push # make sure to use tl gate repository - update bug(s) mark Fix Available

Iris, What I sent was a work in progress of things that have tripped me up one way or another, and that I've found it useful to make notes about. Think of it as one person's real world checklist. I'm more than happy for you to use it as a basis for a more general purpose checklist. :-) The bold numbered headings on the changePlanning.html page also provide a good basis for a checklist. If you took those headings, added a quick hint to each one for the commands or websites involved, with links to the full page of details, then you'd have something pretty good, I think? -- Jon iris clark wrote:

Hi, Jon.

...

For my part, a quick reference guide is useful, more details than a flow chart, but less detailed than multiple pages of info. I've been developing one for myself and other compiler folk. Having it be hyperlinked into more detailed pages would be good. I'll attach the one I've been using for myself, as an example. Obviously, this one is specific to the compiler team, but you get the idea.

Thanks for the sample. I like it, though I'd argue about the content. For instance, you list approvals after review when in fact, some people might argue that some approvals need to be started before the code is finalized for review. Also, several bug database updates are missing.

Perhaps I should enhanced the present set of steps on this page to contain a few key shell commands and references to appropriate tools:

http://openjdk.java.net/guide/changePlanning.html

Then provide a condensed version of those steps?

iris