On 24/12/2006, at 2:00 AM, Jason van Zyl wrote:
- 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.
Yes, I was adding a new report to complete the set. Not something
that needs to be done, just trying to be complete.
- 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
Yes, that's what I meant.
- 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.
Yes, we're talking about the same report here. The report John is
working on is really a "release readiness" report.
- 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 it's worth having separate "user" and "developer" reports.
The public don't care if docck passed, good documentation should just
be a given. I think we are getting at the same thing, though, it's
all just different views on the same data.
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 that's what I was saying too.
I think John is on the right track and that's pretty close to good
enough for a first version.
I agree. Was just a bit thrown by the inclusion of "votes" in the
issue table, since it's not really relevant once the issue is completed.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
