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 <[EMAIL PROTECTED]> 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 <[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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
