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

Thu Feb 10 13:59:23 UTC 2011

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

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