[Fwd: Re: rawhide report: 20060207 changes]

n0dalus n0dalus+redhat at gmail.com
Wed Feb 8 15:37:06 UTC 2006


On 2/9/06, Miles Lane <miles.lane at gmail.com> wrote:
> On Wed, 2006-02-08 at 13:58 +0100, Sander Hoentjen wrote:
> [...]
> > I vote for the clear/resubscribe option.
>
> Me to.  If people can't be bothered to resubscribe, how much are they
> likely to contribute to Fedora?  Not much, I bet.
>

I disagree.

I am on the mailing lists of several open source projects, and every
now and then I will mark unread emails on one or two of them as read.
I don't have time to read all the emails, but it's great to have them
in my archive for searching, and every now and then I see a topic that
I can contribute to. If one of the mailing lists that I'm currently
not reading got one of these resubscribe requests I could easily fail
to notice it -- that doesn't mean I'm not likely to contribute to
their project every now and then.

I think the best way is to just send an email to everyone. I have been
on the list for several months now and I have never gotten any
automated email like the one described earlier. This could be because
I'm not in the public subscriber list. Or perhaps the email wasn't To:
fedora-devel (because the responsible person may have a filter to only
forward some emails) or maybe it was sent in a way that wouldn't have
usually gotten a challenge from the UOL server.

Someone asked why not everyone gets the emails. I am guessing it's
because some domains (like gmail, hotmail, etc) are whitelisted on
their server.

I think a mass unique email is the best way. It would use just as many
emails as sending a resubscribe request to everyone, and it would be
far more effective at finding the person responsible (if constructed
correctly). For all we know it could be that someone's box has been
hacked and their mail config files have been set to forward all their
mail to this uol account. If the forwarding is accidental or through
some other circumstances the person doesn't even realise, they could
resubscribe when the request comes around and the problem would
continue.

n0dalus.




More information about the devel mailing list