couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: merge, where is the doc?
Date Wed, 13 Aug 2014 17:20:15 GMT
Derp. Should've been "obviously *can't* give unrestricted access".

On Wed, Aug 13, 2014 at 12:19 PM, Paul Davis
<paul.joseph.davis@gmail.com> 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 <bchesneau@gmail.com> 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

Mime
View raw message