> On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggs<simon@2ndquadrant.com> wrote:
>> I was hoping to fine tune/tweak Sync Rep after feedback during beta,
>> but my understanding of current consensus is that that will be too
>> late to make user visible changes. So I'm proposing this change now,
>> before Beta, rather than during Beta.
>>
> For what it's worth I think this is a simplification. We have:
>
> 1) Development when new features are added
>
> 2) Feature freeze - when those features are tweaked and fixed based on
> our own testing but no new features added
>
> 3) Beta - when features are tweaked and fixed in response to user
> suggestions but no new features added
How to say this short: when testing the latest syncrep patches I've
wasted time looking where the recv|fsync|apply api was, to find out it
was gone. *shrug* didn't need it for my use case. But for others it
might well be frustration to find out that what's currently called
syncrep cannot be configured in a way it's suitable, and that they might
have wasted considerable time while finding that out.
The dba interface for recv|fsync|apply seems to be pretty stable, so
supporting that for years should be without risk. How it works under the
hood - the beta period seems like *the* opportunity to attrach mayor
testing from all people waiting to get their hands on syncrep.
An aspect of a good product is that it doesn't waste users time, like a
good piece of code needs little comment. Alarm bells should go off when
somebody is about to write a large piece of documentation writing what a
feature doesn't support. It would be better to just support it
(recv|fsync|apply), or no syncrep at all. Syncrep is incomplete without it.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
