[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to (not) protect privacy



On 02/03/10 at 21:03 +0100, Eduard Bloch wrote:
> #include <hallo.h>
> * Gerfried Fuchs [Tue, Mar 02 2010, 01:17:17PM]:
> 
> > * Lucas Nussbaum <lucas@lucas-nussbaum.net> [2010-03-02 10:57:28 CET]:
> > > For context, Andreas is replying to http://www.lucas-nussbaum.net/blog/?p=453
> > > I'm not sure why people start discussions on blogs, when we have mailing
> > > lists for that.
> > 
> >  Maybe because you announce stuff on blogs when we have mailing lists
> > for that.
> 
> Exactly. ATM I am the opposite of happy seeing such stuff happening
> right in between of the Debian community. I expected to see at least a
> bit of common sense WRT privacy protection rules from any fellow DD, but
> apparently I was mistaken. What comes next, RSS feed straight from
> debian-private?
> 
> > > The list of (package, subscribers) is already available to DDs on
> 
> To DDs! That's the point. I accept the permission to see such
> information to a group that I thrust not to the whole world.

Then I think that you are actually fine, since the list of (package,
subscribers) is not available to the whole world.

I think that you misunderstood what was available. Let's take an
example. Suppose I maintain (or co-maintain) 4 packages: at, bc, ed,
gq[1]. On the PTS, I always subscribe to packages I maintain, and also
to some packages I'm very interested in. So I'm subscribed to at, bc, ed
and, because I'm deeply interested in packages with long names,
libbusiness-onlinepayment-transactioncentral-perl.

What does the CGI provide? It doesn't say anything about
libbusiness-onlinepayment-transactioncentral-perl. It just says "gq",
because it is the only package I maintain to which I'm not subscribed.
So it would probably be a good idea to subscribe.

That's all the CGI provides: suggestions of packages you might want to
subscribe to, but are not subscribed to yet. It doesn't say to which
packages you are subscribed: it says to which packages you might want to
subscribe.

Now, to give a very concrete use case for that tool: in the
pkg-ruby-extras team, we don't put the team in the Maintainer field
(like the perl team does, for example). Instead, we put the "mainly
responsible person" as Maintainer, and the team in Uploaders. As a
result, we would miss mails from the BTS if we forgot to subscribe to
some packages. That tool would remind us of packages that we forgot to
subscribe to.

- Lucas

[1] Did you know that we currently have 54 2-letter source packages in
sid?


Reply to: