[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Open mailing lists

From: <svn_at_feb17.org>
Date: Mon, 18 Jun 2012 10:10:27 -0700

Yes again sorry this is probably the wrong place to opine on this topic.
I generally use disposable email addresses but accidentally used a
permanent long term address at one point, otherwise I'd just have
cut off the bleeding there. I don't think it's easy for everyone to
generate lots of disposable addresses.

If there's any way of nuking this page, it would be appreciated

http://mail-archives.apache.org/mod_mbox/subversion-dev/201203.mbox/raw/%3C20120314050552.GM5198@clowder.feb17.org%3E

It doesn't appear to have been replicated yet.

I'm really sorry to disrupt the svn discussion. I've
joined two open source mailing lists and been spammed as a result 100% of the
time, so it's buyer beware. I think it would be wonderful if someone looked at the
list serve infrastructure and made it safer. This feels like telnet circa 1995,

Adieu and thanks for listening,

Darren

> Nearly all open-source projects rely on email communications, and most
> are publicly archived in >1 places.
>
> You could use auto-expiring email addresses (for example,
> address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but
> pretty useless for spammers.
>
> > Sorry,
> >
> > Darren
> >
> > >
> > > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein <gstein_at_gmail.com> wrote:
> > > > Darren,
> > > >
> > > > Over a dozen sites mirror our archives, usually by grabbing our published
> > > > mbox for the list. As a result, we cannot control how they publish the email
> > > > addresses contained within. It is also important for those mboxes to retain
> > > > the email addresses for archival purposes, and so those third-party systems
> > > > can allow proper replies (hopefully, only by humans, but as you've
> > > > discovered... they are not all perfect).
> > > >
> > > > Sorry for any inconvenience, but please don't blame us. We do try to respect
> > > > your privacy in our own web archive system.
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > On Jun 18, 2012 5:10 AM, <svn_at_feb17.org> wrote:
> > > >>
> > > >> Less than 2 months after using this mailing list I've started getting spam
> > > >> to the custom email address I used to post here.  I think it's terrible
> > > >> practice to openly publish email addresses in easily harvestable form.  I'll
> > > >> be /dev/nulling this address and unsubscribing.  I hope you could reconsider
> > > >> that policy,
> > > >>
> > > >> Darren
> > > >>
> > > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote:
> > > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote:
> > > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin
> > > >> > > <philip.martin_at_wandisco.com> wrote:
> > > >> > > > svn_at_feb17.org writes:
> > > >> > > >
> > > >> > > >> A little more information on this.  I have probably rebuilt svn
> > > >> > > >> about 20 times tonight from scratch, with
> > > >> >
> > > >> > Thanks to everyone who contributed useful clues on this.  Using the
> > > >> > current code tree and rebuilding with different versions and combinations of
> > > >> > libraries I narrowed the problem down to the apr version.  Either the build
> > > >> > of my earlier apr 1.3.9 or the version itself was the problem.  The test
> > > >> > suite was super helpful and the explanation about XFAIL vs FAIL.   I have a
> > > >> > build using apr 1.4.6 that passes all the tests it should pass and more
> > > >> > importantly actually works.    It might be helpful to print a reminder at
> > > >> > the end of the default make step suggesting running the tests if this is a
> > > >> > common problem.  There are a lot of dependencies and some of them seem to be
> > > >> > a bit finicky.
> > > >> >
> > > >> > Thanks!
> > > >> > Darren
> > >
> > >
> > >
> > > --
> > >
> > > uberSVN: Apache Subversion Made Easy
> > > http://www.uberSVN.com/
Received on 2012-06-18 19:11:32 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.