[ckan-dev] Branching policy and standardizing on branch names

Thu Feb 10 14:31:42 UTC 2011

On 10 February 2011 14:20, David Read <david.read at okfn.org> wrote:
> On 10 February 2011 13:59, Seb Bacon <seb.bacon at gmail.com> wrote:
>> On 10 February 2011 13:43, William Waites <ww at styx.org> wrote:
>>> * [2011-02-10 13:02:33 +0000] Seb Bacon <seb.bacon at gmail.com> écrit:
>>> ]
>>> ] Alternatively we could move towards a "continuous development" model
>>> ] where we have complete test coverage, fast automated test builds, easy
>>> ] deployment, feature flags and a "blame" functionality so that everyone
>>> ] can be confident and take responsibility for their own code.
>>>
>>> This is more or less the direction we seem to be taking, but some
>>> of the infrastructure is missing.
>>>
>>> Also, I am very much more inclined towards a few simple happy-path
>>> and obvious-error tests and then regression tests when bugs are
>>> found rather than trying to reach the holy grail of "complete
>>> test coverage".
>
> I agree - there are diminishing returns with test coverage and we're
> not writing a platform requiring the stability of a database.

The purpose of 100% test coverage in my eyes isn't to do with some
asymptotically improving notion of quality which is only appropriate
for a database.

It's because it gives you an easy way to say "no, that code can't be
checked in yet, it doesn't have tests".  Which makes it easier for you
to practise continuous development.

Against this measure ("does it enable continuous development?") 5%,
50%, 99% coverage are all roughly equivalent.

Against the measure "are we defending against regression bugs" then
fixing tests when new bugs appear is sufficient.

I'm happy with either approach and almost always take the latter, but
I just wanted to clarify that for me, the notion of 100% test coverage
isn't about improving quality per se but enabling quick decisions to
be taken about code.  Of course just because something has tests
doesn't mean it does the right thing, but it helps.

Seb

> But we
> do have coverage of most of the happy paths and obvious errors.
> However there are some red flashing lights where we seem to lack ANY
> coverage, and it's probably worth mentioning them again:
>
> #854    authorization_group
> #855    authenticator
> #856    caching
> #857    cli
> #859    User model
>
> Dave
>
>> Practically, I agree that we are unlikely to have the resources to say
>> "right, 100% test coverage from next week".  We can occasionally take
>> it on ourselves to improve some random module's coverage, though.
>>
>> However, if by "holy grail" you mean it's unattainable, I accept the
>> definition of 100% is slightly fuzzy, but I'd say Sqlite's definition
>> of 100% branch coverage is pretty good and is attained :)
>> http://www.sqlite.org/testing.html
>>
>>> ] Pros and cons of both approaches.  The problem with dictator model is
>>> ] bottleneck, things waiting around to be merged, becoming harder to
>>> ] merge with time, etc etc.  The benefit is building in code reviews.
>>>
>>> Agree code review is important in any case. Also agree that bottlenecks
>>> are bad.
>>>
>>> ] So far, I still find git easier to work with, but that is probably
>>> ] mainly about familiarity.
>>>
>>> I think unless we start using very advanced or obscure features
>>> hg and git are pretty much the same from my point of view.
>>
>> I agree.  I just find that git cherry-picking means my commits are
>> cleaner, and I like the git emacs mode a lot more than any of the hg
>> alternatives :)
>>
>>
>>> The
>>> only real advantage mercurial has it is written in python so we
>>> could actually use it directly in our code (an obvious use case
>>> is version management of harvested metadata documents instead
>>> of shoving XML into the database) but that's not something that
>>> we have really exploited at all yet.
>>
>> I didn't know that, interesting.
>>
>> Seb
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>

-- 
skype: seb.bacon
mobile: 07790 939224
land: 0207 183 9618
web: http://baconconsulting.co.uk