Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Jascha Geerds]

There is also Pelican, a static site generator written in python. I
don't know how it compares to Jekyll:

http://blog.getpelican.com/
https://github.com/getpelican/pelican

-- 
  Jascha Geerds
  j...@ekby.de
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Vladimír Čunát]

On 09/25/2015 04:28 PM, Matthias Beyer wrote:
> and 1GB installation, as you mentioned.
> 
> I used Jekyll because I don't know Haskell (I know a bit, but not
> enough) and I can see that haskell puts off a lot of people just
> because it is different. [...]

I believe we can work around those as follows: compile the generator
statically. Consequently, for people that don't change our generator
code, only a few-megabyte executable would be downloaded from Hydra and
it would be used to generate the pages. Most wiki contributors will
never (need to) touch any (Haskell) code.


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Eelco Dolstra]

Hi,

On 25/09/15 16:04, Matthias Beyer wrote:

>> This is essentially how the NixOS homepage is built, i.e., a git repository +
>> Template Toolkit + a makefile. And of course you can make pull requests on
>> GitHub. But I wouldn't call that a wiki, since you can't easily edit it from 
>> a
>> browser, or make it world-writable. But if we do want go that way, another
>> possibility is GitHub Pages + Jekyll.
> 
> github pages + jekyll is _exactly_ what I proposed.

Ah sorry, I didn't read properly.

>> The main advantage of using a GitHub wiki is that we then don't have to 
>> manage
>> user accounts and deal with spammers.
> 
> As we would use github for PR merging when using a static-site-wiki. So this
> holds true for static pages as I proposed, too.

Right.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Vladimír Čunát]

On 09/25/2015 04:58 PM, Jookia wrote:
> On Fri, Sep 25, 2015 at 04:01:21PM +0200, Matthias Beyer wrote:
>> What do you mean by proprietary tools? Jekyll, Bundler, git - all open
>> source. The only thing which would be non-open source are the web
>> servers who host the generated html files and the travis-ci build
>> machines!
> 
> github tools like github's wiki require nonfree code to run on your machine in
> the form of javascript to contribute properly. You may be able to get by 
> without
> it but it's a huge pain in the neck.

The point is you won't have to use github. Just edit files in your local
checkout and commit it. For creating a PR you maybe do need it (though
the CLI interface probably can do that as well), but that's much more of
concern for the main nixpkgs code, not the wiki...


If people aren't much against Hakyll, I'll have a closer look during and
hopefully get a prototype during the weekend. I can maintain that
Haskell code long-term, if you like.


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 25-09-2015 17:07:23, Vladimír Čunát wrote:
> 
> The point is you won't have to use github. Just edit files in your local
> checkout and commit it. For creating a PR you maybe do need it (though
> the CLI interface probably can do that as well), but that's much more of
> concern for the main nixpkgs code, not the wiki...
> 

That's right.

> 
> If people aren't much against Hakyll, I'll have a closer look during and
> hopefully get a prototype during the weekend. I can maintain that
> Haskell code long-term, if you like.
> 

Effort has already been made[0] (not hakyll though) and my template is
basically usable! - I mean, if you want to, do so. And of course, I
will maintain everything, including the wiki if we decide to do it my
way (and I accept patches via mail as well).

[0]: https://github.com/matthiasbeyer/wiki.template/tree/transform-to-jekyll

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpnKWkL8CLwI.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 24-09-2015 17:48:17, Edward Tjörnhammar wrote:
> On Thu, Sep 24, 2015 at 05:24:58PM +0200, Domen Kožar wrote:
> >I'm all for permissive creative commons license.
> 
> +1

+1


We would need to contact these people:


https://nixos.org/w/index.php?title=Special%3AListUsers===1=500

I don't know how to get a list of email adresses out of the wiki, can
someone do this, actually?

We really should do this soon.


-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpli9b03Swi0.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Eelco Dolstra]

Hi,

On 25/09/15 12:50, Kirill Elagin wrote:

> I’d like to also point out another problem.
> In case some of contributors do not agree to the new terms, how are we going 
> to
> delete their contributions? My understanding is that simply deleting the 
> content
> in question from the page is not enough, it’s wiki actually. We’ll have to see
> how, for example, Wikipedia deals with this kind of issues, I’m sure they 
> often
> have to remove copyrighted content.

You can always nuke a page along with history.

