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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [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]
