Benoit, I'm not exactly sure what you're asking for here. As I read it, it sounds like you're wanting documentation both on the merge process itself and then documentation on all the various things the merge introduces. As to the merge process, there's really not much to document other than "import code as agreed, apply patches that were voted on, fix bugs". The applying of patches and bug fixes its what's been happening in the windsor-merge branches the last few weeks. If instead you're wanting documentation on all the things the merge introduces then you'll have to be more specific on which parts. I would be more than happy to write documentation for major portions of the clustering from an internal perspective. I agree that it would be quite helpful to others that are just starting to learn how this code works and fits together.
Unfortunately there is no trove of documentation inside Cloudant. Historically most of our "design" happens over IRC or as code review. As Bob has said, we obviously can give unrestricted access to our ticketing system but if there are any patches that are curious we can go back and get the historical context/reasoning for changes that seem opaque. On the other hand you seem to be wanting a wider focus discussion on the various sectiosn of code and how they fit together of which there really isn't anything at all. But as I mentioned I'd be more than happy to sit down and write up anything you've got questions on. Let me know what I can do to help. Paul On Wed, Aug 13, 2014 at 1:00 AM, Benoit Chesneau <[email protected]> wrote: > Sometimes in the past we blamed some people because they were committing > big chunks of code not atomically and not really documented. And I am > afraid this is happening right now again. > > This is not the first time I asked for it but could the merge be more > documented? Commits message are not enough and having to pass 1 day or more > to follow all the changes, why they are done, what are their intents, is > not pleasant/fun at all. More important I find myself in waiting everything > is finished to know what can I do with it. And I don't know where we are > going exactly (just a vague idea of what we will have). Some discussion > with others outside about it shows I am not alone. > > Don't get me wrong, I like to see the source code moving. But I think it's > more important to integrate others developers (and not only committers) in > the loop when a change happen. And we shouldn't wait that a branch is > finished before knowing where we are going. We shouldn't have to dive in > the source code of the current master to understand how each modules > interacts, understanding the way decisions are done on the cluster, ..... > Such things should already be documented before to go further. So other > devs can again help if they want to, without losing their times too much in > the basement. The knowledge should be shared with the community. > > I am sure all these chunks of code have been discussed before between > people inside Cloudant, that some design documents have been exchanged, and > some tickets describe more exactly the solved problem. If people don't have > the time to document the wip, maybe at least such material can be shared? > > I hope this situation may be sorted soon. > > - benoit