However, an alternative to relicensing is to combine it with a move to a
different Wiki, which many people have wanted in the past anyway. For instance,
we could set up a GitHub wiki, and people could copy their own contributions to
the new wiki. The new wiki should of course have a license from the start.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[stewart mackenzie]

On 25 Sep 2015 15:29, "Joachim Schiele"  wrote:
>
> two problems i see here:
> - text can't be covered by GPL thus they created CC

I suggested nix{os,pkgs} to be GPL3 or MPLv2 not the wiki.

> - some edits in the wiki are anonymous (whom to ask?)

I wouldn't care about anonymous edits. Proving it is hard.

> i like that we are adressing this issue now. it is very important.
>
> i'd go for CC BY SA 3.0
> https://creativecommons.org/licenses/by-sa/3.0/
> as IMHO this fits the other licenses pretty well

yes I personally prefer this license.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Vladimír Čunát]

> However, an alternative to relicensing is to combine it with a move to a
> different Wiki, which many people have wanted in the past anyway. For 
> instance,
> we could set up a GitHub wiki, and people could copy their own contributions 
> to
> the new wiki. The new wiki should of course have a license from the start.

A very good idea. There were quite some discussions about the format of
the docs, and IIRC the wiki syntax wasn't very popular. GitHub wiki
should help with integrating with the other changes in nixpkgs.


Now the licensing points.

On 09/25/2015 01:00 PM, stewart mackenzie wrote:
> I suggested nix{os,pkgs} to be GPL3 or MPLv2 not the wiki.

You all seem to suggest copyleft licenses a lot, but nixpkgs isn't
copylefted, and I don't have a feeling that changing that would do good.
I actually suspect that nontrivial part of the contributions we get is
due to *allowing* people to fork nixpkgs and not to disclose (the rest
of) their changes.

Moreover, many of them would use nix expressions to build things without
distributing the expressions themselves, so it would be necessary to
create some other license in AGPL fashion to get some effect.

That was for nixpkgs code - if that isn't copylefted, I don't see the
use of docs being copylefted, especially when in the same repository.


> I wouldn't care about anonymous edits. Proving it is hard.

That's not correct.
https://commons.wikimedia.org/wiki/Commons:Anonymous_works


Copyright assignments: I'm quite certain that whatever licenses we use,
the copyright should be held by a few entities at most. Currently it's
Eelco in nixpkgs; the foundation might be another choice now. We do no
formal assignments, so I'm not sure it is effectively so (I'm no lawyer,
too). Maybe we should (also) have some kind of FLA, though maybe it's
pointless when using permissive licensing
https://fsfe.org/activities/ftf/fla.en.html

Perhaps we should consult someone? Domen: maybe @silverhook?


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Arseniy Seroka]

+1 for hakyll.

-- 
Sincerely,
Arseniy Seroka



On 25 September 2015 18:07:38 Vladimír Čunát  wrote:

> On 09/25/2015 04:58 PM, Jookia wrote:
>> On Fri, Sep 25, 2015 at 04:01:21PM +0200, Matthias Beyer wrote:
>>> What do you mean by proprietary tools? Jekyll, Bundler, git - all open
>>> source. The only thing which would be non-open source are the web
>>> servers who host the generated html files and the travis-ci build
>>> machines!
>>
>> github tools like github's wiki require nonfree code to run on your machine 
>> in
>> the form of javascript to contribute properly. You may be able to get by 
>> without
>> it but it's a huge pain in the neck.
>
> The point is you won't have to use github. Just edit files in your local
> checkout and commit it. For creating a PR you maybe do need it (though
> the CLI interface probably can do that as well), but that's much more of
> concern for the main nixpkgs code, not the wiki...
>
>
> If people aren't much against Hakyll, I'll have a closer look during and
> hopefully get a prototype during the weekend. I can maintain that
> Haskell code long-term, if you like.
>
>
> Vladimir
>
>
>
>
>
> --
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Nicolas Pierron]

I think having a wiki in git can be a big trouble for users who don't
know where to find the "edit" / "login" buttons, but I am sure that we
can make the proper template in due time to wrap an interface around
such system.

On Fri, Sep 25, 2015 at 3:49 PM, Eelco Dolstra
 wrote:
> […] But I wouldn't call that a wiki, since you can't easily edit it from a
> browser, or make it world-writable. But if we do want go that way, another
> possibility is GitHub Pages + Jekyll.

