Re: [Nix-dev] Fractalide is ready to use.

[zimbatm]

Interesting. Do you have any further examples than the readme ?

I wonder if we should extend nix's multi-line string syntax to accept a
shebang-like so that editors can can switch the syntax in that context.

On Sat, 20 Feb 2016 at 19:14 stewart mackenzie  wrote:

> Ah yes a link would be useful (thanks anon)
>
> github.com/fractalide/fractalide
>
> /sjm
> ___
> 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] Fwd: Wiki is dead

[Anthony Cowley]

> On Feb 20, 2016, at 3:20 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru> 
> wrote:
> 
> Anthony Cowley  writes:
>> Bringing together what Thomas and Freddy say here, it seems to me that
>> a rather ideal mixture would be something unstructured like a wiki
>> with buttons for readers saying, "This helped me" or "This did not
>> work".
>> 
>> The point being that once a wiki item gets a handful of positive
>> votes, it gets turned into an Issue on the manual for someone with a
>> better understanding of how things are put together to find it a home.
> 
> Anthony, this is an excellent idea that you have came up to!
> 
> The question that immediately comes my mind is -- what "this" would mean?
> 
> A section? A paragraph? Something even more structured?
> 
> ..and then there is this perpetually simple matter of programming
> to make it happen..
> 
> -- 
> с уважениeм / respectfully,
> Косырев Сергей

I was imagining feedback attached to section headings. They could perhaps be 
buttons inserted with CSS/JS or something tied more into the wiki engine. The 
links could ping a counter running as a separate web service with what 
page/section they are associated with.

I think the feedback mechanism should be as simple as a Reddit upvote since any 
impact it has will be mediated by an expert reviewer who will use their 
judgment to determine what valuable nuggets should be promoted to the manual.

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

Re: [Nix-dev] Printing test failure preventing unstable channel update

[Domen Kožar]

https://github.com/NixOS/nixpkgs/commit/35e1f4954555f465fb4499880dcb6a68417fb959#commitcomment-16221919

On Sat, Feb 20, 2016 at 6:18 PM, Kevin Cox  wrote:

> The raw log links were working for me. I don't know why the others aren't.
> On Feb 20, 2016 13:08, "Jascha Geerds"  wrote:
>
>> Unfortunately, I don't see any logs for the build
>> ___
>> 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] Fwd: Wiki is dead

[Anthony Cowley]

Bringing together what Thomas and Freddy say here, it seems to me that a rather 
ideal mixture would be something unstructured like a wiki with buttons for 
readers saying, "This helped me" or "This did not work".

The point being that once a wiki item gets a handful of positive votes, it gets 
turned into an Issue on the manual for someone with a better understanding of 
how things are put together to find it a home. At that point, the wiki item 
could have a link to the manual added. Similarly, things marked obsolete could 
at some point get a review from an expert who could make the obsolescence 
official so that the item gets a big red banner warning future readers. The 
expert reviewer could zero out the counts if the votes are due to 
misunderstandings. The votes are not for publicity, but for triage.

This does not address spam, but offloading authentication to someone like 
github could still be used. What this does is free would-be doc or recipe 
contributors from being paralyzed by unfamiliarity with language style or 
naming conventions, while still establishing a path for their contributions to 
make it into the manual.

Anthony

> On Feb 20, 2016, at 8:54 AM, Freddy Rietdijk  wrote:
> 
> Adding documentation is one thing, maintaining it is a second. It's great if 
> someone is willing to convert contributions to Docbook, and I'm thankful for 
> that. However, that does not help much if you want to modify parts of it. And 
> as Nixpkgs is updated, so should the documentation.
> 
> I agree writing docs isn't peoples favorite activity, but somehow, when I see 
> the amount of content that's on the Wiki, I do wonder: how come people chose 
> to put it there instead of in the manual? Was it because there never really 
> was a manual where the contents would fit in? Or was it because it was more 
> convenient to contribute to the wiki instead of the manual?
> I haven't been around long enough with this project, so I don't know. Some of 
> you will have a better idea.
> 
> Being able to convert to Docbook like is done with the Haskell guide makes it 
> easier for others to contribute, at least, if you know how that conversion is 
> done.
> 
> Some time ago I began using Nix because I like it. Python packaging is a mess 
> as Domen explained during NixCon, but with Nix it works much better. I've 
> contributed Python packages, and now I would like to share how it is done. As 
> acoustician/researcher my work activities are quite different from I bet most 
> other Nix users. Learning Nix was a big investment, but is I think worth it. 
> Learning Docbook on the other hand...
> 
> If you want to scare away contributors by keeping the barrier high, then keep 
> the documentation the way it is.
> 
> 
> 
>> On Sat, Feb 20, 2016 at 2:04 PM, Thomas Hunger  wrote:
>> I'm tool agnostic but +1 on having a cookbook in git for the review-workflow 
>> (avoids wiki spam). I have a number of snippets (how to remove gc roots, 
>> haskell profiling, how to use ihaskell properly, many more) but no good 
>> place to put them.
>> 
>> I've started a git-book thing [1] a while back to collect these but didn't 
>> get very far. I'd much rather contribute to a common, low-barrier-to-entry 
>> repository than rolling my own.
>> 
>> In my experience just providing the structure will eventually attract 
>> content because adding a small snippet is the path of least resistance for 
>> each individual contributor. Maybe we could add a banner "This is how you 
>> add a snippet" and buttons "File a bug that this is wrong / outdated" to 
>> each snippet?
>> 
>> Rok - I know it's not free software but maybe it's worth setting up a google 
>> docs spreadsheet for coordinating the migration once we've settled on a 
>> tool? I will contribute.
>> 
>> ~
>> 
>> [1]
>> https://github.com/WeAreWizards/nixbyexample
>> 
>>> On 20 February 2016 at 12:06, Freddy Rietdijk  
>>> wrote:
>>> I agree with Vladimir that we already have the infrastructure, the Nixpkgs 
>>> repository.
>>> 
>>> What is needed is a clearer way where to put certain documentation and a 
>>> lower barrier for contributing. In `Redesign of documentation` I came with 
>>> a proposal of how to structure the documentation. A wiki has a low barrier 
>>> for contributing, however, it also has many disadvantages, which you would 
>>> not have if we use, say, the Nixpkgs repository.
>>> 
>>> A big barrier, in my opinion and I'm pretty sure also in that of others, is 
>>> the current format of the Nixpkgs manual. I can understand why docbook is 
>>> used, and I think it should be used for say the Nix manual, but for a 
>>> User's Guide to which many of us would/should contribute, the barrier is 
>>> just too high.
>>> 
>>> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I 
>>> implemented the proposed redesign. 
>>> The documentation is split into two documents, the User's Guide, and the 
>>> 

Re: [Nix-dev] Fractalide is ready to use.

[stewart mackenzie]

Ah yes a link would be useful (thanks anon)

github.com/fractalide/fractalide

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

Re: [Nix-dev] Printing test failure preventing unstable channel update

[Kevin Cox]

The raw log links were working for me. I don't know why the others aren't.
On Feb 20, 2016 13:08, "Jascha Geerds"  wrote:

> Unfortunately, I don't see any logs for the build
> ___
> 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] Printing test failure preventing unstable channel update

[Jascha Geerds]

Unfortunately, I don't see any logs for the build
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Fractalide is ready to use.

[stewart mackenzie]

Hi all,

I'd say Fractalide is in a state ready to use now. It's still very
experimental so don't bet the house on it.

Fractalide is a flow-based programming platform implemented in Rust,
it uses Nix as its package manager, and aims to thwart three classes
of problems: Memory safety, Dependency Hell and Code Reuse (or lack
thereof).

Points of interest:
*) First (?) language designed to use nix as its package manager.
**) Each component can setup its own OS dependencies (say openssl, db
drivers etc)
**) The repo is lazily evaluated thus can expand massively and you
only compile what is needed (similar to nixpkgs)
*) Components have capnproto contracts between them, (in an effort to
implement some semblance of the langsec.org know how. We also use the
nom parser combinator, as a second langsec muscle flex)
*) Its implemented in Rust, so you get to safely have your cake and
speedily eat it.
*) This kind of platform elevates the concept of devops to new levels imho.
*) We use nix to replace make.
*) We're currently implementing a hypercard whereby we swap out
hypertalk for flow-based programming, so feedback is desired. This
allows for fancy graphics.

Happy hacking!

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

Re: [Nix-dev] Fwd: Wiki is dead

[phreedom]

On Saturday, February 20, 2016 15:16:12 zimbatm wrote:
> That's exactly why the wiki is good. The contribution barrier is fairly low
> and you can do things without having to ask for permission.
> It's very easy for anyone to come along and fix typos. Having the change
> appear directly is also much more rewarding than having to file a PR and
> then potentially have people bikeshed about what you did. Edit, change,
> submit. Done.

The way I see it is that everyone understands that lowering the barrier of 
entry will 
encourage contributions. The problem is that people have exactly the opposite 
opinions as 
to what the barrier is :)

For example, for me, the barrier for contributing to the manual is that the 
contribution 
has to be structured, must be up to standards etc etc. So, instead of writing 
down a 
simple how-to note, I would need to do a lot more work so it's tagged "will do 
later"(read 
"never":))

The web interface is also a much bigger hassle to use than dropping an *.md 
file into a git 
repo. I don't even have to commit it right away. The practical and 
psychological barrier is 
the lowest in this case, but only if I have the commit rights otherwise I'd 
probably resort 
to submitting batches of notes in one PR.



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

Re: [Nix-dev] Fwd: Wiki is dead

[Freddy Rietdijk]

Adding documentation is one thing, maintaining it is a second. It's great
if someone is willing to convert contributions to Docbook, and I'm thankful
for that. However, that does not help much if you want to modify parts of
it. And as Nixpkgs is updated, so should the documentation.

I agree writing docs isn't peoples favorite activity, but somehow, when I
see the amount of content that's on the Wiki, I do wonder: how come people
chose to put it there instead of in the manual? Was it because there never
really was a manual where the contents would fit in? Or was it because it
was more convenient to contribute to the wiki instead of the manual?
I haven't been around long enough with this project, so I don't know. Some
of you will have a better idea.

Being able to convert to Docbook like is done with the Haskell guide makes
it easier for others to contribute, at least, if you know how that
conversion is done.

Some time ago I began using Nix because I like it. Python packaging is a
mess as Domen explained during NixCon, but with Nix it works much better.
I've contributed Python packages, and now I would like to share how it is
done. As acoustician/researcher my work activities are quite different from
I bet most other Nix users. Learning Nix was a big investment, but is I
think worth it. Learning Docbook on the other hand...

If you want to scare away contributors by keeping the barrier high, then
keep the documentation the way it is.



On Sat, Feb 20, 2016 at 2:04 PM, Thomas Hunger  wrote:

> I'm tool agnostic but +1 on having a cookbook in git for the
> review-workflow (avoids wiki spam). I have a number of snippets (how to
> remove gc roots, haskell profiling, how to use ihaskell properly, many
> more) but no good place to put them.
>
> I've started a git-book thing [1] a while back to collect these but didn't
> get very far. I'd much rather contribute to a common, low-barrier-to-entry
> repository than rolling my own.
>
> In my experience just providing the structure will eventually attract
> content because adding a small snippet is the path of least resistance for
> each individual contributor. Maybe we could add a banner "This is how you
> add a snippet" and buttons "File a bug that this is wrong / outdated" to
> each snippet?
>
> Rok - I know it's not free software but maybe it's worth setting up a
> google docs spreadsheet for coordinating the migration once we've settled
> on a tool? I will contribute.
>
> ~
>
> [1]
> https://github.com/WeAreWizards/nixbyexample
>
> On 20 February 2016 at 12:06, Freddy Rietdijk 
> wrote:
>
>> I agree with Vladimir that we already have the infrastructure, the
>> Nixpkgs repository.
>>
>> What is needed is a clearer way where to put certain documentation and a
>> lower barrier for contributing. In `Redesign of documentation` I came with
>> a proposal of how to structure the documentation. A wiki has a low barrier
>> for contributing, however, it also has many disadvantages, which you would
>> not have if we use, say, the Nixpkgs repository.
>>
>> A big barrier, in my opinion and I'm pretty sure also in that of others,
>> is the current format of the Nixpkgs manual. I can understand why docbook
>> is used, and I think it should be used for say the Nix manual, but for a
>> User's Guide to which many of us would/should contribute, the barrier is
>> just too high.
>>
>> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I
>> implemented the proposed redesign.
>> The documentation is split into two documents, the User's Guide, and the
>> Contributor's Guide. The User's Guide is divided into three parts:
>>
>>- Introduction
>>- Reference
>>- Cookbook
>>
>> There have been several proposals already for tools/implementations
>> (Matthias' Jekyll implementation, Domens Sphinx docs) . Here I chose to go
>> also for the Sphinx documentation generator. It allows you to write
>> RestructuredText. With a small plugin, which I enabled, you can also
>> include CommonMark/Markdown. Nix highlighting is supported.
>> The result can be found at http://nixpkgs.readthedocs.org/en/latest/ .
>> It's mostly empty still.
>>
>> Now this is only a proposal, and I'm open to other ways. But I really
>> think we should do something about the current state of the docs, in both
>> content and lowering the barrier. ReStructuredText/Markdown obviously
>> doesn't have as much possibilities as Docbook but what matters eventually
>> is whether it is enough, and I think it will be, at least for now.
>>
>>
>> On Sat, Feb 20, 2016 at 12:30 PM, Vladimír Čunát 
>> wrote:
>>
>>> On 02/20/2016 12:52 AM, zimbatm wrote:
>>> > It's a great staging area for content where people can edit without
>>> > asking for permission. [...]
>>>
>>> What are the advantages in comparison to standard pull requests with
>>> discussion underneath? We already have lots of infrastructure advantages
>>> in there, such as merging changes at once 

Re: [Nix-dev] codetriage.com

[zimbatm]

I was looking for a way to visualize the number of open issues over time
and found this: https://9-volt.github.io/bug-life/?repo=nixos/nixpkgs
.Unfortunately
we have too much content and it's hitting the API rate/limit.
The idea was to see the current trend. Maybe after 2-3 weeks of codetriage
the number will start going down ?

On Sat, 20 Feb 2016 at 11:42 Michael Raskin <7c6f4...@mail.ru> wrote:

> >>> https://github.com/NixOS/nixpkgs/pulls?utf8=✓=is:pr+is:open+updated
> 
> :<2015-10-01
> >>
> >> My point was ?if the submitter has got commit rights by now?.
> >>
> >> That seems to be harder to query for.
> >
> >Yeah, there seems to be no way. I can only see filtering by mentions of
> >the whole nixos/nixpkgs-committers team. But I personally don't think
> >it's so important to filter these cases out, in our case.
>
> I dunno. If we start with closing only the insiders' PRs, it can be
> better from the project PR point of view.
>
>
>
> ___
> 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] Fwd: Wiki is dead

[Thomas Hunger]

I'm tool agnostic but +1 on having a cookbook in git for the
review-workflow (avoids wiki spam). I have a number of snippets (how to
remove gc roots, haskell profiling, how to use ihaskell properly, many
more) but no good place to put them.

I've started a git-book thing [1] a while back to collect these but didn't
get very far. I'd much rather contribute to a common, low-barrier-to-entry
repository than rolling my own.

In my experience just providing the structure will eventually attract
content because adding a small snippet is the path of least resistance for
each individual contributor. Maybe we could add a banner "This is how you
add a snippet" and buttons "File a bug that this is wrong / outdated" to
each snippet?

Rok - I know it's not free software but maybe it's worth setting up a
google docs spreadsheet for coordinating the migration once we've settled
on a tool? I will contribute.

~

[1]
https://github.com/WeAreWizards/nixbyexample

On 20 February 2016 at 12:06, Freddy Rietdijk 
wrote:

> I agree with Vladimir that we already have the infrastructure, the Nixpkgs
> repository.
>
> What is needed is a clearer way where to put certain documentation and a
> lower barrier for contributing. In `Redesign of documentation` I came with
> a proposal of how to structure the documentation. A wiki has a low barrier
> for contributing, however, it also has many disadvantages, which you would
> not have if we use, say, the Nixpkgs repository.
>
> A big barrier, in my opinion and I'm pretty sure also in that of others,
> is the current format of the Nixpkgs manual. I can understand why docbook
> is used, and I think it should be used for say the Nix manual, but for a
> User's Guide to which many of us would/should contribute, the barrier is
> just too high.
>
> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I
> implemented the proposed redesign.
> The documentation is split into two documents, the User's Guide, and the
> Contributor's Guide. The User's Guide is divided into three parts:
>
>- Introduction
>- Reference
>- Cookbook
>
> There have been several proposals already for tools/implementations
> (Matthias' Jekyll implementation, Domens Sphinx docs) . Here I chose to go
> also for the Sphinx documentation generator. It allows you to write
> RestructuredText. With a small plugin, which I enabled, you can also
> include CommonMark/Markdown. Nix highlighting is supported.
> The result can be found at http://nixpkgs.readthedocs.org/en/latest/ .
> It's mostly empty still.
>
> Now this is only a proposal, and I'm open to other ways. But I really
> think we should do something about the current state of the docs, in both
> content and lowering the barrier. ReStructuredText/Markdown obviously
> doesn't have as much possibilities as Docbook but what matters eventually
> is whether it is enough, and I think it will be, at least for now.
>
>
> On Sat, Feb 20, 2016 at 12:30 PM, Vladimír Čunát  wrote:
>
>> On 02/20/2016 12:52 AM, zimbatm wrote:
>> > It's a great staging area for content where people can edit without
>> > asking for permission. [...]
>>
>> What are the advantages in comparison to standard pull requests with
>> discussion underneath? We already have lots of infrastructure advantages
>> in there, such as merging changes at once with documentation for them,
>> auto-mention bot, etc.
>>
>>
>>
>> ___
>> 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] Fwd: Wiki is dead

[Shea Levy]

Someone (I think Vladimir?) offered to translate docs in any format 
into the necessary docbook, and has done so at least for one of my PRs. 
As long as that offer still stands and isn't overwhelming him, we can 
avoid spending time and resources switching over our format until we 
actually have evidence that people will write docs in the new format.

I suspect format is a red herring here. People don't like writing docs.

~Shea

On 2016-02-20 07:06, Freddy Rietdijk wrote:
> I agree with Vladimir that we already have the infrastructure, the
> Nixpkgs repository.
>
> What is needed is a clearer way where to put certain documentation
> and a lower barrier for contributing. In `Redesign of documentation` 
> I
> came with a proposal of how to structure the documentation. A wiki 
> has
> a low barrier for contributing, however, it also has many
> disadvantages, which you would not have if we use, say, the Nixpkgs
> repository.
>
> A big barrier, in my opinion and I'm pretty sure also in that of
> others, is the current format of the Nixpkgs manual. I can understand
> why docbook is used, and I think it should be used for say the Nix
> manual, but for a User's Guide to which many of us would/should
> contribute, the barrier is just too high.
>
> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide [2] I
> implemented the proposed redesign. 
> The documentation is split into two documents, the User's Guide, and
> the Contributor's Guide. The User's Guide is divided into three 
> parts:
>
>   * Introduction
>
>   * Reference
>
>   * Cookbook
>
> There have been several proposals already for tools/implementations
> (Matthias' Jekyll implementation, Domens Sphinx docs) . Here I chose
> to go also for the Sphinx documentation generator. It allows you to
> write RestructuredText. With a small plugin, which I enabled, you can
> also include CommonMark/Markdown. Nix highlighting is supported.
>
> The result can be found at http://nixpkgs.readthedocs.org/en/latest/
> [3] . It's mostly empty still.
>
> Now this is only a proposal, and I'm open to other ways. But I really
> think we should do something about the current state of the docs, in
> both content and lowering the barrier. ReStructuredText/Markdown
> obviously doesn't have as much possibilities as Docbook but what
> matters eventually is whether it is enough, and I think it will be, 
> at
> least for now.
>
> On Sat, Feb 20, 2016 at 12:30 PM, Vladimír Čunát  
> wrote:
>
>> On 02/20/2016 12:52 AM, zimbatm wrote:
>> > It's a great staging area for content where people can edit 
>> without
>> > asking for permission. [...]
>>
>> What are the advantages in comparison to standard pull requests with
>> discussion underneath? We already have lots of infrastructure 
>> advantages
>> in there, such as merging changes at once with documentation for 
>> them,
>> auto-mention bot, etc.
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev [1]
>
>
>
> Links:
> --
> [1] http://lists.science.uu.nl/mailman/listinfo/nix-dev
> [2] https://github.com/FRidh/nixpkgs/tree/usersguide
> [3] http://nixpkgs.readthedocs.org/en/latest/
>
> ___
> 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] Fwd: Wiki is dead

[Freddy Rietdijk]

I agree with Vladimir that we already have the infrastructure, the Nixpkgs
repository.

What is needed is a clearer way where to put certain documentation and a
lower barrier for contributing. In `Redesign of documentation` I came with
a proposal of how to structure the documentation. A wiki has a low barrier
for contributing, however, it also has many disadvantages, which you would
not have if we use, say, the Nixpkgs repository.

A big barrier, in my opinion and I'm pretty sure also in that of others, is
the current format of the Nixpkgs manual. I can understand why docbook is
used, and I think it should be used for say the Nix manual, but for a
User's Guide to which many of us would/should contribute, the barrier is
just too high.

On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I
implemented the proposed redesign.
The documentation is split into two documents, the User's Guide, and the
Contributor's Guide. The User's Guide is divided into three parts:

   - Introduction
   - Reference
   - Cookbook

There have been several proposals already for tools/implementations
(Matthias' Jekyll implementation, Domens Sphinx docs) . Here I chose to go
also for the Sphinx documentation generator. It allows you to write
RestructuredText. With a small plugin, which I enabled, you can also
include CommonMark/Markdown. Nix highlighting is supported.
The result can be found at http://nixpkgs.readthedocs.org/en/latest/ . It's
mostly empty still.

Now this is only a proposal, and I'm open to other ways. But I really think
we should do something about the current state of the docs, in both content
and lowering the barrier. ReStructuredText/Markdown obviously doesn't have
as much possibilities as Docbook but what matters eventually is whether it
is enough, and I think it will be, at least for now.


On Sat, Feb 20, 2016 at 12:30 PM, Vladimír Čunát  wrote:

> On 02/20/2016 12:52 AM, zimbatm wrote:
> > It's a great staging area for content where people can edit without
> > asking for permission. [...]
>
> What are the advantages in comparison to standard pull requests with
> discussion underneath? We already have lots of infrastructure advantages
> in there, such as merging changes at once with documentation for them,
> auto-mention bot, etc.
>
>
>
> ___
> 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] codetriage.com

[Vladimír Čunát]

On 02/20/2016 12:31 PM, Michael Raskin wrote:
>> https://github.com/NixOS/nixpkgs/pulls?utf8=✓=is:pr+is:open+updated:<2015-10-01
> 
> My point was ?if the submitter has got commit rights by now?.
> 
> That seems to be harder to query for.

Yeah, there seems to be no way. I can only see filtering by mentions of
the whole nixos/nixpkgs-committers team. But I personally don't think
it's so important to filter these cases out, in our case.




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] Wiki is dead

[Vladimír Čunát]

On 02/20/2016 12:52 AM, zimbatm wrote:
> It's a great staging area for content where people can edit without
> asking for permission. [...]

What are the advantages in comparison to standard pull requests with
discussion underneath? We already have lots of infrastructure advantages
in there, such as merging changes at once with documentation for them,
auto-mention bot, etc.




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] codetriage.com

[Michael Raskin]

>https://github.com/NixOS/nixpkgs/pulls?utf8=✓=is:pr+is:open+updated:<2015-10-01

My point was ?if the submitter has got commit rights by now?.

That seems to be harder to query for.



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

Re: [Nix-dev] codetriage.com

[Vladimír Čunát]

On 02/20/2016 10:45 AM, Wout Mertens wrote:
> Now if we could run a query for that… :-)

GitHub can run similar queries easily:
https://github.com/NixOS/nixpkgs/pulls?utf8=✓=is:pr+is:open+updated:<2015-10-01




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] codetriage.com

[Wout Mertens]

Now if we could run a query for that… :-)

On Sat, Feb 20, 2016, 10:26 AM Michael Raskin <7c6f4...@mail.ru> wrote:

> >Same for PRs, we have some really old ones. What is a good cutoff? 6
> months?
>
> I would start with «6 months without any updates except non-submitter
> pings and the submitter now has commit rights»
>
>
>
> --

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [***SPAM***] Re: codetriage.com

[Michael Raskin]

>Same for PRs, we have some really old ones. What is a good cutoff? 6 months?

I would start with «6 months without any updates except non-submitter 
pings and the submitter now has commit rights»



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