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

Re: [UDD] Fixing (most) email addresses in upload_history table



On 23/01/11 at 14:40 +0100, Andreas Tille wrote:
> On Sun, Jan 23, 2011 at 02:14:14PM +0100, Lucas Nussbaum wrote:
> > On 23/01/11 at 00:41 +0100, Andreas Tille wrote:
> > > BTW, a
> > > 
> > > udd=# SELECT maintainer, maintainer_email, changed_by, changed_by_email, signed_by FROM upload_history WHERE (maintainer_email not like '%@%' or changed_by_email not like '%@%') and changed_by_email != 'N/A' and maintainer_email != 'N/A';
> > > 
> > > reveals some other cases where some reasonable guesses about valid
> > > e-mail adresses can be done if you compare maintainer, changed_by and
> > > signed_by for the name and username part of the email.  While for
> > > my application it is not really necessary to be that picky, it could
> > > help when gaining for real completeness.
> > 
> > Could you take care of doing this on udd.debian.org? I don't have the
> > time currently.
> 
> What do you mean by "doing this"?
> 
>    1. Reimporting the whole upload_history* tables with the new importer
>       script?
>       -> I do not like it really because of the import problem I have
>          faced on my side and I do not really understand the implications
>          this might have.  I would not know what to do in case something
>          might break more heavily and if you have no time to fix a possible
>          break this might be bad timing.
>          However, I don't think a delay of doing the reimport will really
>          harm (I'll plan to do all the stuff, even the query for what I
>          need the fixed e-mail addresses) on blends.debian.net where I
>          know that this is the only application and I can not break
>          anything else.
> 
>    2. Just copying the patches for the importer to put it in effect for
>       the files which are processed from now on.
>       -> That's fine.  I can perfectly do this.
> 
>    3. Implementing the issue I mentioned in my hint above?
>       -> Hmmm, I'm not really motivated to fix this minor issue seems not
>          be that harmful (regarding the number of data we can really fix)

I meant (1), or at least (2).

- Lucas


Reply to: