launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2011-10-13 02:53, Robert Collins wrote:

> On the 'should we expire' side - We have a guiding principle that
> Launchpad is the custodian of peoples data, not the owner. A mandatory
> fixed expiry date seems (to me) to be in tension with that. As Nigel
> says though, a configurable setting might be considered a feature.

I don't see that tension here.  As with an incomplete bug report (which 
we expire in 60 days) or a pending translations upload (which we delete 
eventually), a membership request is not a particular person's data. 
People produced it, but it's meaningless without continuation by whoever 
is in charge.  Approval or rejection is effectively consumption of the 
data, not alteration.

A fixed expiry period states that you need to act on a request within a 
given time if you want to prove that there's still an interested human 
in charge at all.  If there isn't, it's not people's data.  The request 
is effectively un-owned wastepaper; at best it deserves to be renewed. 
We might as well say loudly and clearly that Launchpad will see it that 
way after a given period.


> Note that an expiry mechanism intended to deal with this corrupt data
> would be more complex than one that has good data, so I think an
> expiry system is a different work item to fixing the corrupt data (and
> the cause of the corruption).

This is something I haven't looked into; in what ways is it more complex?

(Having a quick look at Curtis' message in this thread…

…There's some SQL there that looks like it wouldn't even notice a 
difference between the corrupt data and regular ignored requests.  I'll 
follow up there with my questions.)


Jeroen