Tobias Geerinckx-Rice transcribed 3.3K bytes:
> ng0,
> 
> On 16/07/17 14:07, ng0 wrote:
> > What I expressed last night:
> > 
> > I don't want any additions to the connections made without the 
> > consent of people using guix.
> 
> The proposal then was using Guix to ‘feed’ the Directory, not the other
> way round. We as a project can't prohibit others to export data from

Okay, then it's all good for me and I did not understand Quiliro.

> their Guix checkout to their wiki if they'd so desire.
> 
> However, individual authors probably have some sort of copyright over
> the data in some jurisdiction, which is why I don't see it happening.

Yep.

> > What exactly does this mean? Everything should be within Guix. The 
> > default should be to *not* call some mediawiki for more information. 
> > If we even have the option to query this mediawiki and the 
> > information doesn't have to be present in guix like translations, I 
> > want it to be optional and you have to opt-in to (receiving) these 
> > (informations).
> 
> A sentiment which I support in general, but which makes no sense when
> discussing ‘guix import’, whose entire purpose in this life is to query
> external sources. What's so different about this one?

I did not read the full initial post. I responded to what Quiliro wrote in
IRC before I left yesterday night.
As we already established that I did not understand it correctly and now
do, let me explain how I understood the proposal on IRC.
I though the function would be to have some sort of mechanism in guix
package etc which sends a QUERY to the mediawiki of fsf to receive data
like categories (tags).
If this would
happen without the ability to reject this I would have vetoed against
it.
I'm not viewing this from a developer perspective but from users who
want to be in control over the connections. There's more to it, but I'm
not motivated to explain entire scenarios today.

> (I'm not personally advocating adding *this particular one* — I have
> nothing against the project, but do think our descriptions are slightly
> better on average. 

Yes, I think the fsf wiki is not really good. Really really not good.
Maybe mediawiki/wikidata of wikipedia might have better resources.

> Quiliro's proposal seemed interesting enough to
> discuss here: they're obviously eager to contribute, and this would be a
> relatively easy importer to write :-)

Okay, I think I still don't understand it. Why an importer when it
should be the other way around as you explained earlier?
At first I understood Quiliro this way:
FSF MW -> Guix.
After the first part of your email it was this:
Guix -> FSF MW.
And now an importer... for descriptions which are worse than ours?
Help me out here as I really don't know what the point of such an
importer would be, unless I got lost in the explanation.

> 
> > Please discuss this either on guix-devel or on the other list, but 
> > don't CC me into one of the famous gnu.org cross-posting
> > discussions. Thanks for your consideration.
> 
> What?
> 
> I don't think this proposal will be going anywhere because of licencing
> hurdles alone, anyway, so you'll not be disturbed by any more replies
> from me.

This wasn't directed at you specifically, I just want discussion to
happen on one list. gnu.org has the tendency to spread certain
discussions to at least 2 lists "because reasons". Crossposting is
never a good idea, and I just wanted to discourage it for anyone
replying to this, to not take some other list back into the CC.
(I know you just posted this to guix-devel, which is good :))

> Kind regards,
> 
> T G-R
> 




-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org