Also, I wanted to mention that Github offers an option for modifying
pages without even cloning the repository on your computer.  Which
makes this approach less painful for making contributions.

https://help.github.com/articles/editing-files-in-your-repository/

I am sure that a review process is good for the quality and
consistency of the wiki, but we should *clearly* document how people
can contribute to the wiki:
 - Open an issue for the lack of documentation
 - Use the ACE editor to edit pages online and submit pull requests
 - Clone the repository to edit and preview pages locally.

Also, I think that having an issue tracker to highlight the lack of
documentation is a really good idea.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?

[Thomas Hunger]

Hi Alaistair,

Thanks for doing that change! We've tried your package on a fresh install
and it doesn't add the channel or
`$HOME/.nix-profile/etc/profile.d/nix.sh`. After we've added those manually
we ran into the locale bug in [1]. Are you getting that bug as well? And if
so, did you manage to work around that?

~

[1]
https://github.com/NixOS/nix/issues/599

On 23 September 2015 at 10:15, Alastair Pharo  wrote:

> Hi Thomas,
>
> I’m the author of this script by the way. I didn’t say that before.
>
> The bulk of the work that it does is in the install file which is not easy
> to view from the AUR website, so I’m not sure if you saw it. Here
> 
> is a link to it in the git repo viewer. It’s still a very simple script;
> it’s mostly just doing what is described on the wiki for Debian:
>
>1. create users
>2. make a skeleton /nix folder
>3. display a message telling the user how to enable the daemon.
>
> It wasn’t doing (2) properly until a few minutes ago; previously it was
> failing if /nix/store didn’t exist. As you will see, the installer is
> basically just a shell script that gets run as root when the package is
> installed, so if there is a more official version of this process, it would
> probably be quite easy to include it there.
>
> Cheers,
>
> Alastair
>
> On 23 September 2015 18:02, Thomas Hunger wrote:
>
> Alastair,
>
> Looking at [1] it looks like the only thing that package does is setting an
> env variable - how did you get your /nix tree started? Maybe we could
> extend nix-multiuser to execute your /nix steps on start?
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 25-09-2015 20:58:36, Nicolas Pierron wrote:
> 
> Also, I wanted to mention that Github offers an option for modifying
> pages without even cloning the repository on your computer.  Which
> makes this approach less painful for making contributions.
> 
> https://help.github.com/articles/editing-files-in-your-repository/

Indeed.

> 
> I am sure that a review process is good for the quality and
> consistency of the wiki, but we should *clearly* document how people
> can contribute to the wiki:
>  - Open an issue for the lack of documentation
>  - Use the ACE editor to edit pages online and submit pull requests
>  - Clone the repository to edit and preview pages locally.
> 
> Also, I think that having an issue tracker to highlight the lack of
> documentation is a really good idea.
> 

I agree. I wanted to create a new organization for this and publish
the repository on the organizations account and github page.

Something like github.com/nixos-wiki

or something similar. I explicitely want _not_ to include the wiki in
the "normal" nixos account.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpULSurEebqi.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Eric Sagnes]

Hi,

A few considerations:

I would be great to have support for i18n, including guidelines and
workflows for foreign languages. (eg: Who with merging privileges can 
determine if a contribution in thai is not spam?)

Git and command line can be a big hurdle for non technical users, so to 
help them there should be a beginner tutorial on how to contribute  
and an alternative way to submit content (for example in an 
issue with a dedicated label)

PRs are great for big commits but they can brings more friction for minor
changes like grammar or typo fixes.
And specially if the number of pages get big it can means a large number
of 1~10 characters change PR. (Using issues for minor edits could be a 
solution)

Cheers,

