Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer. Regarding "automated ticket assignment to maintainers" your changes will make it harder for trac itself. How to solve this, have a port <=> maintainer map at a secret hidden place? Kind regards Thomas jberry@macports.org wrote:
Revision 35275 <http://trac.macosforge.org/projects/macports/changeset/35275> Author jberry@macports.org Date 2008-03-23 08:54:42 -0700 (Sun, 23 Mar 2008)
Log Message
obfuscate my maintainer email addresses
On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid <reiffert@macports.org> wrote:
Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer.
Why? MacPorts understands this obfuscation, it will expand to the appropriate address. For example, running 'port info' for these ports will return the correct email address: 'user' will be expanded to user@macports.org and 'example.com:user' will be expanded to user@example.com I use this on all my ports, along with many other maintainers. Cheers Adam
Hi Thomas, On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote:
On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid <reiffert@macports.org> wrote:
Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer.
Why? MacPorts understands this obfuscation, it will expand to the appropriate address. For example, running 'port info' for these ports will return the correct email address: 'user' will be expanded to user@macports.org and 'example.com:user' will be expanded to user@example.com
I use this on all my ports, along with many other maintainers.
Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc). Implemented by the following code in port.tcl: proc unobscure_maintainers { list } { set result {} foreach m $list { if {[string first "@" $m] < 0} { if {[string first ":" $m] >= 0} { set m [regsub -- "(.*):(.*)" $m "\\2@\\1"] } else { set m "$m@macports.org" } } lappend result $m } return $result } James
Hi Thomas, On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote:
On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid <reiffert@macports.org> wrote:
Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer.
Why? MacPorts understands this obfuscation, it will expand to the appropriate address. For example, running 'port info' for these ports will return the correct email address: 'user' will be expanded to user@macports.org and 'example.com:user' will be expanded to user@example.com
I use this on all my ports, along with many other maintainers.
Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc). Implemented by the following code in port.tcl: proc unobscure_maintainers { list } { set result {} foreach m $list { if {[string first "@" $m] < 0} { if {[string first ":" $m] >= 0} { set m [regsub -- "(.*):(.*)" $m "\\2@\\1"] } else { set m "$m@macports.org" } } lappend result $m } return $result } James
On Mar 24, 2008, at 09:05, James Berry wrote:
Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc).
The $Id$ tag at the top of every portfile. :(
Ryan Schmidt wrote:
On Mar 24, 2008, at 09:05, James Berry wrote:
Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc).
The $Id$ tag at the top of every portfile. :( Uh, you are so right. I never thought about that, but this really makes obfuscation rather useless for committers...
Rainer
On Mar 24, 2008, at 19:00, Rainer Müller wrote:
Ryan Schmidt wrote:
On Mar 24, 2008, at 09:05, James Berry wrote:
Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc).
The $Id$ tag at the top of every portfile. :(
Uh, you are so right. I never thought about that, but this really makes obfuscation rather useless for committers...
Well, we had to start somewhere. We started with the maintainer line in the portfiles. Next, we need a solution for obfuscating the $Id$ line and trac tickets (use obfuscated Trac/svn logins?)
participants (5)
-
Adam Mercer
-
James Berry
-
Rainer Müller
-
Ryan Schmidt
-
Thomas Reifferscheid