#
# This is a template configuration file for the Scmbug glue.
#
$glue_configuration = { 

    #
    # Flags whether the glue is active
    #
    enabled => 1,

    #
    # Describes the SCM system integrated with bug-tracking
    #
    scm => {
	name => 'CVS',

	# Comma(,)-separated list of paths to any binaries the SCM
	# tool may need to use
	binary_paths => '/usr/local/bin,/usr/local/bin/cvs',

	# This applies only to Subversion. It is recommended that tags
	# are stored in the 'tags' directory, and branches in the
	# 'branches' directory.
	label_directories => [
			      'tags',
			      'branches'
			      ],

	# This applies only to Subversion. It is recommended that the
	# main trunk work is stored in the 'trunk' directory.
	main_trunk_directories => [
				   'trunk'
				   ],

	# This applies only to CVS. When a commit affects more than
	# one directory, multiple duplicate log comments are inserted,
	# one-per-directory. Enabling this option would consolidate
	# the commits to all use the first log message.
	consolidate_cvs_messages => 1
    },

    #
    # Describes the daemon that will process the integration requests
    #
    daemon => {
	location => '127.0.0.1',
	port => 3872,
	},

	
    #
    # List of policies the glue can enforce
    #
    policies => {

	# Log template.
	#
	# Regular expressions that describe how the bug id and log
	# comment will be identified must be defined.
	#
	# This policy is ALWAYS enabled
	log_template => {
	    # The log_bugid_regex is a regular expression that must
	    # set the unnamed variable $1 to the bug number, or list
	    # of bug numbers. It is checked for a match as: m/$regex/s
	    log_bugid_regex => 'bug\s*([\d|\s|,|#]*?):',
            # The log_bugid_split_regex is a regular expression
            # describing how a list of bug ids will be split in
            # individual bug numbers. It is split as: /$regex/
            log_bugid_split_regex => ',\s?#|\s?#|,|\s+',
	    # The log_body_regex is a regular expression that must set
	    # the unnamed variable $1 to the log comment. It is
	    # checked for a match as: m/$regex/s
	    log_body_regex => 'bug.*?:\s*(.*)'
	    },

	# Resolution template.
	#
	# Regular expressions that describe how a resolution status
	# for a list of bug ids can be identified
	resolution_template => {
	    enabled => 1,
	    # The resolution_bugid_regex is a regular expression that
	    # must set the unnamed variable $1 to the bug number, or
	    # list of bug numbers. It is checked for a match as:
	    # m/$regex/s
	    resolution_bugid_regex => 'status\s*([\d|\s|,|#]*?):',
            # The resolution_bugid_split_regex is a regular expression
            # describing how a list of bug ids will be split in
            # individual bug numbers. It is split as: /$regex/
	    resolution_bugid_split_regex => ',\s?#|\s?#|,|\s+',
	    # The resolution_status_regex is a regular expression that
	    # must set the unnamed variable $1 to the requested
	    # status. It is checked for a match as: m/$regex/s
	    #
	    # For example, if one issued in the log message the
	    # resolution command:
	    #
	    # status 547: reopened
	    #
	    # Then the resolution_status_regex is expected to match
	    # "reopened"
	    resolution_status_regex => 'status.*?:\s*(\S+)\s*.*',
	    # The resolution_status_resolution_regex is a regular
	    # expression that must set the unnamed variable $1 to the
	    # requested resolution. It is checked for a match as:
	    # m/$regex/s
	    #
	    # For example, if one issued in the log message the
	    # resolution command:
	    #
	    # status 547: resolved fixed
	    #
	    # Then the resolution_status_resolution_regex is expected
	    # to match "fixed"
	    resolution_status_resolution_regex => 'status.*?:\s*\S+\s+(\S+)',
	    # The resolution_status_resolution_data_regex is a regular
	    # expression that must set the unnamed variable $1 to the
	    # additional data supplied by the resolution status. It is
	    # checked for a match as:
	    # m/$regex/s
	    #
	    # For example, if one issued in the log message the
	    # resolution command:
	    #
	    # status 548: resolved duplicate 547
	    #
	    # Then the resolution_status_resolution_data_regex is
	    # expected to match "547"
	    resolution_status_resolution_data_regex => 'status.*?:\s*\S+\s+\S+\s+(\S+)',
            # Apply a case sensitive resolution and resolution status verification
            resolution_status_case_sensitive_verification => 0,
	    # The resolution_status_* information can have all of the
	    # following characters converted according to a regular
	    # expression. This is useful in addressing the limitation
	    # of some bug-trackers that report a resolution-related
	    # information with a token that contains spaces. For
	    # example:
	    #
	    # "unable to reproduce" in Mantis.
	    resolution_status_convert => {
		enabled => 1,
		# Regular expressions that will be applied to convert
		# the characters of all resolution_status_*
		# information. It is applied for substitution as:
		#
		# s/$convert_from/$convert_to/g
		resolution_status_convert_from => '_',
		resolution_status_convert_to => ' '
		},
	    # The bugs whose resolution status will be changed must be
	    # filed against a valid product name.
	    resolution_valid_product_name => 0,
	    # The SCM user must be the user to which the bugs whose
	    # resolution status will be changed are assigned
	    resolution_valid_bug_owner => 0,
	    },

	#
	# Presence of bug ids. There are 3 options:
	#
	# - 'required'. A bug id must be specified during each
	#   activity. Activities without a bug id will not be permitted.
	#
	# - 'optional'. If a bug id is supplied, the activity will be
	#   integrated. If not the activity will be permitted to go
	#   through in the SCM system, but without bug-tracking
	#   integration.
	#
	# - 'none'. Never integrate activities regardless. This is
	#   different than flagging the glue inactive. The remaining
	#   policies are still enforced were applicable.
	#   (e.g. policy minimum_log_message_size).
	#
	# This policy is ALWAYS enabled
	presence_of_bug_ids =>  {
	    value => 'optional'
	    },

	# The SCM user issuing an activity must be the user to which
	# the bug is assigned
	valid_bug_owner => {
	    enabled => 0
	    },

	# All integration activity must originate from a specific SCM
	# user. If the SCM system does not provide the SCM user
	# information (e.g Subversion running an svnserve daemon with
	# anonymous access), assume the activity originated from a
	# specific SCM user
	anonymous_scm_username => {
	    enabled => 0,
	    value => 'anonymous_scm_user'
	    },

	# The bug against which an activity is issued must be in an
	# open state
	open_bug_state => {
	    enabled => 1
	    },

	# Minimum number of characters log message.
	minimum_log_message_size => {
	    enabled => 0,
	    size => 50
	    },

	# Format of label names (tag or branch names) defined as
	# regular expressions.
	label_name => {
	    enabled => 1,
	    names => [
              # take anything
		      '^.+?$',
		      # Convention for official releases.
		      # For example:
		      # SCMBUG_RELEASE_0-2-7
		      '^.+?_RELEASE_[0-9]+-[0-9]+-[0-9]+$',

		      # Convention for development builds.
		      # For example:
		      # SCMBUG_BUILD_28_added_a_policies_mechanism
		      '^.+?_BUILD_[0-9]+_.+$',

		      # Convention for branches.
		      # For example:
		      # b_experimenting_with_policies_on_glue_side
		      '^b_.+$',

		      # Convention for private developer tags. Uses
		      # the developer's initials (either 2 or 3).
		      # For example:
		      # p_kpm_prior_to_bug353_stabilization_fixes
		      '^p_[a-zA-Z][a-zA-Z]?[a-zA-Z]_.+$'
		      ]
		  },

	# The bug against which an activity is issued must be filed
	# against a valid product name.
	valid_product_name => {
	    enabled => 0
	    },

	# Product name definition. There are 2 options:
	#
	# - type is 'manual'. Each bug id supplied during commit
	#   messages must be filed against the product name
	#   specified in value.
	#
	# - type is 'auto'. The product name will be
	#   autodetected. Value must be a comma(,)-separated list of
	#   regular expressions. Each regular expression must set the
	#   unnamed variable $1 to the product name.
	#
	# This policy is ALWAYS enabled
	product_name_definition => {
	    type => 'manual',
	    value => 'TestProduct'
	    },

	#
	# Send email notifications after integration activity
	#
	mail_notification => {
            # Send an email after a successful activity (both
            # verifying and labeling)
	    mail_on_success => 0,
	    # Send an email after a failed commit activity that the
	    # SCM system may overshadow and not report
	    # (e.g. Subversion does not report error messages of its
	    # post-commit hook.) .
	    mail_on_failure => 0,
	    mail_settings => {
		# Must be a valid email address. Can remain empty if
		# other users should be notified.
		To => 'replace_with_commit_mailing_list_email@exampledomain.com',
		# Must be a valid email address. Can remain empty if
		# mail_also_appears_from_scm_user is enabled.
		From => 'Scmbug <replace_with_mailing_list_owner_email@exampledomain.com>',
		# Defaults to localhost if left empty
		Smtp => 'replace_with_mail_server.exampledomain.com'
	    },
	    # Sending email when a tag is moved or deleted in CVS can
	    # be annoying, since multiple emails are sent per
	    # directory (but not when a tag is added). mail_on_label
	    # can disable that behavior.
	    mail_on_label => 1,
	    mail_recipients => {
		# Make the email also appear to have been sent by the
		# SCM user.
		mail_also_appears_from_scm_user => 1,
		# List of users that will be notified
		mail_scm_user => 1,
		mail_bug_owner => 1,
		mail_bug_reporter => 1,
		mail_bug_monitors => 1,
		mail_product_owners => 1
		}
	}
    }
};
