[ckan-dev] Commit policy

[David Read]

How about this:
a) always reference a ticket in the changeset comments or the branch name
b) branch if you think this ticket might require more than one changeset

For Seb's example, maybe the commit comments would be useful here, and
but a ticket would be useful to know why.

Here are some likely scenarios for small commits:

A) a definite need for a particular customer
B) part of some wider naming strategy etc.
C) fixing a bug
D) tinkering to mildly improve something that's been bugging you

I think A & B are likely to need more than one changeset and should go
on a branch. C may only be one changeset, but we should ticket all
bugs so that we can manage them. e.g. we can say which released
versions this applies to, check there is a regression test, keep track
if it shows up in the future.

The real grey area is for case D - unrelated tinkering (and it's
something we all love doing sometimes!). We should realise there is a
cost in:

a) everyone working on default on the same day having to merge or
rebase your changeset
b) it may introduce a bug
c) the release manager worried about how important it is, what it
relates too etc. when it's near a branch for a release
d) this might be an actual bugfix that the person has forgotten to
label or ticket

I think running off a quick ticket to reference it is a reasonable
burden on the commiter, in the light of the costs to others.

And I think learning to branch and merge is a reasonable burden for
all CKAN developers, the same as running the tests before commit.
Maybe we should consider moving to Git if it would keep more people
happy going forward?

Dave

On 15 March 2011 15:09, Seb Bacon <seb.bacon at gmail.com> wrote:
> I'm up for greater discipline... But having said that, I'd quite like
> to make the three-line change below, and I wonder if that, too, needs
> a ticket and a branch?  Is there perhaps a slightly fuzzy area where
> branches aren't necessary (e.g. changes that don't need a change to
> tests)?
>
> Seb
>
>
>
> diff -r ff071cfc5472 ckan/lib/helpers.py
> --- a/ckan/lib/helpers.py       Mon Mar 07 17:11:51 2011 +0000
> +++ b/ckan/lib/helpers.py       Tue Mar 15 14:58:57 2011 +0000
> @@ -113,7 +113,9 @@
>     return unicode(truncate(plain, length=190, indicator='...',
> whole_word=True))
>
>  def icon_url(name):
> -    return '/images/icons/%s.png' % name
> +    from pylons import config
> +    site_url = config.get('ckan.site_url', '')
> +    return '%s/images/icons/%s.png' % (site_url, name)
>
>
>
>
> On 15 March 2011 12:58, James Gardner <james_archive at 3aims.com> wrote:
>> Yes, we should push for greater discipline.
>>
>> Please only commit to branches and only if there is a ticket. I know I've
>> been breaking this rule too for my doc changes but I'll try harder not to as
>> well.
>>
>> Cheers,
>>
>> James
>>
>>
>> On 15/03/11 11:03, David Read wrote:
>>>
>>> In the past week it seems everyone (myself included) has been making
>>> repeated commits to CKAN code without a branch or referencing tickets.
>>> I'm flagging it because this isn't what we collectively decided to aim
>>> for a few weeks ago. Are we comfortable with this or do people think
>>> we should push for greater discipline in the process?
>>>
>>> David
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>