savannah-hackers-public
[Top][All Lists]
Advanced

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

Re: [Savannah-hackers-public] Running GNU Savannah (frontend) locally


From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] Running GNU Savannah (frontend) locally
Date: Thu, 04 Sep 2014 08:20:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0

Hello,

On 09/03/2014 12:49 AM, Karl Berry wrote:
     1. Hacking on the GNU Savannah code itself will be easier, and more
     inviting.
     2. Bringing the current Savannah code up-to-date.
     3. Examining the current databases as preparation for migration to a
     new platform.

All those are unquestionably (IMO) valid arguments, but don't speak to
making a database dump *publicly* available.  Available on the Savannah
machines would be enough for those purposes.

     4. Allowing interested people to explore the GNU Savannah public
     data (which is already public), develop new useful features, and
     finding new interesting statistics.

Ok, that could be persuasive.

     As I've written in the previous email, I consider "public" only
     information that's available to non-logged users.

That sounds very sensible to me.

As my main goal is to make hacking on GNU Savannah easier and more inviting,
and to do that, I believe that providing a snapshot of the real database is 
essential,
Can we perhaps agree on a small subset of projects which can be included ?

Can we include "coreutils" ? can we include "emacs" or "autoconf" ? Preferable 
at least one project for each type of VCS system.
These are large enough projects, with enough items in the database to help 
reproduce real scenarios on a development machine.
We can also use fake user names and fake user accounts (though I will insist 
again to remind you that all user names are already public).
I do not want to limit access to this snapshot for authorized Savannah hackers.
I want every one to be able to hack on GNU Savannah.


     Are the SQL commands I've listed in the previous emails adequate for
     removing private information?

As Sylvain said, it still seems much better to me, in principle, to
extract only the public information than delete the private.  Better to
err on the side of less being included.
select from bugs where privacy=0 or whatever ...

At the risk of repeating myself like a parrot :)

I agree with the suggestion of exporting the data differently.
But to do that, I still need your feedback as to which fields/tables/rows/items 
are considered public and which are considered private.

- Assaf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]