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