[ckan-dev] Commit policy
James Gardner
james at 3aims.com
Tue Mar 15 16:03:48 UTC 2011
+1 to all this. I think you've got the balance spot on actually.
I'm treating this as the new policy. Bottom line is that anything that
commits to default should have a ticket.
-1 to moving to git. It's benefit wouldn't out-weigh its cost to learn.
Something to consider again at some point in the future perhaps, if we
all become mercurial experts and still see a greater benefit in git.
Let's not discuss here though.
On 15/03/11 15:51, David Read wrote:
> 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
>>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
More information about the ckan-dev
mailing list