On Wed, 2008-12-10 at 13:32 +0100, Thorsten Schöning wrote: > A more general way sounds good, of course, I was a little afraid of > how to configure something like this. Without properties the only > place would be the glue.conf, right? The glue could map paths to > mailadresses or something in the commit message to mailadresses.
That's right.
> Paths are not as flexible as something in the message, but at least in
> my case changes in the directory structure won't happen that often
> because those checked out directories are in productive use by the
> customers. One time configured the committee wouldn't need to
> remember anything, but can't deactivate this feature just for one
> commit.
"Something in the message" may be too flexible. If you want to manually
enter six email addresses for example, then perhaps you should be
opening up a mail client on your desktop and sending an email. It would
take you a lot of time to find those addresses, and to craft your log
message, which is what mail clients are for.
They can certainly deactivate this feature just for one commit. They can
edit glue.conf. Also, if they *need* to deactivate this feature, just
for one commit, that's an indication that they have set a policy that
isn't logically sound. Else, why would they want to override it ?
> Providing information about who to mail with each commit is more
> flexible and would be comparable to the bug and status-keywords.
> Something like "notification: [EMAIL PROTECTED],[EMAIL PROTECTED]" where
> [EMAIL PROTECTED]
> and [EMAIL PROTECTED] would be the addresses of mail notifications regardless
> of what is configured as the other mail notification options regarding
> bug owner etc. The committee could provide some mail lists or maybe
> the glue could be configured to map some keys to mail addresses, too.
"Some keys" ? You mean having essentially groups ?
mailing_lists => {
customers => { ... }
important_customers => { '[EMAIL PROTECTED]', '[EMAIL PROTECTED]' },
}
That would be neat. Your mail client has one, too.
> That way the log message the committee would have to supply would
> grow, of course.
I can see this as an addition to first having a policy of a standard
list of emails for people to be notified per path. I'm not crazy about
it, but I can imagine cases where it could be useful.
> Going the second way more of SCMBug standard-code could be used,
> right?
No. If you have a POLICY of what to do when you commit, then you
wouldn't need the notification keyword in the log. If you don't, then
you need a mail client, which you already have on your desktop. Don't
you think ?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
