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

Thu Feb 10 14:20:51 UTC 2011

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. 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
>