Derp. Should've been "obviously *can't* give unrestricted access".
On Wed, Aug 13, 2014 at 12:19 PM, Paul Davis <[email protected]> wrote: > 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
