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]