On Fri, Sep 25, 2015 at 02:24:56PM +0200, Matthias Beyer wrote:
> On 25-09-2015 12:58:14, Eelco Dolstra wrote:
> > However, an alternative to relicensing is to combine it with a move to a
> > different Wiki, which many people have wanted in the past anyway. For 
> > instance,
> > we could set up a GitHub wiki, and people could copy their own 
> > contributions to
> > the new wiki. The new wiki should of course have a license from the start.
> 
> Well, if we start this discussion here:
> 
> In fact, I asked the licensing question _because_ I'm working on an
> alternative wiki for nixos. The whole point of my question is that I
> want to be sure that I can use contents from the official wiki.
> 
> I didn't want to ask for permission that early, so I just
> asked about the license of the wiki and docs, but well... as we are at
> that point in our discussion now...
> 
> Anyhow, I strongly disagree with your proposal to use the github wiki.
> It is _far_ to complicated to keep things organized in there. Subpages
> and all this stuff.
> 
> Of course, I did some investigation on the subject. I tried several
> wiki software packages.
> 
> Let me elaborate:
> 
> My requirements:
> 
> 1. git. I want to have the content (and, if possible, all
>metainformation like page templates and so on) tracked in git.
> 
>Contributions would go through git as well. So why is that? I
>can already hear voices argueing about this. Yes, it is
>a bit of an obstacle if you are only able to contribute via a
>pull-request procedure.
> 
>BUT there are some big pro points:
> 
> 1) Contributions are reviewed. One can't argue with that.
>People can actually review contributions before they go
>online. This keeps up the quality of the wiki and
>automatically protects it against abuse. I believe that this
>becomes more important as the wiki (or the number of people
>involved in nix{wiki, os, pkgs, }) grows.
> 
> 2) Having a long(ish) running process for adding/editing
>content of the wiki keeps people from "just pasting this in
>the wiki somewhere". I believe that if there is a bit of a
>process behind all this, it keeps people from just dropping
>in content.
> 
> Some more pro points which are not that major as the ones
> above:
> 
> 3) git-log. You can log the history of single articles or even
>topic-trees (speaking of subdirectories). You can do the
>former with, for example, MediaWiki. But not the latter, I
>guess.
> 
> 4) git-blame. You can actually see what happened where. And
>yes, you can do this wiki MediaWiki, too. But tell me:
>How often have you actually done this?
> 
> Of course there are more points. Let me summarize them: git.
> 
> 2. One-click contributions (not really, actually). I want user to
>be able to do contributions with only a few commandline calls.
>Idea was that a user only needs to fork the repository, edit the
>contents of some Markdown page and rebuild the wiki to review.
>One-click contributions like in a MediaWiki instance is not what
>I want, as described in 1.
> 
> 3. Local clone.
>Well, git gives us the opportunity to run a _full clone_ of the
>wiki locally. You cannot do this with MediaWiki (maybe you can,
>but not _that_ easy).
> 
> Okay, so here are the things I reviewed:
> 
> - gitit (Haskell, integrated with nixos)
> - gollum (ruby, actually the software that powers the github wiki)
> 
> These are the only options I found for a wiki with git as backend.
> 
> gitit
> -
> 
> Gitit is awesome. It works great and is fast.
> Anyways, it has some issues. First, it does not track templates.
> You can write page templates, but they are not tracked in git.
> I had to do some nasty hacks for this.
> 
> The templates cannot be used to generate, for example, warning
> blocks:
> 
> { warning_block "Do not install this in User env" }
> 
> (Just an example, not the actual markup for templates)
> The above is 

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Joachim Schiele]

two problems i see here:
- text can't be covered by GPL thus they created CC
- some edits in the wiki are anonymous (whom to ask?)

i like that we are adressing this issue now. it is very important.

i'd go for CC BY SA 3.0
https://creativecommons.org/licenses/by-sa/3.0/
as IMHO this fits the other licenses pretty well

On 25.09.2015 03:48, stewart mackenzie wrote:
> According to my understanding:
> 
> * 1st agree on a license for the wiki.
> * we need to get all wiki contributors to agree on said license.
> * we'll need a written statement from all wiki contributors, could be
> something simple like "I agree to publish my contributions to the nixos
> wiki under the X license" these statements could be on a new mailing
> list thread. It'll be mundane receiving these mails but it's needed..
> 
> (longerterm strategy)
> * The Nixos Foundation could use selected parts of the C4.1(
> http://rfc.zeromq.org/spec:22) particularly the licensing bits to create
> a nixos contributors 'contract'. It /should/ be difficult but not
> impossible to change the license of wiki, nix{pkgs,os,} as this prevents
> vendor lockins / foundation / consortium clusterfuck takeovers where
> dishonest agents could for example purchase the copyright to a codebase.
> i.e. what happened to Berkeleydb and oracle.
> * so far all the contribution copyrights to nix{os,pkgs} belong to the
> contributors and not the nixos foundation. It is preferable (IMHO) that
> copyright remain in the contributors hands and not the nixos foundation.
> Foundations can be corrupted, this prevents sillybuggers happening in
> foundations.
> 
> Personally, i'd prefer the whole nix{os,pkgs} to be a license like gpl3
> or mpl2. These licenses create prevent an org like redhat form forking
> and sublicensing.
> 
> I am not a lawyer.
> 
> There are treasures of untold wealth in nixos let's at least properly
> protect them.
> 
> On 25 Sep 2015 01:52, "Vladimír Čunát"  > wrote:
> 
> On 09/24/2015 05:24 PM, Domen Kožar wrote:
> > I'm all for permissive creative commons license.
> 
> It might be good to have the same license for wiki and nix{pkgs,os,}
> docs, allowing us to move content around freely.
> 
> I'm no lawyer, too, but I think there's also the issue of the copyright
> holder, which might be the foundation, for example. And the question of
> "asking everyone" seems rather difficult; moreover, I'm not sure what
> kind of approval is needed (I'm afraid a paper-written one in some
> jurisdictions).
> 
> 
> Vladimir
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl 
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 25-09-2015 12:58:14, Eelco Dolstra wrote:
> However, an alternative to relicensing is to combine it with a move to a
> different Wiki, which many people have wanted in the past anyway. For 
> instance,
> we could set up a GitHub wiki, and people could copy their own contributions 
> to
> the new wiki. The new wiki should of course have a license from the start.

Well, if we start this discussion here:

In fact, I asked the licensing question _because_ I'm working on an
alternative wiki for nixos. The whole point of my question is that I
want to be sure that I can use contents from the official wiki.

I didn't want to ask for permission that early, so I just
asked about the license of the wiki and docs, but well... as we are at
that point in our discussion now...

Anyhow, I strongly disagree with your proposal to use the github wiki.
It is _far_ to complicated to keep things organized in there. Subpages
and all this stuff.

Of course, I did some investigation on the subject. I tried several
wiki software packages.

Let me elaborate:

My requirements:

1. git. I want to have the content (and, if possible, all
   metainformation like page templates and so on) tracked in git.

   Contributions would go through git as well. So why is that? I
   can already hear voices argueing about this. Yes, it is
   a bit of an obstacle if you are only able to contribute via a
   pull-request procedure.

   BUT there are some big pro points:

1) Contributions are reviewed. One can't argue with that.
   People can actually review contributions before they go
   online. This keeps up the quality of the wiki and
   automatically protects it against abuse. I believe that this
   becomes more important as the wiki (or the number of people
   involved in nix{wiki, os, pkgs, }) grows.

2) Having a long(ish) running process for adding/editing
   content of the wiki keeps people from "just pasting this in
   the wiki somewhere". I believe that if there is a bit of a
   process behind all this, it keeps people from just dropping
   in content.

Some more pro points which are not that major as the ones
above:

3) git-log. You can log the history of single articles or even
   topic-trees (speaking of subdirectories). You can do the
   former with, for example, MediaWiki. But not the latter, I
   guess.

4) git-blame. You can actually see what happened where. And
   yes, you can do this wiki MediaWiki, too. But tell me:
   How often have you actually done this?

Of course there are more points. Let me summarize them: git.

2. One-click contributions (not really, actually). I want user to
   be able to do contributions with only a few commandline calls.
   Idea was that a user only needs to fork the repository, edit the
   contents of some Markdown page and rebuild the wiki to review.
   One-click contributions like in a MediaWiki instance is not what
   I want, as described in 1.

3. Local clone.
   Well, git gives us the opportunity to run a _full clone_ of the
   wiki locally. You cannot do this with MediaWiki (maybe you can,
   but not _that_ easy).

Okay, so here are the things I reviewed:

- gitit (Haskell, integrated with nixos)
- gollum (ruby, actually the software that powers the github wiki)

These are the only options I found for a wiki with git as backend.

gitit
-

Gitit is awesome. It works great and is fast.
Anyways, it has some issues. First, it does not track templates.
You can write page templates, but they are not tracked in git.
I had to do some nasty hacks for this.

The templates cannot be used to generate, for example, warning
blocks:

{ warning_block "Do not install this in User env" }

(Just an example, not the actual markup for templates)
The above is _not_ possible with gitit. Kinda dealbreaker for me.

There are few plugins for gitit. I failed installing even
the simplest of them using nixos tools.

Also, gitit is not actively maintained. There is an attempt to
rewrite gitit (called gitit2 actually) which is even less
maintained.

Running not-that-well-maintained software is ... problematic at
least.

gollum
--

Powering the github wiki, relatively actively maintained... Good
idea I thought. But:

- No templates
- No Plugins
- Not even custom style (you can do it, but I couldn't find
  documentation about it)

Also, gollum is great for single-user use. I use it locally to
keep some notes. It works great. But I fear distributing it and
merging around. It is just not the way it is supposed to work, I
think.

And, of course, it is rather complicated to keep track of where
things are actually stored. You can mess up really bad (I 

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Kirill Elagin]

I’d like to also point out another problem.
In case some of contributors do not agree to the new terms, how are we
going to delete their contributions? My understanding is that simply
deleting the content in question from the page is not enough, it’s wiki
actually. We’ll have to see how, for example, Wikipedia deals with this
kind of issues, I’m sure they often have to remove copyrighted content.

That said, I’m pretty sure other projects also had to deal with changing
the licence of their docs, so we can learn from their experience instead of
inventing something new.

On Fri, Sep 25, 2015 at 10:28 AM, Joachim Schiele  wrote:

> two problems i see here:
> - text can't be covered by GPL thus they created CC
> - some edits in the wiki are anonymous (whom to ask?)
>
> i like that we are adressing this issue now. it is very important.
>
> i'd go for CC BY SA 3.0
> https://creativecommons.org/licenses/by-sa/3.0/
> as IMHO this fits the other licenses pretty well
>
> On 25.09.2015 03:48, stewart mackenzie wrote:
> > According to my understanding:
> >
> > * 1st agree on a license for the wiki.
> > * we need to get all wiki contributors to agree on said license.
> > * we'll need a written statement from all wiki contributors, could be
> > something simple like "I agree to publish my contributions to the nixos
> > wiki under the X license" these statements could be on a new mailing
> > list thread. It'll be mundane receiving these mails but it's needed..
> >
> > (longerterm strategy)
> > * The Nixos Foundation could use selected parts of the C4.1(
> > http://rfc.zeromq.org/spec:22) particularly the licensing bits to create
> > a nixos contributors 'contract'. It /should/ be difficult but not
> > impossible to change the license of wiki, nix{pkgs,os,} as this prevents
> > vendor lockins / foundation / consortium clusterfuck takeovers where
> > dishonest agents could for example purchase the copyright to a codebase.
> > i.e. what happened to Berkeleydb and oracle.
> > * so far all the contribution copyrights to nix{os,pkgs} belong to the
> > contributors and not the nixos foundation. It is preferable (IMHO) that
> > copyright remain in the contributors hands and not the nixos foundation.
> > Foundations can be corrupted, this prevents sillybuggers happening in
> > foundations.
> >
> > Personally, i'd prefer the whole nix{os,pkgs} to be a license like gpl3
> > or mpl2. These licenses create prevent an org like redhat form forking
> > and sublicensing.
> >
> > I am not a lawyer.
> >
> > There are treasures of untold wealth in nixos let's at least properly
> > protect them.
> >
> > On 25 Sep 2015 01:52, "Vladimír Čunát"  > > wrote:
> >
> > On 09/24/2015 05:24 PM, Domen Kožar wrote:
> > > I'm all for permissive creative commons license.
> >
> > It might be good to have the same license for wiki and nix{pkgs,os,}
> > docs, allowing us to move content around freely.
> >
> > I'm no lawyer, too, but I think there's also the issue of the
> copyright
> > holder, which might be the foundation, for example. And the question
> of
> > "asking everyone" seems rather difficult; moreover, I'm not sure what
> > kind of approval is needed (I'm afraid a paper-written one in some
> > jurisdictions).
> >
> >
> > Vladimir
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl 
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Jookia]

On Fri, Sep 25, 2015 at 09:28:36AM +0200, Joachim Schiele wrote:
> two problems i see here:
> - text can't be covered by GPL thus they created CC
> - some edits in the wiki are anonymous (whom to ask?)

> i like that we are adressing this issue now. it is very important.

> i'd go for CC BY SA 3.0
> https://creativecommons.org/licenses/by-sa/3.0/
> as IMHO this fits the other licenses pretty well

I might as well chime in given I wrote
https://nixos.org/wiki/Bootstrapping_NixOS_on_ARM but had someone else upload it
as Tor users are blocked from editing but I still want to contribute.

People can use my contributions licensed under the CC-BY-SA 4.0 or GPLv3+. Text
can be covered by the GPL (there's no reason they can't, it's a copyright
license at heart.) I'm not sure why you'd choose a 3.0 license when 4.0 is out.
I've heard 4.0 solves a lot of internalization problems too.

There's some people talking about copyleft licenses requirng you to disclose
your work, which isn't true. You only have to disclose the source code to people
you distribute your work to, which seems fair to everyone involved.

If there's a consensus for another license or a copyright agreement, people
can take my contribution as CC0 and combine them in to the permissively
licensed work. IMHO copyright agreements are unneccesary unless you disagree on
the license chosen. In which case you should probably have chosen a license.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Joachim Schiele]

hi rob,

we need your help. can you please provide matthias beyer with all the
email addresses from the wiki?

you can run these commands:
mysql -p
or
mysql

show databases;
use lastlogwiki;
select user_name,user_real_name,user_email from user;

mysql> select user_name,user_real_name,user_email from user;
+-+++
| user_name   | user_real_name | user_email |
+-+++
| WikiSysop   |||
| Joachim Schiele || j...@lastlog.de  |
| foo bar || f...@bar.com   |
+-+++

we need that in order to write about the license change of the wiki, see
the recent discussion on the mailinglist.

thanks in advance,
joachim


On 25.09.2015 12:59, Matthias Beyer wrote:
> On 24-09-2015 17:48:17, Edward Tjörnhammar wrote:
>> On Thu, Sep 24, 2015 at 05:24:58PM +0200, Domen Kožar wrote:
>>>I'm all for permissive creative commons license.
>>
>> +1
> 
> +1
> 
> 
> We would need to contact these people:
> 
> 
> https://nixos.org/w/index.php?title=Special%3AListUsers===1=500
> 
> I don't know how to get a list of email adresses out of the wiki, can
> someone do this, actually?
> 
> We really should do this soon.
> 
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Eelco Dolstra]

Hi,

On 25/09/15 14:24, Matthias Beyer wrote:

> So, an idea came up - why not using static pages for all of this? If you
> want to do contributions via git, you can use github. If one want to
> host it, one can use github pages and build it with travis-ci. These
> things are documented and they _work_ for other people, so why not for
> a wiki?
> 
> To be able to build pages with travis-ci and github pages, one needs a
> static site compiler. 

This is essentially how the NixOS homepage is built, i.e., a git repository +
Template Toolkit + a makefile. And of course you can make pull requests on
GitHub. But I wouldn't call that a wiki, since you can't easily edit it from a
browser, or make it world-writable. But if we do want go that way, another
possibility is GitHub Pages + Jekyll.

The main advantage of using a GitHub wiki is that we then don't have to manage
user accounts and deal with spammers. But as you say, the downside is that we
can't customize much.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Jookia]

On Fri, Sep 25, 2015 at 03:49:08PM +0200, Eelco Dolstra wrote:
> Hi,
> 
> On 25/09/15 14:24, Matthias Beyer wrote:
> 
> > So, an idea came up - why not using static pages for all of this? If you
> > want to do contributions via git, you can use github. If one want to
> > host it, one can use github pages and build it with travis-ci. These
> > things are documented and they _work_ for other people, so why not for
> > a wiki?
> > 
> > To be able to build pages with travis-ci and github pages, one needs a
> > static site compiler. 
> 
> This is essentially how the NixOS homepage is built, i.e., a git repository +
> Template Toolkit + a makefile. And of course you can make pull requests on
> GitHub. But I wouldn't call that a wiki, since you can't easily edit it from a
> browser, or make it world-writable. But if we do want go that way, another
> possibility is GitHub Pages + Jekyll.
> 
> The main advantage of using a GitHub wiki is that we then don't have to manage
> user accounts and deal with spammers. But as you say, the downside is that we
> can't customize much.

