couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <a...@nms.de>
Subject Re: rcouch+bigcouch merge & need for a "developer" guide
Date Mon, 30 Jun 2014 09:27:47 GMT
I like the idea a lot. I was asking some months ago that it would be cool
to write speaking and informative git commit messages and afaic that
happened :). Your approach Benoit would make the code even more transparent
and "documented". At the end, we would lower the entry barrier for new devs.

But as most of the merge is done by Bob and Russell, and we know how much
work that is (thanks so much!), I think we should leave a big portion of
the decision how to handle this to them.

Speaking here with my "none coredeveloper but testing"-hat on ...

Cheers

Andy


On 30 June 2014 10:19, Benoit Chesneau <bchesneau@gmail.com> wrote:

> Hi,
>
> I started to look at the merge of both branches started by
> sagelywizard who provided me the links on IRC:
>
> https://github.com/sagelywizard/couchdb-couch/tree/working and
> https://github.com/sagelywizard/couchdb-couch-mrview/tree/working
>
> And while I can of course look in the code to see how to merge the
> latest bits (chttpd for the HTTP part and fabric for the merge of
> shards data/feeds) I am wondering if we couldn't take this merge as a
> way to make useful developer documents:
>
> - design of the apps. who interact with. which module does what
> - configuration entry points
> - which things a developer should consider when he write an app or
> edit a code in the code, for example how to monitor a database, how to
> make sure an indexer is counted as a db user, ...
> - how the activity monitor work
> ....
>
> The are some examples. I am not really speaking about the syntax here,
> though a guide can also be provided. Same also should be done for
> fauxton or any part of the code.
>
> Of course it will require some work but it work it imo (and probably a
> lot of works from cloudant guys, sorry). It would open the code to any
> devs, and well... would not force anyone that want to hack to lost
> some time to read each parts of the code before figuring how to hack
> it. It would also force us to make a full review on the current
> branches.
>
> Another point that would be cool would be sharing developer "notes".
>
>
> Thoughts?
>
> - benoit
>



-- 
Andy Wenk
Hamburg - Germany
RockIt!

http://www.couchdb-buch.de
http://www.pg-praxisbuch.de

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

https://people.apache.org/keys/committer/andywenk.asc

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message