You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Tolentino <jt...@apache.org> on 2006/12/19 04:19:44 UTC
Feedback Needed on Release Reporting Tool
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).
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/19/06, John Tolentino <jt...@apache.org> 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).
IMHO license auditing is quite a lot more subtle than it might first
appear: checking license headers is really only the start. there's a
lot more complexity that a release audit tool needs to cope with in
the wild.
whether maven ends up using RAT or rolling another release audit tool,
it probably makes sense to think about collaborating on some of the
problems.
for example, audit meta-data is important: a machine readable record
of the licensing and provenance of a document. it's not always right
to include a license header in a document but it's not unreasonable to
ask that every document without a header be accumpianied by audit
meta-data. rdf seems a good match for the format.
(see http://mail-archives.apache.org/mod_mbox/labs-labs/200612.mbox/%3cf470f68e0612160623n2edd7ec0q81fb51139554e6dd@mail.gmail.com%3e
thread)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Kenney Westerhof <ke...@apache.org>.
John Tolentino wrote:
[snip]
>> 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.
>
> I'll see what I can do on translating docck return values into a
> suitable report.
Ok cool.
>> 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?
>
> When asking for a vote, we're expected to supply binaries of the
> release candidate. This URL would point to that staging site.
Ah right. Should 'Download url' possibly be renamed to something like 'Release site',
since it doesn't point to a binary or a page where you can ONLY download
the binary, but provides a complete mvn site?
[snip]
>> 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?
>
> We've created standards on documenting plugins. I think it would be
> good for people to know that effort is being made to keep to those
> standards. Would also make developers mindful that we should help on
> the documentation of our work as well. Other than the plugins, it's
> not required, but i know would really be appreciated by its users.
The parent pom for all plugins should include that report then. Isn't that enough?
> On the license, aren't this required by apache since October--or
> earlier if my memory has failed me? Again, optional for other
> projects.
Yup, true, but again, a plugin declaration in the root apache/maven pom
should take care of this.
Though I see what you're doing here - you prove compliance to all demands
set by apache for a binary release on one page. Perhaps a simple list
of demands with OK/FAIL behind them, where the elements in the list point
to the report itself, is sufficient?
for instance:
<ul>
<li><a href="docck-report.html">Documentation standards</a>: OK</li>
...
</ul>
> We could make it an expandable section as well to keep things simple
> and users interested in the detailed report could click on it for
> viewing.
See above.
>> 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.
>
> I think it would be handy for people to know what fixes/new features
> are included. Can be added in the Project Reports section.
Cool.
versions on mvn sites still need some discussion; for instance a menu section
with 'previous versions', 'latest snapshot' etc. that point to complete sites
for other versions would be nice; all sites would have a version in their directory too,
and a 'current' symlink or redirect page pointing to the latest non-snapshot release.
But this should be discussed on a separate thread. (there was a thread about this a
while back but nothing came out of it IIRC).
Thanks,
Kenney
>
>>
>> -- Kenney
>>
>> >
>> > Jason.
>> >
>> >> Thanks,
>> >> John
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
> 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.
Ah! +1 That would be nice.
>
> > 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.
I'll see what I can do on translating docck return values into a
suitable report.
>
> 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?
When asking for a vote, we're expected to supply binaries of the
release candidate. This URL would point to that staging site.
>
> 'Release date: 12/10/1815' wow, i didn't think they had computers back then ;)
Agusta Ada Byron's birthday :D
> (I'd prefer ISO dates or a tztimestamp btw: 2006/12/10 or 2006/12/10 13:14:15 CEST)
I see what you mean.
>
> 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?
We've created standards on documenting plugins. I think it would be
good for people to know that effort is being made to keep to those
standards. Would also make developers mindful that we should help on
the documentation of our work as well. Other than the plugins, it's
not required, but i know would really be appreciated by its users.
On the license, aren't this required by apache since October--or
earlier if my memory has failed me? Again, optional for other
projects.
We could make it an expandable section as well to keep things simple
and users interested in the detailed report could click on it for
viewing.
>
> 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.
I think it would be handy for people to know what fixes/new features
are included. Can be added in the Project Reports section.
>
> -- Kenney
>
> >
> > Jason.
> >
> >> Thanks,
> >> John
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Kenney Westerhof <ke...@apache.org>.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
On 19 Dec 06, at 10:38 AM 19 Dec 06, John Casey wrote:
> On 12/19/06, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> 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.
>
>
>
> IMO, it needs to be more than a label. Labels can be moved in most SCM
> systems, which makes this label a floating point. While it would
> definitely
> be good to have the label in there somewhere, it also makes a lot
> of sense
> to me to have specific revisions (SVN name; versions in CVS, not
> sure what
> nomenclature is for other systems...) that identifies exactly which
> version
> of each souce file is included in the binary.
>
Yah, by "label" I mean something like the revision in SVN which is
exact.
Jason.
> Otherwise, very impressive!
>
> -john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Casey <ca...@gmail.com>.
On 12/19/06, Jason van Zyl <ja...@maven.org> wrote:
>
>
> 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.
IMO, it needs to be more than a label. Labels can be moved in most SCM
systems, which makes this label a floating point. While it would definitely
be good to have the label in there somewhere, it also makes a lot of sense
to me to have specific revisions (SVN name; versions in CVS, not sure what
nomenclature is for other systems...) that identifies exactly which version
of each souce file is included in the binary.
Otherwise, very impressive!
-john
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
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 would also link each of the resolved issues to the issue tracking
system so you can navigate from the report to the exact issue.
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.
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.
Jason.
> Thanks,
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: re[2]: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
Hi Natalie,
The logo is somewhat separate - it is part of the overall site
configuration, not a part of the report. This sample from John is
just using the current default.
I agree it is a good idea for our little built by logo to default to
one that matches the main logo on the site, it's just a separate
discussion.
Cheers,
Brett
On 28/12/2006, at 3:51 AM, <na...@simulalabs.com>
<na...@simulalabs.com> wrote:
> John
>
> What about updating the "Built with Maven" logo? I will send to you
> in separate email. Thanks!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
re[2]: Feedback Needed on Release Reporting Tool
Posted by na...@simulalabs.com.
John
What about updating the "Built with Maven" logo? I will send to you in separate email. Thanks!
Natalie
----------------------- Original Message -----------------------
From: "John Tolentino" <jt...@apache.org>
To: "Maven Developers List" <de...@maven.apache.org>
Date: Sat, 23 Dec 2006 07:13:20 +0800
Subject: Re: Feedback Needed on Release Reporting Tool
Here's version 2:
http://people.apache.org/~jtolentino/release-reports/MockReport2.html
You can also find the corresponding xdoc here:
http://people.apache.org/~jtolentino/release-reports/MockReport2.xml
I didn't change the left navigation yet as we're still deciding on
which reports gets linked to and which will be included within the
page.
On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> I see what you mean. I'll post the second version of the mock report
> and let's group it from there. :-)
>
> On 12/23/06, Brett Porter <br...@apache.org> 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)
> > - development priorities report (for developers, information on what
> > needs attention at any time)
> > - release readiness report (for developers, information on what needs
> > attention before a release can be cut)
> > - changes/release report (for users, information on what was in the
> > last release. Could also include announcement text, download links,
> > etc).
> >
> > 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.
> >
> > WDYT?
> >
> > - Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
Well, the one thing you can use in CVS is the date + branch. But I
think tagging it and then either promoting, removing or retaining the
tag is acceptable as part of the staging process for a release. You
can do the same thing in other systems.
- Brett
On 23/12/2006, at 10:28 AM, John Tolentino wrote:
> I see. So if a project is using CVS, they have to rely on their
> process having to tag a revision first. I used the revision on the
> checkout instructions in the mock reports, but like you said, this is
> only applicable to SVN.
>
> On 12/23/06, Brett Porter <br...@apache.org> wrote:
>> I don't think we can really do much special with the label - it just
>> needs to be something that won't change in that system (under the
>> assumption the user doesn't deliberately change it, we can't guard
>> against it).
>>
>> So, an SVN revision number is valid, but so is a URL to a tag, as is
>> a CVS tag, or the equivalent in another system. We can't rely on the
>> system having a unique repository revision (since CVS doesn't).
>>
>> - Brett
>>
>> On 23/12/2006, at 10:18 AM, John Tolentino wrote:
>>
>> > By the way, I need some help with the "labels" for the SCM. I'm not
>> > familiar with other SCM tools and would appreciate some
>> suggestions on
>> > how to generally approach this one.
>> >
>> > On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> >> Here's version 2:
>> >>
>> >> http://people.apache.org/~jtolentino/release-reports/
>> >> MockReport2.html
>> >>
>> >> You can also find the corresponding xdoc here:
>> >>
>> >> http://people.apache.org/~jtolentino/release-reports/
>> >> MockReport2.xml
>> >>
>> >> I didn't change the left navigation yet as we're still deciding on
>> >> which reports gets linked to and which will be included within the
>> >> page.
>> >>
>> >> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> >> > I see what you mean. I'll post the second version of the mock
>> >> report
>> >> > and let's group it from there. :-)
>> >> >
>> >> > On 12/23/06, Brett Porter <br...@apache.org> 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)
>> >> > > - development priorities report (for developers, information
>> >> on what
>> >> > > needs attention at any time)
>> >> > > - release readiness report (for developers, information on
>> >> what needs
>> >> > > attention before a release can be cut)
>> >> > > - changes/release report (for users, information on what was
>> >> in the
>> >> > > last release. Could also include announcement text, download
>> >> links,
>> >> > > etc).
>> >> > >
>> >> > > 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.
>> >> > >
>> >> > > WDYT?
>> >> > >
>> >> > > - Brett
>> >> > >
>> >> > >
>> >>
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Dec 06, at 2:03 AM 23 Dec 06, Stephane Nicoll wrote:
> Tagging the sources with a standardized scheme and use it would be the
> best for CVS I think.
>
Ultimately we decide what tool is helping with the release, the API
created for making releases must shape this information in a standard
way so that the API works. Much like Maven SCM tries to shoehorn
different concepts as best it can. Using a tag won't always work
because people can modify tags.
Jason.
> Stéphane
>
> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> I see. So if a project is using CVS, they have to rely on their
>> process having to tag a revision first. I used the revision on the
>> checkout instructions in the mock reports, but like you said, this is
>> only applicable to SVN.
>>
>> On 12/23/06, Brett Porter <br...@apache.org> wrote:
>> > I don't think we can really do much special with the label - it
>> just
>> > needs to be something that won't change in that system (under the
>> > assumption the user doesn't deliberately change it, we can't guard
>> > against it).
>> >
>> > So, an SVN revision number is valid, but so is a URL to a tag,
>> as is
>> > a CVS tag, or the equivalent in another system. We can't rely on
>> the
>> > system having a unique repository revision (since CVS doesn't).
>> >
>> > - Brett
>> >
>> > On 23/12/2006, at 10:18 AM, John Tolentino wrote:
>> >
>> > > By the way, I need some help with the "labels" for the SCM.
>> I'm not
>> > > familiar with other SCM tools and would appreciate some
>> suggestions on
>> > > how to generally approach this one.
>> > >
>> > > On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> > >> Here's version 2:
>> > >>
>> > >> http://people.apache.org/~jtolentino/release-reports/
>> > >> MockReport2.html
>> > >>
>> > >> You can also find the corresponding xdoc here:
>> > >>
>> > >> http://people.apache.org/~jtolentino/release-reports/
>> > >> MockReport2.xml
>> > >>
>> > >> I didn't change the left navigation yet as we're still
>> deciding on
>> > >> which reports gets linked to and which will be included
>> within the
>> > >> page.
>> > >>
>> > >> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> > >> > I see what you mean. I'll post the second version of the mock
>> > >> report
>> > >> > and let's group it from there. :-)
>> > >> >
>> > >> > On 12/23/06, Brett Porter <br...@apache.org> 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)
>> > >> > > - development priorities report (for developers, information
>> > >> on what
>> > >> > > needs attention at any time)
>> > >> > > - release readiness report (for developers, information on
>> > >> what needs
>> > >> > > attention before a release can be cut)
>> > >> > > - changes/release report (for users, information on what was
>> > >> in the
>> > >> > > last release. Could also include announcement text, download
>> > >> links,
>> > >> > > etc).
>> > >> > >
>> > >> > > 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.
>> > >> > >
>> > >> > > WDYT?
>> > >> > >
>> > >> > > - Brett
>> > >> > >
>> > >> > >
>> > >>
>> ---------------------------------------------------------------------
>> > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Stephane Nicoll <st...@gmail.com>.
Tagging the sources with a standardized scheme and use it would be the
best for CVS I think.
Stéphane
On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> I see. So if a project is using CVS, they have to rely on their
> process having to tag a revision first. I used the revision on the
> checkout instructions in the mock reports, but like you said, this is
> only applicable to SVN.
>
> On 12/23/06, Brett Porter <br...@apache.org> wrote:
> > I don't think we can really do much special with the label - it just
> > needs to be something that won't change in that system (under the
> > assumption the user doesn't deliberately change it, we can't guard
> > against it).
> >
> > So, an SVN revision number is valid, but so is a URL to a tag, as is
> > a CVS tag, or the equivalent in another system. We can't rely on the
> > system having a unique repository revision (since CVS doesn't).
> >
> > - Brett
> >
> > On 23/12/2006, at 10:18 AM, John Tolentino wrote:
> >
> > > By the way, I need some help with the "labels" for the SCM. I'm not
> > > familiar with other SCM tools and would appreciate some suggestions on
> > > how to generally approach this one.
> > >
> > > On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> > >> Here's version 2:
> > >>
> > >> http://people.apache.org/~jtolentino/release-reports/
> > >> MockReport2.html
> > >>
> > >> You can also find the corresponding xdoc here:
> > >>
> > >> http://people.apache.org/~jtolentino/release-reports/
> > >> MockReport2.xml
> > >>
> > >> I didn't change the left navigation yet as we're still deciding on
> > >> which reports gets linked to and which will be included within the
> > >> page.
> > >>
> > >> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> > >> > I see what you mean. I'll post the second version of the mock
> > >> report
> > >> > and let's group it from there. :-)
> > >> >
> > >> > On 12/23/06, Brett Porter <br...@apache.org> 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)
> > >> > > - development priorities report (for developers, information
> > >> on what
> > >> > > needs attention at any time)
> > >> > > - release readiness report (for developers, information on
> > >> what needs
> > >> > > attention before a release can be cut)
> > >> > > - changes/release report (for users, information on what was
> > >> in the
> > >> > > last release. Could also include announcement text, download
> > >> links,
> > >> > > etc).
> > >> > >
> > >> > > 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.
> > >> > >
> > >> > > WDYT?
> > >> > >
> > >> > > - Brett
> > >> > >
> > >> > >
> > >> ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 06, at 5:28 PM 22 Dec 06, John Tolentino wrote:
> I see. So if a project is using CVS, they have to rely on their
> process having to tag a revision first. I used the revision on the
> checkout instructions in the mock reports, but like you said, this is
> only applicable to SVN.
>
No, you can mimic with a timestamp, that's the closest you can come
to the atomic revision SVN/P4 has.
Jason.
> On 12/23/06, Brett Porter <br...@apache.org> wrote:
>> I don't think we can really do much special with the label - it just
>> needs to be something that won't change in that system (under the
>> assumption the user doesn't deliberately change it, we can't guard
>> against it).
>>
>> So, an SVN revision number is valid, but so is a URL to a tag, as is
>> a CVS tag, or the equivalent in another system. We can't rely on the
>> system having a unique repository revision (since CVS doesn't).
>>
>> - Brett
>>
>> On 23/12/2006, at 10:18 AM, John Tolentino wrote:
>>
>> > By the way, I need some help with the "labels" for the SCM. I'm not
>> > familiar with other SCM tools and would appreciate some
>> suggestions on
>> > how to generally approach this one.
>> >
>> > On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> >> Here's version 2:
>> >>
>> >> http://people.apache.org/~jtolentino/release-reports/
>> >> MockReport2.html
>> >>
>> >> You can also find the corresponding xdoc here:
>> >>
>> >> http://people.apache.org/~jtolentino/release-reports/
>> >> MockReport2.xml
>> >>
>> >> I didn't change the left navigation yet as we're still deciding on
>> >> which reports gets linked to and which will be included within the
>> >> page.
>> >>
>> >> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> >> > I see what you mean. I'll post the second version of the mock
>> >> report
>> >> > and let's group it from there. :-)
>> >> >
>> >> > On 12/23/06, Brett Porter <br...@apache.org> 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)
>> >> > > - development priorities report (for developers, information
>> >> on what
>> >> > > needs attention at any time)
>> >> > > - release readiness report (for developers, information on
>> >> what needs
>> >> > > attention before a release can be cut)
>> >> > > - changes/release report (for users, information on what was
>> >> in the
>> >> > > last release. Could also include announcement text, download
>> >> links,
>> >> > > etc).
>> >> > >
>> >> > > 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.
>> >> > >
>> >> > > WDYT?
>> >> > >
>> >> > > - Brett
>> >> > >
>> >> > >
>> >>
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
I see. So if a project is using CVS, they have to rely on their
process having to tag a revision first. I used the revision on the
checkout instructions in the mock reports, but like you said, this is
only applicable to SVN.
On 12/23/06, Brett Porter <br...@apache.org> wrote:
> I don't think we can really do much special with the label - it just
> needs to be something that won't change in that system (under the
> assumption the user doesn't deliberately change it, we can't guard
> against it).
>
> So, an SVN revision number is valid, but so is a URL to a tag, as is
> a CVS tag, or the equivalent in another system. We can't rely on the
> system having a unique repository revision (since CVS doesn't).
>
> - Brett
>
> On 23/12/2006, at 10:18 AM, John Tolentino wrote:
>
> > By the way, I need some help with the "labels" for the SCM. I'm not
> > familiar with other SCM tools and would appreciate some suggestions on
> > how to generally approach this one.
> >
> > On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> >> Here's version 2:
> >>
> >> http://people.apache.org/~jtolentino/release-reports/
> >> MockReport2.html
> >>
> >> You can also find the corresponding xdoc here:
> >>
> >> http://people.apache.org/~jtolentino/release-reports/
> >> MockReport2.xml
> >>
> >> I didn't change the left navigation yet as we're still deciding on
> >> which reports gets linked to and which will be included within the
> >> page.
> >>
> >> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> >> > I see what you mean. I'll post the second version of the mock
> >> report
> >> > and let's group it from there. :-)
> >> >
> >> > On 12/23/06, Brett Porter <br...@apache.org> 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)
> >> > > - development priorities report (for developers, information
> >> on what
> >> > > needs attention at any time)
> >> > > - release readiness report (for developers, information on
> >> what needs
> >> > > attention before a release can be cut)
> >> > > - changes/release report (for users, information on what was
> >> in the
> >> > > last release. Could also include announcement text, download
> >> links,
> >> > > etc).
> >> > >
> >> > > 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.
> >> > >
> >> > > WDYT?
> >> > >
> >> > > - Brett
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
I don't think we can really do much special with the label - it just
needs to be something that won't change in that system (under the
assumption the user doesn't deliberately change it, we can't guard
against it).
So, an SVN revision number is valid, but so is a URL to a tag, as is
a CVS tag, or the equivalent in another system. We can't rely on the
system having a unique repository revision (since CVS doesn't).
- Brett
On 23/12/2006, at 10:18 AM, John Tolentino wrote:
> By the way, I need some help with the "labels" for the SCM. I'm not
> familiar with other SCM tools and would appreciate some suggestions on
> how to generally approach this one.
>
> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> Here's version 2:
>>
>> http://people.apache.org/~jtolentino/release-reports/
>> MockReport2.html
>>
>> You can also find the corresponding xdoc here:
>>
>> http://people.apache.org/~jtolentino/release-reports/
>> MockReport2.xml
>>
>> I didn't change the left navigation yet as we're still deciding on
>> which reports gets linked to and which will be included within the
>> page.
>>
>> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> > I see what you mean. I'll post the second version of the mock
>> report
>> > and let's group it from there. :-)
>> >
>> > On 12/23/06, Brett Porter <br...@apache.org> 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)
>> > > - development priorities report (for developers, information
>> on what
>> > > needs attention at any time)
>> > > - release readiness report (for developers, information on
>> what needs
>> > > attention before a release can be cut)
>> > > - changes/release report (for users, information on what was
>> in the
>> > > last release. Could also include announcement text, download
>> links,
>> > > etc).
>> > >
>> > > 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.
>> > >
>> > > WDYT?
>> > >
>> > > - Brett
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
By the way, I need some help with the "labels" for the SCM. I'm not
familiar with other SCM tools and would appreciate some suggestions on
how to generally approach this one.
On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> Here's version 2:
>
> http://people.apache.org/~jtolentino/release-reports/MockReport2.html
>
> You can also find the corresponding xdoc here:
>
> http://people.apache.org/~jtolentino/release-reports/MockReport2.xml
>
> I didn't change the left navigation yet as we're still deciding on
> which reports gets linked to and which will be included within the
> page.
>
> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> > I see what you mean. I'll post the second version of the mock report
> > and let's group it from there. :-)
> >
> > On 12/23/06, Brett Porter <br...@apache.org> 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)
> > > - development priorities report (for developers, information on what
> > > needs attention at any time)
> > > - release readiness report (for developers, information on what needs
> > > attention before a release can be cut)
> > > - changes/release report (for users, information on what was in the
> > > last release. Could also include announcement text, download links,
> > > etc).
> > >
> > > 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.
> > >
> > > WDYT?
> > >
> > > - Brett
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 06, at 5:13 PM 22 Dec 06, John Tolentino wrote:
> Here's version 2:
>
I would still put the issues resolved on the top, I think that's what
people looking at new releases want to see first. "Was my issue
fixed?" is what they are asking.
Jason.
> http://people.apache.org/~jtolentino/release-reports/MockReport2.html
>
> You can also find the corresponding xdoc here:
>
> http://people.apache.org/~jtolentino/release-reports/MockReport2.xml
>
> I didn't change the left navigation yet as we're still deciding on
> which reports gets linked to and which will be included within the
> page.
>
> On 12/23/06, John Tolentino <jt...@apache.org> wrote:
>> I see what you mean. I'll post the second version of the mock report
>> and let's group it from there. :-)
>>
>> On 12/23/06, Brett Porter <br...@apache.org> 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)
>> > - development priorities report (for developers, information on
>> what
>> > needs attention at any time)
>> > - release readiness report (for developers, information on what
>> needs
>> > attention before a release can be cut)
>> > - changes/release report (for users, information on what was in the
>> > last release. Could also include announcement text, download links,
>> > etc).
>> >
>> > 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.
>> >
>> > WDYT?
>> >
>> > - Brett
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
Here's version 2:
http://people.apache.org/~jtolentino/release-reports/MockReport2.html
You can also find the corresponding xdoc here:
http://people.apache.org/~jtolentino/release-reports/MockReport2.xml
I didn't change the left navigation yet as we're still deciding on
which reports gets linked to and which will be included within the
page.
On 12/23/06, John Tolentino <jt...@apache.org> wrote:
> I see what you mean. I'll post the second version of the mock report
> and let's group it from there. :-)
>
> On 12/23/06, Brett Porter <br...@apache.org> 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)
> > - development priorities report (for developers, information on what
> > needs attention at any time)
> > - release readiness report (for developers, information on what needs
> > attention before a release can be cut)
> > - changes/release report (for users, information on what was in the
> > last release. Could also include announcement text, download links,
> > etc).
> >
> > 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.
> >
> > WDYT?
> >
> > - Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
I see what you mean. I'll post the second version of the mock report
and let's group it from there. :-)
On 12/23/06, Brett Porter <br...@apache.org> 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)
> - development priorities report (for developers, information on what
> needs attention at any time)
> - release readiness report (for developers, information on what needs
> attention before a release can be cut)
> - changes/release report (for users, information on what was in the
> last release. Could also include announcement text, download links,
> etc).
>
> 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.
>
> WDYT?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
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)
- development priorities report (for developers, information on what
needs attention at any time)
- release readiness report (for developers, information on what needs
attention before a release can be cut)
- changes/release report (for users, information on what was in the
last release. Could also include announcement text, download links,
etc).
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.
WDYT?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
On 12/23/06, Brett Porter <br...@apache.org> wrote:
> I like it, especially all being on one page as Jason said.
>
> Just trying to get to the bottom of the requirements... so this is
> something that would always be generated and would measure
> "releasability"? ie, you look at the page and see that there are
> still 5 issues open for the current version and docck is failing so
> it can't be released. I like it.
That's the idea, so we'd have more regular releases. For now, the
person calling for the release would have to generate the site and
stage it somewhere for people to see.
>
> I agree, I'd basically go for this approach:
> - table at the top with all the things in the report that are being
> checked, either with a "PASSED" or "FAILED".
> - subsections for each thing, linked from the summary. Include actual
> failures here for quick investigation, but for success (as well as
> failures) show the link to the actual report
I get what you mean.
>
> For the JIRA side, I'm not sure about showing # votes. I think that's
> a separate report that let's you find out what to work on when you
> aren't even considering a release. Also, I wouldn't show a list of
> closed issues (though link to it) - that's what the changes report
> should be for.
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'm thinking this is an aggregation of other reports, so we might
> consider how best to construct this, but the prototype is a great
> thing to start using now and work towards that.
>
> How does this sound?
Working on version 2 of the mock reports now. Will post it again when
I'm done consolidating the feedbacks but I'm almost done.
>
> - Brett
>
> On 19/12/2006, at 2:19 PM, 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).
> >
> > Thanks,
> > John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by Brett Porter <br...@apache.org>.
I like it, especially all being on one page as Jason said.
Just trying to get to the bottom of the requirements... so this is
something that would always be generated and would measure
"releasability"? ie, you look at the page and see that there are
still 5 issues open for the current version and docck is failing so
it can't be released. I like it.
I agree, I'd basically go for this approach:
- table at the top with all the things in the report that are being
checked, either with a "PASSED" or "FAILED".
- subsections for each thing, linked from the summary. Include actual
failures here for quick investigation, but for success (as well as
failures) show the link to the actual report
For the JIRA side, I'm not sure about showing # votes. I think that's
a separate report that let's you find out what to work on when you
aren't even considering a release. Also, I wouldn't show a list of
closed issues (though link to it) - that's what the changes report
should be for.
I'm thinking this is an aggregation of other reports, so we might
consider how best to construct this, but the prototype is a great
thing to start using now and work towards that.
How does this sound?
- Brett
On 19/12/2006, at 2:19 PM, 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).
>
> Thanks,
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feedback Needed on Release Reporting Tool
Posted by John Tolentino <jt...@apache.org>.
On 12/20/06, natalie.burdick@simulalabs.com
<na...@simulalabs.com> wrote:
> John
>
> Just a few small suggestions:
>
> In the menu on the far left:
>
> Overview
> Introduction
> Usage
> FAQ
> Examples
> Generating Votes Report
> Generating Resolved Issues Report
> Generating A Custom Report
>
> suggest:
>
> Overview
> Introduction
> Usage
> FAQs
> Examples
> Generating a Votes Report
> Generating a Resolved Issues Report
> Generating a Custom Report
http://maven.apache.org/ and other plugin sites uses FAQ. I just
followed the convention.
>
> On the the descriptor for: License Header Results -- relabeling to: Artifact License Info
>
> Also, for consistency -- some casing changes:
>
> Issues Resolved For This Release -- List of Issues Resolved in this Release
> List of deliverables -- List of Release Deliverables
Ok
>
> Lastly, how about using one of the newer Built by Maven logos?
This was generated by the maven site plugin from an xdoc file, also
used in http://maven.apache.org/
Working now on the second mock version of this report. Thanks for the
feedback. :-)
>
>
>
> ----------------------- Original Message -----------------------
>
> From: "John Tolentino" <jt...@apache.org>
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Tue, 19 Dec 2006 11:19:44 +0800
> Subject: Feedback Needed on Release Reporting Tool
>
> 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).
>
> Thanks,
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
re: Feedback Needed on Release Reporting Tool
Posted by na...@simulalabs.com.
John
Just a few small suggestions:
In the menu on the far left:
Overview
Introduction
Usage
FAQ
Examples
Generating Votes Report
Generating Resolved Issues Report
Generating A Custom Report
suggest:
Overview
Introduction
Usage
FAQs
Examples
Generating a Votes Report
Generating a Resolved Issues Report
Generating a Custom Report
On the the descriptor for: License Header Results -- relabeling to: Artifact License Info
Also, for consistency -- some casing changes:
Issues Resolved For This Release -- List of Issues Resolved in this Release
List of deliverables -- List of Release Deliverables
Lastly, how about using one of the newer Built by Maven logos?
----------------------- Original Message -----------------------
From: "John Tolentino" <jt...@apache.org>
To: "Maven Developers List" <de...@maven.apache.org>
Date: Tue, 19 Dec 2006 11:19:44 +0800
Subject: Feedback Needed on Release Reporting Tool
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).
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org