diff --git a/mozilla/webtools/tinderbox2/src/default_conf/TicketData.pm b/mozilla/webtools/tinderbox2/src/default_conf/TicketData.pm deleted file mode 100644 index 75c53784a37..00000000000 --- a/mozilla/webtools/tinderbox2/src/default_conf/TicketData.pm +++ /dev/null @@ -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/befator/cvs/jail/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/Attic/TicketData.pm,v $ -# $Name: not supported by cvs2svn $ - - -# 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; diff --git a/mozilla/webtools/tinderbox2/src/default_conf/VCData.pm b/mozilla/webtools/tinderbox2/src/default_conf/VCData.pm deleted file mode 100644 index 61caff7a39c..00000000000 --- a/mozilla/webtools/tinderbox2/src/default_conf/VCData.pm +++ /dev/null @@ -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/befator/cvs/jail/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/Attic/VCData.pm,v $ -# $Name: not supported by cvs2svn $ - - -# 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;