anelok: new and enhanced Y-Box (draft)

EdorFaus edorfaus at
Fri Jan 17 00:30:51 EST 2014

On 01/17/2014 12:01 AM, Werner Almesberger wrote:
> EdorFaus wrote:
>> I threw together a quick diagram of the basic use cases for this,
>> based on my understanding of things
> That's the spirit ! And yes, it's exactly right. Thanks a lot !

np, yw.

> One minor nit: the Anelok case ends in a half-circle on the side
> of the wheel, with wheel and half-circle having the same center.

Darn it. I know, but I was sort of hoping noone would notice (or at 
least not care/comment about) that. ^_^'

That's part of what the "quick" qualifier was for, tbh - I was at work, 
so only had LibreOffice Draw to work with, and I'm not too familiar with 
how that's used. (I'm more familiar with Inkscape.)

Turned out to be fairly quick and easy for an inital mockup (just add 
some rounded-rects, circles, etc), but I didn't quite see how to fix 
that kind of detail. :/ (Had a few other annoyances too, but I was kind 
of trying to suppress my inner perfectionist so I wouldn't run out of 
energy/inspiration before I had something at least halfway usable.)

Ah well, just consider it a first draft or something like that. :)

>> However, I couldn't figure out how to make a clone of the wiki
>> repository in such a way that I can then send a merge request
>> against it.
> Hmm, there doesn't seem to be a direct way to do it. According to
> "be able to clone the wiki repository" should be implemented
> "soon", but then it says the same about "be able to push to the
> wiki repository (project admins only?)" and this works already,
> at least for me as project owner.

Yeah, while googling I found some resolved issues about those things (so 
I guess it's just the todo page not being updated), but I didn't find 
anything about having the same on-site clone/merge functionality for the 
wiki repos as for project repos. Seems like a pretty obvious idea to me, 
but maybe they just haven't thought of it yet? *shrug*

I'm pretty sure it's the same way on GitHub's wikis too, that they're 
kind of off to the side of the normal git functionality.

Now that I think about it though, I guess wikis are really more about 
letting everyone change stuff, and then just revert the change if it was 
wrong, instead of having to approve every change... Just a bit hard to 
let go of my code mindset I guess, where that would be a disaster. :P

>> What license is [the documentation] supposed to  be using?
> Good question. CC-BY-SA may work. I treat it sort of as catchall
> for anything that isn't clearly software. There's the GNU FDL
> specifically for documents, but at a very quick glance it looks
> a little over-engineered.

CC-BY-SA works for me. (Wikipedia uses it, so it ought to work pretty 
well for wiki stuff...)

... Although, hm. A bit of looking around shows that CC-BY-SA is not 
compatible with the GNU GPL. That might be a problem, depending on if we 
want to put code into the docs, or docs into the code.

During my looking around though, I saw someone doing something that 
might work (but IANAL and I haven't looked closer at it or its potential 
consequences): licensing the docs under both CC-BY-SA and GPLv2+.

However, one of my first thoughts about that is that I suspect it would 
allow us to put docs into code and hardware, but not code or hardware 
into the docs. So, in one way, worse than just CC-BY-SA...

Argh. It's too late (or early) for this... I'm going to bed. g'nite.


P.S. Things would be *so* much simpler if only everyone could use CC0 
instead of all these other licenses... Fat chance of that happening though.

More information about the discussion mailing list