A huge disadvantage of using github tools are that they're proprietary, so
people using free systems can't contribute (easily.) What about ikiwiki?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 25-09-2015 15:49:08, Eelco Dolstra wrote:
> Hi,
> 
> On 25/09/15 14:24, Matthias Beyer wrote:
> 
> > So, an idea came up - why not using static pages for all of this? If you
> > want to do contributions via git, you can use github. If one want to
> > host it, one can use github pages and build it with travis-ci. These
> > things are documented and they _work_ for other people, so why not for
> > a wiki?
> > 
> > To be able to build pages with travis-ci and github pages, one needs a
> > static site compiler. 
> 
> This is essentially how the NixOS homepage is built, i.e., a git repository +
> Template Toolkit + a makefile. And of course you can make pull requests on
> GitHub. But I wouldn't call that a wiki, since you can't easily edit it from a
> browser, or make it world-writable. But if we do want go that way, another
> possibility is GitHub Pages + Jekyll.

github pages + jekyll is _exactly_ what I proposed.

> 
> The main advantage of using a GitHub wiki is that we then don't have to manage
> user accounts and deal with spammers.
> 

As we would use github for PR merging when using a static-site-wiki. So this
holds true for static pages as I proposed, too.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgp2eQbPUdRAY.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Edward Tjörnhammar]

On Fri, Sep 25, 2015 at 11:53:24PM +1000, Jookia wrote:
> On Fri, Sep 25, 2015 at 03:49:08PM +0200, Eelco Dolstra wrote:
> > Hi,
> >
> > On 25/09/15 14:24, Matthias Beyer wrote:
> >
> > > So, an idea came up - why not using static pages for all of this? If you
> > > want to do contributions via git, you can use github. If one want to
> > > host it, one can use github pages and build it with travis-ci. These
> > > things are documented and they _work_ for other people, so why not for
> > > a wiki?
> > >
> > > To be able to build pages with travis-ci and github pages, one needs a
> > > static site compiler.
> >
> > This is essentially how the NixOS homepage is built, i.e., a git repository 
> > +
> > Template Toolkit + a makefile. And of course you can make pull requests on
> > GitHub. But I wouldn't call that a wiki, since you can't easily edit it 
> > from a
> > browser, or make it world-writable. But if we do want go that way, another
> > possibility is GitHub Pages + Jekyll.
> >
> > The main advantage of using a GitHub wiki is that we then don't have to 
> > manage
> > user accounts and deal with spammers. But as you say, the downside is that 
> > we
> > can't customize much.
>
> A huge disadvantage of using github tools are that they're proprietary, so
> people using free systems can't contribute (easily.) What about ikiwiki?

Actually I believe that you can edit github wiki pages by just cloning,
committing and pushing, as an example:

git clone https://github.com/libgdx/libgdx.wiki.git libgdx-wiki

I don't know if you can do PR's for wiki content but I guess so.

Also you could then clone that gitrepo and put that checkout as the
wikidata path to gitit, since pandoc can read github markdown, and point
to the mainpage using the gitit configuration option. You would of
course still need to poll the github wiki.. Also this would mean that
the contribution model doesn't really change since if you want to be
anonymous you can run your own gitit/nixos-wiki clone and then submit
patches back via email?

> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


pgpL8P6tTjmjD.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Vladimír Čunát]

On 09/25/2015 04:18 PM, Vladimír Čunát wrote:
> I've got great experience with Hakyll

The only downside to Hakyll I can see is that apparently you need ~1 GB
of Haskell stuff to build the site :-/



smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

On 25-09-2015 16:18:31, Vladimír Čunát wrote:
> On 09/25/2015 02:24 PM, Matthias Beyer wrote:
> > So, an idea came up - why not using static pages for all of this?
> 
> Yeah, sounds good. Actually, you can edit and preview files on github
> easily - it's two clicks to get a PR with the changes (at least markdown
> is previewed).

Glad you like it!

Yes, you can view markdown on github and also create pull requests
with the github user interface - almost forgot about that. So
contributing would be _that_ simple!

> 
> Personally, I've got great experience with Hakyll, "running"
> http://vcunat.matfyz.cz for years. The flexibility is really great,
> XMonad-like and combined with the power of pandoc...
> 

and 1GB installation, as you mentioned.

I used Jekyll because I don't know Haskell (I know a bit, but not
enough) and I can see that haskell puts off a lot of people just
because it is different. Using Jekyll was just a sound decision. It is
maintained, really easy to extend and there's a load of documentation
on how to use it, build with travis etc etc etc. Everything is just
_there_ and you just have to plug parts together, you know?

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpB0YdexrWUK.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev