You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2013/10/20 12:32:20 UTC

couchdb internals doc repo

Hi all,

It came to my mind that a some people are asking how the couchdb internals
are working. Some for implementing alternatives, some to start start to
hack on couchdb and others for pure curiosity.

I have started a repository to collect the docs about it:

https://github.com/benoitc/couchdb_internals

For now it only contains the docs I have about the replication algorithm.
If you want to join me in that effort, just open a PR. For those who also
want direct commit access, then start with a pr with some content and ask
for it. This is that simple.

Things that will be accepted on that repo are:

- docs
- corrections
- anything that can help to maintain and display such docs.

Part of the docs could eventually be merged later in the couchdb repository
but I also think that having such repo outside can also be a good start for
a collaboration between many projects around and share new
ideas/implementations details.


Anyway will be on irc or on the ml if you want to discuss about it.

Best,

- benoit

Re: couchdb internals doc repo

Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 30, 2013 at 9:42 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Wed, Oct 30, 2013 at 9:34 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> > Anyway I really think a good doc items should be organised first before
> > putting anything in a melting pot  and reorganise them after. What makes
> a
> > good doc is the ability of the user to find rapidly an information
> without
> > having to sort after.
>
> I don't disagree, my point is more about the process of getting there.
> I think it's much easier to gather up all the documentation that we
> have already and try to iterate on it to improve organization &
> coherency, rather than starting from scratch and wanting to write
> everything to be just perfect. It also provides a better interim
> solution -- in between starting to collect/write and getting to a
> state of having the perfect developer docs, it would be better to have
> a disorganized collection of docs in a place that's easy to find (and
> contribute to) than having some separate place containing half-written
> docs or an outline of what it will grow to be.
>
>
The mailing-list is here to help us to coordinate the work imo. Especially
since we have the possibility to always provide a fresh snapshot to our
users.

The way we could organise our work could be the following:

1) Start a topic where we define first parts of the dev doc and put in
front the docs we currently have
2) Create the parts in our doc with a WIP header (something like we have in
some wikipedia articles)
3) Port the items collected in (1) to the repo in parts created in (2)

and iterate again using the mailing list by proposing new docs. That will
help to collaborate on the doc imo. At least more than the current process
that happen most of the time in the dark rooms of irc. If some are OK with
such workflow I will start the new thread asap.

- benoit

Re: couchdb internals doc repo

Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Oct 30, 2013 at 9:34 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> Anyway I really think a good doc items should be organised first before
> putting anything in a melting pot  and reorganise them after. What makes a
> good doc is the ability of the user to find rapidly an information without
> having to sort after.

I don't disagree, my point is more about the process of getting there.
I think it's much easier to gather up all the documentation that we
have already and try to iterate on it to improve organization &
coherency, rather than starting from scratch and wanting to write
everything to be just perfect. It also provides a better interim
solution -- in between starting to collect/write and getting to a
state of having the perfect developer docs, it would be better to have
a disorganized collection of docs in a place that's easy to find (and
contribute to) than having some separate place containing half-written
docs or an outline of what it will grow to be.

Cheers,

Dirkjan

Re: couchdb internals doc repo

Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 30, 2013 at 9:34 AM, Benoit Chesneau <bc...@gmail.com>wrote:

>
>
>
> On Wed, Oct 30, 2013 at 9:00 AM, Dirkjan Ochtman <di...@ochtman.nl>wrote:
>
>> On Wed, Oct 30, 2013 at 2:10 AM, Alexander Shorin <kx...@gmail.com>
>> wrote:
>> > This is good tutorial post about how to start hacking into, but for
>> > dev I think we should have some more common and abstract overview of
>> > CouchDB code layout.
>>
>> At the moment, we have no internals documentation at all. IMO adding
>> stuff we already have and iterating on it is better than trying to
>> hold off on it in search of something better that might take a while
>> to create/write/build.
>
>
> The fact that there is nothing in the upstream repo yet (thanks to forget
> the work I started) doesn't imply that we should put anything in the
> developer section just because we have it somewhere. The goal of the
> Internals section is is to present the internals of couchdb, gernerla
> design, solutions choosen, how they are actually implemented. At least this
> is what this topic was about.
>
> Then we could have another section in the developer section on how to hack
> couchdb and how the source code is actually organised. That another section
> anyway, in which I think the doc from Jan perfectly fit imo. And this is
> what Alexander implied imo.
>
> Anyway I really think a good doc items should be organised first before
> putting anything
>

 s/ a good doc/in a good doc, /

in a melting pot  and reorganise them after. What makes a good doc is the
> ability of the user to find rapidly an information without having to sort
> after.
>
> - benoit
>
>

Re: couchdb internals doc repo

Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 30, 2013 at 9:00 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Wed, Oct 30, 2013 at 2:10 AM, Alexander Shorin <kx...@gmail.com>
> wrote:
> > This is good tutorial post about how to start hacking into, but for
> > dev I think we should have some more common and abstract overview of
> > CouchDB code layout.
>
> At the moment, we have no internals documentation at all. IMO adding
> stuff we already have and iterating on it is better than trying to
> hold off on it in search of something better that might take a while
> to create/write/build.


The fact that there is nothing in the upstream repo yet (thanks to forget
the work I started) doesn't imply that we should put anything in the
developer section just because we have it somewhere. The goal of the
Internals section is is to present the internals of couchdb, gernerla
design, solutions choosen, how they are actually implemented. At least this
is what this topic was about.

Then we could have another section in the developer section on how to hack
couchdb and how the source code is actually organised. That another section
anyway, in which I think the doc from Jan perfectly fit imo. And this is
what Alexander implied imo.

Anyway I really think a good doc items should be organised first before
putting anything in a melting pot  and reorganise them after. What makes a
good doc is the ability of the user to find rapidly an information without
having to sort after.

- benoit

Re: couchdb internals doc repo

Posted by Alexander Shorin <kx...@gmail.com>.
On Wed, Oct 30, 2013 at 12:00 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, Oct 30, 2013 at 2:10 AM, Alexander Shorin <kx...@gmail.com> wrote:
>> This is good tutorial post about how to start hacking into, but for
>> dev I think we should have some more common and abstract overview of
>> CouchDB code layout.
>
> At the moment, we have no internals documentation at all. IMO adding
> stuff we already have and iterating on it is better than trying to
> hold off on it in search of something better that might take a while
> to create/write/build.

I'm not against including stuff to docs, I was about including them to
the right place (;


--
,,,^..^,,,

Re: couchdb internals doc repo

Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Oct 30, 2013 at 2:10 AM, Alexander Shorin <kx...@gmail.com> wrote:
> This is good tutorial post about how to start hacking into, but for
> dev I think we should have some more common and abstract overview of
> CouchDB code layout.

At the moment, we have no internals documentation at all. IMO adding
stuff we already have and iterating on it is better than trying to
hold off on it in search of something better that might take a while
to create/write/build.

Cheers,

Dirkjan

Re: couchdb internals doc repo

Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Oct 29, 2013 at 3:54 PM, Garren Smith <ga...@apache.org> wrote:
> Jan wrote a great introduction post to Couchdb last year. I think we should add it to the docs.
> http://markmail.org/search/?q=couchdb-erlang#query:couchdb-erlang%20list%3Aorg.apache.couchdb.erlang%20order%3Adate-forward+page:1+mid:usulk2gpys7hqato+state:results

This is good tutorial post about how to start hacking into, but for
dev I think we should have some more common and abstract overview of
CouchDB code layout.

Tutorials are also worth to have in docs as live examples about how to
increase the power of relax, but that's a bit separate docs section.
At least I don't think that mixing technical (couch internals docs are
such) and practical guides is good idea, but having them based on top
of the same code might be good idea, though (:

--
,,,^..^,,,

Re: couchdb internals doc repo

Posted by Garren Smith <ga...@apache.org>.
Hi Benoit,

Jan wrote a great introduction post to Couchdb last year. I think we should add it to the docs. 
http://markmail.org/search/?q=couchdb-erlang#query:couchdb-erlang%20list%3Aorg.apache.couchdb.erlang%20order%3Adate-forward+page:1+mid:usulk2gpys7hqato+state:results

Cheers
Garren
On 27 Oct 2013, at 3:30 PM, Benoit Chesneau <bc...@gmail.com> wrote:

> On Thu, Oct 24, 2013 at 3:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
> 
>> +1 too, I’ve wanted to start this for a while, thanks for taking the
>> initiative Benoit!
>> 
> 
> 
> 
> Like I said to some, I will find some times during the commit week to setup
> these docs in the main repo, will make s status update on the ml asap.
> 
> 
> - benoit


Re: couchdb internals doc repo

Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Oct 24, 2013 at 3:22 PM, Jan Lehnardt <ja...@apache.org> wrote:

> +1 too, I’ve wanted to start this for a while, thanks for taking the
> initiative Benoit!
>



Like I said to some, I will find some times during the commit week to setup
these docs in the main repo, will make s status update on the ml asap.


- benoit

Re: couchdb internals doc repo

Posted by Andy Wenk <an...@nms.de>.
+1 for putting this to the docs!


On 24 October 2013 15:22, Jan Lehnardt <ja...@apache.org> wrote:

> +1 too, I’ve wanted to start this for a while, thanks for taking the
> initiative Benoit!
>
> Best
> Jan
> --
>
> On 20 Oct 2013, at 16:39 , Alexander Shorin <kx...@gmail.com> wrote:
>
> > +1 to have this information in docs. One good docs to describe all the
> couch! (:
> >
> > P.S. I'll submit new replication protocol definition for review a bit
> > later today.
> > --
> > ,,,^..^,,,
> >
> >
> > On Sun, Oct 20, 2013 at 6:01 PM, Garren Smith <ga...@apache.org> wrote:
> >> Hi Benoit,
> >>
> >> This is a great idea. I also think this should be in the docs. Many
> people will find it easy to access from there.
> >>
> >> Cheers
> >> Garren
> >>
> >> On 20 Oct 2013, at 2:03 PM, Noah Slater <ns...@apache.org> wrote:
> >>
> >>> I think if we're documenting CouchDB internals, and other dev topics
> >>> relating to CouchDB, then it's fine for that stuff to live inside the
> >>> CouchDB manual. We host it online, so people can access it without
> having
> >>> to download CouchDB itself.
> >>>
> >>> Also, you can edit ReST directly from Github. So contributing should
> be as
> >>> easy as forking your branch, and then editing the file in the Github
> >>> interface itself. At least, I think that's how Alexander imagines
> people
> >>> might contribute!
> >>>
> >>>
> >>> On 20 October 2013 13:59, Benoit Chesneau <bc...@gmail.com> wrote:
> >>>
> >>>> On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org>
> wrote:
> >>>>
> >>>>> Benoit,
> >>>>>
> >>>>> Any way to get commit messages or notifications sent to the mailing
> list?
> >>>>>
> >>>>
> >>>> was about to set it up.
> >>>>
> >>>>>
> >>>>> As a community, we've promised to have all major activity happen on
> the
> >>>>> mailing list. Usually, this would apply to code. But I think you
> could
> >>>> say
> >>>>> the same about the development documentation. If there is significant
> >>>> work
> >>>>> going on away from the mailing lists, we may have to do a full IP
> >>>> Clearance
> >>>>> when we want to merge it back.
> >>>>>
> >>>> How difficult would it be fore you to create a new branch for this?
> And
> >>>>> while you're at it, create a new section in the manual that we ship
> under
> >>>>> share/doc. A section for developers. Because we mirror to Github, you
> >>>>> should still be able to invite PRs.
> >>>>>
> >>>>>
> >>>>>
> >>>> No difficulties really. I just felt like it, since no-one really took
> care
> >>>> about it until now. (we talk about that many time even 2 years ago at
> the
> >>>> summit).
> >>>>
> >>>> I can without difficulties (except having to convert it to this ugly
> >>>> restructured text) moved it to a branch or even master. I just want
> to make
> >>>> sure anyone is enough comfortable to work on a doc mixed with user
> things.
> >>>> And by anyone I am thinking to people that work on couchdb
> alternatives.
> >>>>
> >>>> - benoit
> >>>>
> >>>>
> >>>>>
> >>>>> On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> It came to my mind that a some people are asking how the couchdb
> >>>>> internals
> >>>>>> are working. Some for implementing alternatives, some to start
> start to
> >>>>>> hack on couchdb and others for pure curiosity.
> >>>>>>
> >>>>>> I have started a repository to collect the docs about it:
> >>>>>>
> >>>>>> https://github.com/benoitc/couchdb_internals
> >>>>>>
> >>>>>> For now it only contains the docs I have about the replication
> >>>> algorithm.
> >>>>>> If you want to join me in that effort, just open a PR. For those who
> >>>> also
> >>>>>> want direct commit access, then start with a pr with some content
> and
> >>>> ask
> >>>>>> for it. This is that simple.
> >>>>>>
> >>>>>> Things that will be accepted on that repo are:
> >>>>>>
> >>>>>> - docs
> >>>>>> - corrections
> >>>>>> - anything that can help to maintain and display such docs.
> >>>>>>
> >>>>>> Part of the docs could eventually be merged later in the couchdb
> >>>>> repository
> >>>>>> but I also think that having such repo outside can also be a good
> start
> >>>>> for
> >>>>>> a collaboration between many projects around and share new
> >>>>>> ideas/implementations details.
> >>>>>>
> >>>>>>
> >>>>>> Anyway will be on irc or on the ml if you want to discuss about it.
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>> - benoit
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Noah Slater
> >>>>> https://twitter.com/nslater
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Noah Slater
> >>> https://twitter.com/nslater
> >>
>
>


-- 
Andy Wenk
Hamburg - Germany
RockIt!

"CouchDB - Das Praxisbuch für Entwickler und Administratoren"
http://www.galileocomputing.de/2462
http://www.couchdb-buch.de

"PostgreSQL 8.4: Das Praxisbuch"
http://www.galileocomputing.de/2008
http://www.pg-praxisbuch.de

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js v.1.20130712
Comment: http://openpgpjs.org

xo0EUeJpHgED/34kUBUQNNT+3fcc621CLjzQZsuwYajo7Pj1hxtTcPbOo6Ci
UbyGOlIhlSDBaiXGXsFKxtdp4z/os7NdFQstzh6QpHzppjbGzGkv/om49jJM
SYLYkXyMDquhEQO47ovgOQUwJeO5qSzKE5fxftJQUjzHY1K673aA9D80uREM
Jc1tABEBAAHNF0FuZHkgV2VuayA8YW5keUBubXMuZGU+wpwEEAEIABAFAlHi
aR8JEAhxaGu1XIB2AAAfuAP/ZJXbv5wxAGCPridI/8Za9fXcccM0GmsG5ciH
bkhE9bakLlexclv3Jb+iQ2Cyp2FFo1wzLSADRRMEz1EvFFUoDo/Wj2SUQnaq
LNA8tKkRBuW0tUf88aK66TcdRINghhAcEqVJtwRIXF7fI5Arv6N+ql8heD3O
4/jA6c/8iExS0dE=
=6ftE
-----END PGP PUBLIC KEY BLOCK-----

Re: couchdb internals doc repo

Posted by Jan Lehnardt <ja...@apache.org>.
+1 too, I’ve wanted to start this for a while, thanks for taking the initiative Benoit!

Best
Jan
--

On 20 Oct 2013, at 16:39 , Alexander Shorin <kx...@gmail.com> wrote:

> +1 to have this information in docs. One good docs to describe all the couch! (:
> 
> P.S. I'll submit new replication protocol definition for review a bit
> later today.
> --
> ,,,^..^,,,
> 
> 
> On Sun, Oct 20, 2013 at 6:01 PM, Garren Smith <ga...@apache.org> wrote:
>> Hi Benoit,
>> 
>> This is a great idea. I also think this should be in the docs. Many people will find it easy to access from there.
>> 
>> Cheers
>> Garren
>> 
>> On 20 Oct 2013, at 2:03 PM, Noah Slater <ns...@apache.org> wrote:
>> 
>>> I think if we're documenting CouchDB internals, and other dev topics
>>> relating to CouchDB, then it's fine for that stuff to live inside the
>>> CouchDB manual. We host it online, so people can access it without having
>>> to download CouchDB itself.
>>> 
>>> Also, you can edit ReST directly from Github. So contributing should be as
>>> easy as forking your branch, and then editing the file in the Github
>>> interface itself. At least, I think that's how Alexander imagines people
>>> might contribute!
>>> 
>>> 
>>> On 20 October 2013 13:59, Benoit Chesneau <bc...@gmail.com> wrote:
>>> 
>>>> On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org> wrote:
>>>> 
>>>>> Benoit,
>>>>> 
>>>>> Any way to get commit messages or notifications sent to the mailing list?
>>>>> 
>>>> 
>>>> was about to set it up.
>>>> 
>>>>> 
>>>>> As a community, we've promised to have all major activity happen on the
>>>>> mailing list. Usually, this would apply to code. But I think you could
>>>> say
>>>>> the same about the development documentation. If there is significant
>>>> work
>>>>> going on away from the mailing lists, we may have to do a full IP
>>>> Clearance
>>>>> when we want to merge it back.
>>>>> 
>>>> How difficult would it be fore you to create a new branch for this? And
>>>>> while you're at it, create a new section in the manual that we ship under
>>>>> share/doc. A section for developers. Because we mirror to Github, you
>>>>> should still be able to invite PRs.
>>>>> 
>>>>> 
>>>>> 
>>>> No difficulties really. I just felt like it, since no-one really took care
>>>> about it until now. (we talk about that many time even 2 years ago at the
>>>> summit).
>>>> 
>>>> I can without difficulties (except having to convert it to this ugly
>>>> restructured text) moved it to a branch or even master. I just want to make
>>>> sure anyone is enough comfortable to work on a doc mixed with user things.
>>>> And by anyone I am thinking to people that work on couchdb alternatives.
>>>> 
>>>> - benoit
>>>> 
>>>> 
>>>>> 
>>>>> On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> It came to my mind that a some people are asking how the couchdb
>>>>> internals
>>>>>> are working. Some for implementing alternatives, some to start start to
>>>>>> hack on couchdb and others for pure curiosity.
>>>>>> 
>>>>>> I have started a repository to collect the docs about it:
>>>>>> 
>>>>>> https://github.com/benoitc/couchdb_internals
>>>>>> 
>>>>>> For now it only contains the docs I have about the replication
>>>> algorithm.
>>>>>> If you want to join me in that effort, just open a PR. For those who
>>>> also
>>>>>> want direct commit access, then start with a pr with some content and
>>>> ask
>>>>>> for it. This is that simple.
>>>>>> 
>>>>>> Things that will be accepted on that repo are:
>>>>>> 
>>>>>> - docs
>>>>>> - corrections
>>>>>> - anything that can help to maintain and display such docs.
>>>>>> 
>>>>>> Part of the docs could eventually be merged later in the couchdb
>>>>> repository
>>>>>> but I also think that having such repo outside can also be a good start
>>>>> for
>>>>>> a collaboration between many projects around and share new
>>>>>> ideas/implementations details.
>>>>>> 
>>>>>> 
>>>>>> Anyway will be on irc or on the ml if you want to discuss about it.
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> - benoit
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Noah Slater
>>>>> https://twitter.com/nslater
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Noah Slater
>>> https://twitter.com/nslater
>> 


Re: couchdb internals doc repo

Posted by Alexander Shorin <kx...@gmail.com>.
+1 to have this information in docs. One good docs to describe all the couch! (:

P.S. I'll submit new replication protocol definition for review a bit
later today.
--
,,,^..^,,,


On Sun, Oct 20, 2013 at 6:01 PM, Garren Smith <ga...@apache.org> wrote:
> Hi Benoit,
>
> This is a great idea. I also think this should be in the docs. Many people will find it easy to access from there.
>
> Cheers
> Garren
>
> On 20 Oct 2013, at 2:03 PM, Noah Slater <ns...@apache.org> wrote:
>
>> I think if we're documenting CouchDB internals, and other dev topics
>> relating to CouchDB, then it's fine for that stuff to live inside the
>> CouchDB manual. We host it online, so people can access it without having
>> to download CouchDB itself.
>>
>> Also, you can edit ReST directly from Github. So contributing should be as
>> easy as forking your branch, and then editing the file in the Github
>> interface itself. At least, I think that's how Alexander imagines people
>> might contribute!
>>
>>
>> On 20 October 2013 13:59, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org> wrote:
>>>
>>>> Benoit,
>>>>
>>>> Any way to get commit messages or notifications sent to the mailing list?
>>>>
>>>
>>> was about to set it up.
>>>
>>>>
>>>> As a community, we've promised to have all major activity happen on the
>>>> mailing list. Usually, this would apply to code. But I think you could
>>> say
>>>> the same about the development documentation. If there is significant
>>> work
>>>> going on away from the mailing lists, we may have to do a full IP
>>> Clearance
>>>> when we want to merge it back.
>>>>
>>> How difficult would it be fore you to create a new branch for this? And
>>>> while you're at it, create a new section in the manual that we ship under
>>>> share/doc. A section for developers. Because we mirror to Github, you
>>>> should still be able to invite PRs.
>>>>
>>>>
>>>>
>>> No difficulties really. I just felt like it, since no-one really took care
>>> about it until now. (we talk about that many time even 2 years ago at the
>>> summit).
>>>
>>> I can without difficulties (except having to convert it to this ugly
>>> restructured text) moved it to a branch or even master. I just want to make
>>> sure anyone is enough comfortable to work on a doc mixed with user things.
>>> And by anyone I am thinking to people that work on couchdb alternatives.
>>>
>>> - benoit
>>>
>>>
>>>>
>>>> On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> It came to my mind that a some people are asking how the couchdb
>>>> internals
>>>>> are working. Some for implementing alternatives, some to start start to
>>>>> hack on couchdb and others for pure curiosity.
>>>>>
>>>>> I have started a repository to collect the docs about it:
>>>>>
>>>>> https://github.com/benoitc/couchdb_internals
>>>>>
>>>>> For now it only contains the docs I have about the replication
>>> algorithm.
>>>>> If you want to join me in that effort, just open a PR. For those who
>>> also
>>>>> want direct commit access, then start with a pr with some content and
>>> ask
>>>>> for it. This is that simple.
>>>>>
>>>>> Things that will be accepted on that repo are:
>>>>>
>>>>> - docs
>>>>> - corrections
>>>>> - anything that can help to maintain and display such docs.
>>>>>
>>>>> Part of the docs could eventually be merged later in the couchdb
>>>> repository
>>>>> but I also think that having such repo outside can also be a good start
>>>> for
>>>>> a collaboration between many projects around and share new
>>>>> ideas/implementations details.
>>>>>
>>>>>
>>>>> Anyway will be on irc or on the ml if you want to discuss about it.
>>>>>
>>>>> Best,
>>>>>
>>>>> - benoit
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Noah Slater
>>>> https://twitter.com/nslater
>>>>
>>>
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>

Re: couchdb internals doc repo

Posted by Garren Smith <ga...@apache.org>.
Hi Benoit,

This is a great idea. I also think this should be in the docs. Many people will find it easy to access from there.

Cheers
Garren

On 20 Oct 2013, at 2:03 PM, Noah Slater <ns...@apache.org> wrote:

> I think if we're documenting CouchDB internals, and other dev topics
> relating to CouchDB, then it's fine for that stuff to live inside the
> CouchDB manual. We host it online, so people can access it without having
> to download CouchDB itself.
> 
> Also, you can edit ReST directly from Github. So contributing should be as
> easy as forking your branch, and then editing the file in the Github
> interface itself. At least, I think that's how Alexander imagines people
> might contribute!
> 
> 
> On 20 October 2013 13:59, Benoit Chesneau <bc...@gmail.com> wrote:
> 
>> On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org> wrote:
>> 
>>> Benoit,
>>> 
>>> Any way to get commit messages or notifications sent to the mailing list?
>>> 
>> 
>> was about to set it up.
>> 
>>> 
>>> As a community, we've promised to have all major activity happen on the
>>> mailing list. Usually, this would apply to code. But I think you could
>> say
>>> the same about the development documentation. If there is significant
>> work
>>> going on away from the mailing lists, we may have to do a full IP
>> Clearance
>>> when we want to merge it back.
>>> 
>> How difficult would it be fore you to create a new branch for this? And
>>> while you're at it, create a new section in the manual that we ship under
>>> share/doc. A section for developers. Because we mirror to Github, you
>>> should still be able to invite PRs.
>>> 
>>> 
>>> 
>> No difficulties really. I just felt like it, since no-one really took care
>> about it until now. (we talk about that many time even 2 years ago at the
>> summit).
>> 
>> I can without difficulties (except having to convert it to this ugly
>> restructured text) moved it to a branch or even master. I just want to make
>> sure anyone is enough comfortable to work on a doc mixed with user things.
>> And by anyone I am thinking to people that work on couchdb alternatives.
>> 
>> - benoit
>> 
>> 
>>> 
>>> On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> It came to my mind that a some people are asking how the couchdb
>>> internals
>>>> are working. Some for implementing alternatives, some to start start to
>>>> hack on couchdb and others for pure curiosity.
>>>> 
>>>> I have started a repository to collect the docs about it:
>>>> 
>>>> https://github.com/benoitc/couchdb_internals
>>>> 
>>>> For now it only contains the docs I have about the replication
>> algorithm.
>>>> If you want to join me in that effort, just open a PR. For those who
>> also
>>>> want direct commit access, then start with a pr with some content and
>> ask
>>>> for it. This is that simple.
>>>> 
>>>> Things that will be accepted on that repo are:
>>>> 
>>>> - docs
>>>> - corrections
>>>> - anything that can help to maintain and display such docs.
>>>> 
>>>> Part of the docs could eventually be merged later in the couchdb
>>> repository
>>>> but I also think that having such repo outside can also be a good start
>>> for
>>>> a collaboration between many projects around and share new
>>>> ideas/implementations details.
>>>> 
>>>> 
>>>> Anyway will be on irc or on the ml if you want to discuss about it.
>>>> 
>>>> Best,
>>>> 
>>>> - benoit
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Noah Slater
>>> https://twitter.com/nslater
>>> 
>> 
> 
> 
> 
> -- 
> Noah Slater
> https://twitter.com/nslater


Re: couchdb internals doc repo

Posted by Noah Slater <ns...@apache.org>.
I think if we're documenting CouchDB internals, and other dev topics
relating to CouchDB, then it's fine for that stuff to live inside the
CouchDB manual. We host it online, so people can access it without having
to download CouchDB itself.

Also, you can edit ReST directly from Github. So contributing should be as
easy as forking your branch, and then editing the file in the Github
interface itself. At least, I think that's how Alexander imagines people
might contribute!


On 20 October 2013 13:59, Benoit Chesneau <bc...@gmail.com> wrote:

> On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org> wrote:
>
> > Benoit,
> >
> > Any way to get commit messages or notifications sent to the mailing list?
> >
>
> was about to set it up.
>
> >
> > As a community, we've promised to have all major activity happen on the
> > mailing list. Usually, this would apply to code. But I think you could
> say
> > the same about the development documentation. If there is significant
> work
> > going on away from the mailing lists, we may have to do a full IP
> Clearance
> > when we want to merge it back.
> >
> How difficult would it be fore you to create a new branch for this? And
> > while you're at it, create a new section in the manual that we ship under
> > share/doc. A section for developers. Because we mirror to Github, you
> > should still be able to invite PRs.
> >
> >
> >
> No difficulties really. I just felt like it, since no-one really took care
> about it until now. (we talk about that many time even 2 years ago at the
> summit).
>
> I can without difficulties (except having to convert it to this ugly
> restructured text) moved it to a branch or even master. I just want to make
> sure anyone is enough comfortable to work on a doc mixed with user things.
> And by anyone I am thinking to people that work on couchdb alternatives.
>
> - benoit
>
>
> >
> > On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > It came to my mind that a some people are asking how the couchdb
> > internals
> > > are working. Some for implementing alternatives, some to start start to
> > > hack on couchdb and others for pure curiosity.
> > >
> > > I have started a repository to collect the docs about it:
> > >
> > > https://github.com/benoitc/couchdb_internals
> > >
> > > For now it only contains the docs I have about the replication
> algorithm.
> > > If you want to join me in that effort, just open a PR. For those who
> also
> > > want direct commit access, then start with a pr with some content and
> ask
> > > for it. This is that simple.
> > >
> > > Things that will be accepted on that repo are:
> > >
> > > - docs
> > > - corrections
> > > - anything that can help to maintain and display such docs.
> > >
> > > Part of the docs could eventually be merged later in the couchdb
> > repository
> > > but I also think that having such repo outside can also be a good start
> > for
> > > a collaboration between many projects around and share new
> > > ideas/implementations details.
> > >
> > >
> > > Anyway will be on irc or on the ml if you want to discuss about it.
> > >
> > > Best,
> > >
> > > - benoit
> > >
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
> >
>



-- 
Noah Slater
https://twitter.com/nslater

Re: couchdb internals doc repo

Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 20, 2013 at 1:09 PM, Noah Slater <ns...@apache.org> wrote:

> Benoit,
>
> Any way to get commit messages or notifications sent to the mailing list?
>

was about to set it up.

>
> As a community, we've promised to have all major activity happen on the
> mailing list. Usually, this would apply to code. But I think you could say
> the same about the development documentation. If there is significant work
> going on away from the mailing lists, we may have to do a full IP Clearance
> when we want to merge it back.
>
How difficult would it be fore you to create a new branch for this? And
> while you're at it, create a new section in the manual that we ship under
> share/doc. A section for developers. Because we mirror to Github, you
> should still be able to invite PRs.
>
>
>
No difficulties really. I just felt like it, since no-one really took care
about it until now. (we talk about that many time even 2 years ago at the
summit).

I can without difficulties (except having to convert it to this ugly
restructured text) moved it to a branch or even master. I just want to make
sure anyone is enough comfortable to work on a doc mixed with user things.
And by anyone I am thinking to people that work on couchdb alternatives.

- benoit


>
> On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:
>
> > Hi all,
> >
> > It came to my mind that a some people are asking how the couchdb
> internals
> > are working. Some for implementing alternatives, some to start start to
> > hack on couchdb and others for pure curiosity.
> >
> > I have started a repository to collect the docs about it:
> >
> > https://github.com/benoitc/couchdb_internals
> >
> > For now it only contains the docs I have about the replication algorithm.
> > If you want to join me in that effort, just open a PR. For those who also
> > want direct commit access, then start with a pr with some content and ask
> > for it. This is that simple.
> >
> > Things that will be accepted on that repo are:
> >
> > - docs
> > - corrections
> > - anything that can help to maintain and display such docs.
> >
> > Part of the docs could eventually be merged later in the couchdb
> repository
> > but I also think that having such repo outside can also be a good start
> for
> > a collaboration between many projects around and share new
> > ideas/implementations details.
> >
> >
> > Anyway will be on irc or on the ml if you want to discuss about it.
> >
> > Best,
> >
> > - benoit
> >
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>

Re: couchdb internals doc repo

Posted by Noah Slater <ns...@apache.org>.
Benoit,

Any way to get commit messages or notifications sent to the mailing list?

As a community, we've promised to have all major activity happen on the
mailing list. Usually, this would apply to code. But I think you could say
the same about the development documentation. If there is significant work
going on away from the mailing lists, we may have to do a full IP Clearance
when we want to merge it back.

How difficult would it be fore you to create a new branch for this? And
while you're at it, create a new section in the manual that we ship under
share/doc. A section for developers. Because we mirror to Github, you
should still be able to invite PRs.



On 20 October 2013 12:32, Benoit Chesneau <bc...@gmail.com> wrote:

> Hi all,
>
> It came to my mind that a some people are asking how the couchdb internals
> are working. Some for implementing alternatives, some to start start to
> hack on couchdb and others for pure curiosity.
>
> I have started a repository to collect the docs about it:
>
> https://github.com/benoitc/couchdb_internals
>
> For now it only contains the docs I have about the replication algorithm.
> If you want to join me in that effort, just open a PR. For those who also
> want direct commit access, then start with a pr with some content and ask
> for it. This is that simple.
>
> Things that will be accepted on that repo are:
>
> - docs
> - corrections
> - anything that can help to maintain and display such docs.
>
> Part of the docs could eventually be merged later in the couchdb repository
> but I also think that having such repo outside can also be a good start for
> a collaboration between many projects around and share new
> ideas/implementations details.
>
>
> Anyway will be on irc or on the ml if you want to discuss about it.
>
> Best,
>
> - benoit
>



-- 
Noah Slater
https://twitter.com/nslater