Hi, some more comments:
First: very nice, extremely handy for voting.
Jason van Zyl wrote:
On 18 Dec 06, at 10:19 PM 18 Dec 06, John Tolentino wrote:
Hi Everyone,
Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html
We can send this generated page to the dev list when we call for a
release.
I appreciate any feedback so I can improve the reporting (and before I
go further into implementation).
I would link the "Issues Resolved for This Release" to the roadmap in
the issue tracking system.
I agree. Maybe even use a JIRA/whateverIssueSystem embedded report (rss
feed for the jira changelog formatted in the site's style).
I would also link each of the resolved issues to the issue tracking
system so you can navigate from the report to the exact issue.
Right.
Maybe some SCM information, what system is being used and the "label"
instead of revision which is SVN specific and a link, if possible, to
that revision in the SCM. For SVN and CVS this is easy with ViewCVS.
John's comment about labels: agreed. I only know 1 system that supports labels
and that's Clearcase; labels don't specify a fixed version. Perhaps a revision
number is better, or a tag/branch. Though all those can change.
For CVS, each file has it's own version history, so you should list all
source files and their versions, though there's no easy way to check that out.
Perhaps a CVS timestamp works best in that case - there can never be 2 commits
with the same timestamp AFAIK.
That's all I can see at first glance. Though I think that getting
everything easy to see in one page is a good goal. We can link to things
like the docck report and the expanded view of deliverables. Get it all
on one page and link. If the results are OK then people most likely
won't look at them, but they can if they want. One clear page of the
state of the release would be nice.
Right. I personally don't like raw maven output on such a page - the docck
report plugin
should just generate a normal report page, preferrably embed it in this page.
What's the 'download link' for? I can see how that's useful for assembly
releases,
like maven-2.0.x-bin.tar.gz, but for plugins/other loose artifacts, would it
point
to the jar in the repository? Is that useful?
'Release date: 12/10/1815' wow, i didn't think they had computers back then ;)
(I'd prefer ISO dates or a tztimestamp btw: 2006/12/10 or 2006/12/10 13:14:15
CEST)
Another thought about the docck report: should we list that on the page at all?
I think that, and the license header stuff are just plugins that fail the build
if
the project is not compliant. So we should assume that when those plugins are
enabled/used,
the project satisfies the requirements. A link to the project (staging)site
which already
contains all the reports should be enough, right?
Also - when the release is made, will this page be available on the project
site somewhere?
So people can see the project history, examine changelogs, etc.
-- Kenney
Jason.
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
