On 22 Dec 06, at 4:48 PM 22 Dec 06, Brett Porter wrote:
On 23/12/2006, at 9:13 AM, John Tolentino wrote:
The vote is an indicator that we're prioritizing what the community
needs/wants to get fixed. I think this would be of interest for those
making a vote for the release, if the issues they want fixed will go
in.
I think these really should be two separate, but related reports.
The stable would be:
- build status report (for developers, from Continuum, things that
need immediate attention like broken build, failing tests, failing
ITs, failing checks)
This report is strictly a record of something that is ready to
release. Once all the work was done so that a vote can be presented
with it all the pertinent information. The successful docck and
verification plugin output is for completeness. Removing the manual
tedium.
- development priorities report (for developers, information on
what needs attention at any time)
This is captured in other swizzle reports and can definitely be
integrated into guides for developers. The plugin report that is
generated daily is starting to be an accurate guide for what plugin
issues people have:
http://repo1.maven.org/reports/plugins/plugin-issues.txt
- release readiness report (for developers, information on what
needs attention before a release can be cut)
They really could use the release report to check themselves.
- changes/release report (for users, information on what was in the
last release. Could also include announcement text, download links,
etc).
These could be integrated into the same report. I think this would be
good because then we have one concise report for a release. At the
point something is released all this information could be presented.
I say this as I've chatted with John and this one piece of
information could be attached to a release so that the record of what
occurred lives on in perpetuity in the repository. The reporting API
is good for outputting html right now but it's not good at
aggregating information which is what this would be. It would
essentially be a datasource being turned into an XML structure that
could be released. Eventually you have an IDE tool that can retrieve
those to browse them. Or an Archiva report to create a historical
report of releases.
I think the key differences between 2 and 3 are different handling
of JIRA. An issue with 1024 votes needs to be scheduled, but it
still shouldn't block a release (eg, it's a feature, and the
release in question is only a point release). However, a scheduled
issue for the point release will block that release and so needs to
be considered.
It wouldn't block the release, it would have already been moved out
of the version so that the road map reflected what was being worked
on for the release.
I think John is on the right track and that's pretty close to good
enough for a first version. One other interesting thing that we've
chatted about is even though we are producing xdoc right now that
could easily be reparsed into doxia events to produce the report in
anything, so a primitive merging could be done like that but the
reporting api isn't really suited for it right now.
Jason.
WDYT?
- Brett
---------------------------------------------------------------------
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]
