зеркало из https://github.com/mozilla/pjs.git
changing the filenames during the move was a bad idea,
restore the original filenames.
This commit is contained in:
kestes%staff.mail.com
Родитель
11fcd960c1
Коммит
1eef781bbf
|
|
@ -1,226 +0,0 @@
|
|||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
|
||||
# BTData.pm - the configuration file which describes the local Bug
|
||||
# Tracking system and its relationship to the tinderbox trees.
|
||||
|
||||
|
||||
# $Revision: 1.1 $
|
||||
# $Date: 2000-11-29 20:53:35 $
|
||||
# $Author: kestes%staff.mail.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/default_conf/Attic/TicketData.pm,v $
|
||||
# $Name: $
|
||||
|
||||
|
||||
# The contents of this file are subject to the Mozilla Public
|
||||
# License Version 1.1 (the "License"); you may not use this file
|
||||
# except in compliance with the License. You may obtain a copy of
|
||||
# the License at http://www.mozilla.org/NPL/
|
||||
#
|
||||
# Software distributed under the License is distributed on an "AS
|
||||
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
|
||||
# implied. See the License for the specific language governing
|
||||
# rights and limitations under the License.
|
||||
#
|
||||
# The Original Code is the Tinderbox build tool.
|
||||
#
|
||||
# The Initial Developer of the Original Code is Netscape Communications
|
||||
# Corporation. Portions created by Netscape are
|
||||
# Copyright (C) 1998 Netscape Communications Corporation. All
|
||||
# Rights Reserved.
|
||||
#
|
||||
|
||||
# complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
|
||||
# Contributor(s):
|
||||
|
||||
|
||||
|
||||
|
||||
package BTData;
|
||||
|
||||
$VERSION = '#tinder_version#';
|
||||
|
||||
|
||||
|
||||
|
||||
# Ticket variable names match this pattern
|
||||
|
||||
# All variables seem to start with a capital letter.
|
||||
|
||||
# Note: there are some standard bugzilla variables with unusual
|
||||
# characters in them:
|
||||
#
|
||||
# Bug#: 1999
|
||||
# OS/Version:
|
||||
|
||||
# Some AIM variable names have spaces in them, we will conert these
|
||||
# into '_' after the mail is parsed.
|
||||
|
||||
$VAR_PATTERN = '[A-Z][a-zA-Z0-9._/ \#\-]*';
|
||||
|
||||
|
||||
|
||||
# the name of the bug tracking field which shows bug_id
|
||||
|
||||
#$BUGID_FIELD_NAME = 'Ticket_#';
|
||||
$BUGID_FIELD_NAME = 'Bug#';
|
||||
|
||||
|
||||
# the name of the bug tracking field which shows progress/slippage.
|
||||
|
||||
$STATUS_FIELD_NAME = 'Status';
|
||||
|
||||
|
||||
# The values of the status field wich denote that the ticket is moving
|
||||
# forward. Notice that this list may not be complete as we are only
|
||||
# interested in displaying Developer progress. If the ticket is moving
|
||||
# through QA tinderbox may not be the correct place to see that
|
||||
# change. In particular newly opend tickets are not particularly
|
||||
# interesting when monitoring the development process.
|
||||
|
||||
# All status values are converted to lower case for ease of
|
||||
# processing. Each value of this table corresponds to a bug column in
|
||||
# the tinderbox status page. You may have as many bug columns as you
|
||||
# like.
|
||||
|
||||
%STATUS_PROGRESS = (
|
||||
'ASSIGNED' => 'Progress',
|
||||
'VERIFIED' => 'Progress',
|
||||
|
||||
'REOPENED' => 'Slipage',
|
||||
'FAILED' => 'Slipage',
|
||||
'OPENED' => 'Slipage',
|
||||
'NEW' => 'Slipage',
|
||||
);
|
||||
|
||||
|
||||
# Uncomment only the fields you wish displayed in the popup window,
|
||||
# The fields will be displayed in the order they are listed here.
|
||||
# Only uncomment fields which are interesting. Fields which are empty
|
||||
# will still be displayed.
|
||||
|
||||
@DISPLAY_FIELDS = (
|
||||
|
||||
# Tinderbox created fields
|
||||
|
||||
#'tinderbox_status',
|
||||
#'tinderbox_bug_id',
|
||||
#'tinderbox_tree',
|
||||
#'tinderbox_bug_url',
|
||||
|
||||
# Bugzilla fields
|
||||
|
||||
'Bug#',
|
||||
'Product',
|
||||
'Version',
|
||||
'Platform',
|
||||
'OS/Version',
|
||||
'Status',
|
||||
'Resolution',
|
||||
'Severity',
|
||||
'Priority',
|
||||
'Component',
|
||||
'AssignedTo',
|
||||
'ReportedBy',
|
||||
#'URL',
|
||||
#'Cc',
|
||||
'Summary',
|
||||
|
||||
|
||||
# AIM Fields
|
||||
|
||||
# (these names are configurable and come from the
|
||||
# appearance of mail messages. We always convert
|
||||
# spaces to '_'.)
|
||||
|
||||
|
||||
# 'Ticket_#',
|
||||
# 'Date_Open',
|
||||
# 'Product_Name',
|
||||
# 'Product_Sub_System',
|
||||
# 'Product_Version',
|
||||
# 'Severity',
|
||||
# 'Status',
|
||||
# 'Closed_Date',
|
||||
# 'User_Login',
|
||||
# 'E-Mail',
|
||||
# 'Support_Staff_Login',
|
||||
# 'Support_Staff_E-Mail',
|
||||
# 'Last_Modified_Date',
|
||||
# 'Short_Description',
|
||||
|
||||
);
|
||||
|
||||
|
||||
# Given a pointer to a bug update hash return the name of the tree to
|
||||
# which this bug report belongs. Typically this will be the contents
|
||||
# of a field like 'Product', however some projects may be more
|
||||
# compicated. One example of a complex function would be if each of
|
||||
# the product product types listed in the bug tracking data base
|
||||
# refers to one development project except for a particular
|
||||
# feature/platform of one particular project which is being developed
|
||||
# by a separate group of developers. So the version control notion of
|
||||
# tress (a set of modules on a branch) may not have a direct map into
|
||||
# the bug tracking database at all times.
|
||||
|
||||
# This function should return 'undef' if the bug report should be
|
||||
# ignored by the tinderbox server.
|
||||
|
||||
|
||||
sub update2tree {
|
||||
my ($tinderbox_ref) = @_;
|
||||
|
||||
$out = (
|
||||
$tinderbox_ref->{'Product'}.
|
||||
"");
|
||||
|
||||
# It might be a good idea to call TreeData::tree_exists() and ensure
|
||||
# that this tree is valid, but this would make it harder for testing
|
||||
# using genbugs.
|
||||
|
||||
return $out;
|
||||
}
|
||||
|
||||
|
||||
# Given a pointer to a bug_update_hash return a URL ('href') to the
|
||||
# bug. If the bug tracker does not support URL's to a bug number,
|
||||
# return a 'mailto: ' to someone who cares about the bug.
|
||||
|
||||
sub update2bug_url {
|
||||
my ($tinderbox_ref) = @_;
|
||||
|
||||
# AIM can not accept bug numbers as URLS without encoding lots of
|
||||
# other junk (logged in user name, session id info). Just give a
|
||||
# 'mailto: ' for the link instead.
|
||||
|
||||
# $out = (
|
||||
# 'mailto: '.
|
||||
# $tinderbox_ref{'User_Login'}.
|
||||
# "");
|
||||
|
||||
# Bugzilla has an easy format for making URL's of bugs
|
||||
|
||||
$out = (
|
||||
'http://bugzilla.mozilla.org/show_bug.cgi?id='.
|
||||
$tinderbox_ref->{$BTData::BUGID_FIELD_NAME}.
|
||||
"");
|
||||
|
||||
return $out;
|
||||
}
|
||||
|
||||
|
||||
sub get_all_progress_states {
|
||||
|
||||
my (@progress_states) = main::uniq( values %BTData::STATUS_PROGRESS );
|
||||
|
||||
return @progress_states;
|
||||
}
|
||||
|
||||
sub is_status_valid {
|
||||
my ($status) = @_;
|
||||
|
||||
my $out = defined($STATUS_PROGRESS{$status});
|
||||
|
||||
return $out;
|
||||
}
|
||||
|
||||
1;
|
||||
|
|
@ -1,248 +0,0 @@
|
|||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
|
||||
# TreeData.pm - the configuration file which describes the local VC
|
||||
# repository data. Only TinderDB::VC and VCDisplay know the
|
||||
# datastructure contained in this file. Other modules can only check
|
||||
# if a string is a valid tree name or can get the list of all valid
|
||||
# trees through functional interfaces. Also this file store the list
|
||||
# of valid tree states. The TreeState is used as an informational
|
||||
# message only it does not directly effect the operation of the
|
||||
# version control system. The TreeState is manipulated via the
|
||||
# TinderHeader interface.
|
||||
|
||||
# This data used to be configurable via the treeadmin interface but we
|
||||
# do not support that. The format of this data depends on the version
|
||||
# control system in use and abstraction prevents treeadmin.cgi from
|
||||
# knowing those details. I may code a TreeData specific admin-CGI
|
||||
# script in the future but I do not have time now and the benefits are
|
||||
# not so clear. For bonsai users it would be best if the DB stored
|
||||
# the tree data. The tinderbox server could download the data from a
|
||||
# central place when it first starts up, and this down load could
|
||||
# trigger a registration for email updates of changes to any trees
|
||||
# which this tinderbox server is monitoring. As long as the data is
|
||||
# stored in a file, it is safer to have this data stored in VC in its
|
||||
# own file, in case of problems. The data tends to be technical
|
||||
# enough that this file is managed by a Jr Sysadmin and they prefer a
|
||||
# text editor with CVS to a CGI script and no records. Also the
|
||||
# client side build script needs to know how to checkout a tree and
|
||||
# map tree names to what was checked out, so there is a communication
|
||||
# issue to work out.
|
||||
|
||||
|
||||
# $Revision: 1.1 $
|
||||
# $Date: 2000-11-29 20:53:45 $
|
||||
# $Author: kestes%staff.mail.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/default_conf/Attic/VCData.pm,v $
|
||||
# $Name: $
|
||||
|
||||
|
||||
# The contents of this file are subject to the Mozilla Public
|
||||
# License Version 1.1 (the "License"); you may not use this file
|
||||
# except in compliance with the License. You may obtain a copy of
|
||||
# the License at http://www.mozilla.org/NPL/
|
||||
#
|
||||
# Software distributed under the License is distributed on an "AS
|
||||
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
|
||||
# implied. See the License for the specific language governing
|
||||
# rights and limitations under the License.
|
||||
#
|
||||
# The Original Code is the Tinderbox build tool.
|
||||
#
|
||||
# The Initial Developer of the Original Code is Netscape Communications
|
||||
# Corporation. Portions created by Netscape are
|
||||
# Copyright (C) 1998 Netscape Communications Corporation. All
|
||||
# Rights Reserved.
|
||||
#
|
||||
|
||||
# complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
|
||||
# Contributor(s):
|
||||
|
||||
|
||||
|
||||
|
||||
package TreeData;
|
||||
|
||||
$VERSION = '#tinder_version#';
|
||||
|
||||
|
||||
# Each tree is a map from a name to all the information necessary to
|
||||
# do a checkout of the sources (in this case cvs repository to
|
||||
# checkout, module, branch needed) and to create a URL to display the
|
||||
# page (if such a means exists). Tree names are used as parts of
|
||||
# filenames so should not contain ' ' or '/' or unprintable
|
||||
# characters. You may need to change this datastructure if you do not
|
||||
# use CVS.
|
||||
|
||||
# Who uses tree data?
|
||||
|
||||
# Only the VCDisplay and TinderDB::VC know what the internal structure
|
||||
# of the tree hash is. All other modules only need to use the name of
|
||||
# a valid tree.
|
||||
|
||||
# Also the client side build script needs to know how to checkout a
|
||||
# tree.
|
||||
|
||||
|
||||
#------------------------------------------------------------------
|
||||
|
||||
|
||||
# This section describes some functionality issues when using
|
||||
# VC_CVS.pm and is not applicable to Bonsai users.
|
||||
|
||||
|
||||
# The 'cvs history' command does not give correct info about
|
||||
# modifications to the repository (types= 'ARM') when passed a module
|
||||
# name, it was only designed to work on individual files. If you use
|
||||
# the -m option you will not find any info about checkins. We leave
|
||||
# off the module name and take the info for the whole repository
|
||||
# instead. If this becomes a bother we can reject information about
|
||||
# updates which do not match a pattern. In this respect the pattern
|
||||
# becomes a proxy for the module. The pattern is stored in
|
||||
# $TreeData::VC_TREE{$tree}{'dir_pattern'}.
|
||||
|
||||
# There is nothing I can think of to get information about which
|
||||
# branch the changes were checked in on. The history command also has
|
||||
# no notion of branches, but that is a common problem with the way CVS
|
||||
# does branching anyway.
|
||||
|
||||
# What we really want it the checkin comments but history does not
|
||||
# give us that information and it would be too expensive to run cvs
|
||||
# again for each file. The file name is good enough but other VC
|
||||
# implementations should use the checkin comments if available.
|
||||
|
||||
# dir_pattern: Reject all CVS update file names which do not match
|
||||
# this pattern. This is only used by VC_CVS.pm and not by Bonsai.
|
||||
# This is a hack to get around the fact that CVS does not always
|
||||
# understand the module structure, and 'cvs history' will report all
|
||||
# updates to a repository even for modules not of interest to us. So
|
||||
# if you use VC_CVS.pm the module value will not be passed to CVS. If
|
||||
# the user can describe what is in the module using a perl pattern
|
||||
# then VC_CVS.pm can implement lost CVS module functionality in the
|
||||
# perl code.
|
||||
|
||||
# module: Although VC_CVS ignores this variable you should still set
|
||||
# it because it is clearer (a tree is supposed to map to a module) and
|
||||
# for practical reasons (the VC_Display may use it an CVS may allow
|
||||
# proper use in the future).
|
||||
|
||||
|
||||
#------------------------------------------------------------------
|
||||
|
||||
|
||||
# It may interest you to know we are currently using this format to
|
||||
# build sets of locally developed libraries. Each tree is really a
|
||||
# set of CVS modules which need to be built in some order due to
|
||||
# dependencies on the modules. The build script knows how to do this.
|
||||
# As far as tinderbox is concerned the tree is a single CVS module
|
||||
# which checks out the whole set of modules. The rest of development
|
||||
# thinks of a tree as a set of modules.
|
||||
|
||||
|
||||
|
||||
%VC_TREE = (
|
||||
# SeaMonkey => {
|
||||
# root => ':pserver:anonymous@'.
|
||||
# 'cvs-mirror.mozilla.org:'.
|
||||
# '/cvsroot',
|
||||
#
|
||||
# root => '/devel/java_repository',
|
||||
#
|
||||
# module => 'SeaMonkeyAll',
|
||||
# branch => 'main',
|
||||
# dir_pattern => '^/mozilla',
|
||||
# },
|
||||
|
||||
# these are dummy trees for testing.
|
||||
|
||||
'Project_A' => {
|
||||
root => ':pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot',
|
||||
module => 'SeaMonkeyAll',
|
||||
branch => 'main',
|
||||
},
|
||||
'Project_B' => {
|
||||
root => ':pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot',
|
||||
module => 'Grendel',
|
||||
branch => 'main',
|
||||
},
|
||||
'Project_C' => {
|
||||
root => ':pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot',
|
||||
module => 'NSPR',
|
||||
branch => 'main',
|
||||
},
|
||||
|
||||
);
|
||||
|
||||
|
||||
# We group trees into sets so that individual managers can get a page
|
||||
# of all the projects they manage. This is a mapping from managers
|
||||
# email address to the set of projects they are interested in. This
|
||||
# is only used by the Summaries.pm module and the static portion can
|
||||
# be left blank if you do not wish for these pages to be generated.
|
||||
|
||||
|
||||
%VC_TREE_GROUPS = (
|
||||
'jim' => {
|
||||
'Project_A' => 1,
|
||||
'Project_B' => 1,
|
||||
},
|
||||
'fred' => {
|
||||
'Project_C' => 1,
|
||||
},
|
||||
);
|
||||
|
||||
# We always want there to be one summary pages showing all trees.
|
||||
|
||||
foreach $tree (keys %VC_TREE) {
|
||||
$VC_TREE_GROUPS{'all_trees'}{$tree} =1;
|
||||
}
|
||||
|
||||
|
||||
# This hash holds the colors used for the cells in the VC column of
|
||||
# the build table. The keys of this hash are the definative list of
|
||||
# tree states. The code makes no assumptions as to how many states
|
||||
# there are or what they mean, it only displays the history of the
|
||||
# state.
|
||||
|
||||
%TREE_STATE2COLOR = (
|
||||
'Open' => "white",
|
||||
'Restricted' => "#e7e7e7", # a light grey
|
||||
'Closed' => "silver",
|
||||
);
|
||||
|
||||
|
||||
sub TreeState2color {
|
||||
my ($state) = @_;
|
||||
|
||||
return $TREE_STATE2COLOR{$state};
|
||||
}
|
||||
|
||||
|
||||
sub get_all_tree_states {
|
||||
my @tree_states;
|
||||
|
||||
@tree_states = sort keys %TREE_STATE2COLOR;
|
||||
|
||||
return @tree_states;
|
||||
}
|
||||
|
||||
|
||||
|
||||
sub tree_exists {
|
||||
my ($tree) = @_;
|
||||
|
||||
($VC_TREE{$tree}) &&
|
||||
return 1;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
sub get_all_trees {
|
||||
my (@out);
|
||||
|
||||
@out = sort (keys %VC_TREE);
|
||||
|
||||
return @out;
|
||||
}
|
||||
|
||||
1;
|
||||
Загрузка…
Ссылка в новой задаче