[ckan-dev] CHANGELOG for CKAN 2.0

Mon Mar 11 11:30:02 UTC 2013

On 11 March 2013 11:03, Sean Hammond <sean.hammond at okfn.org> wrote:
>> I think we should start doing it in the pull requests. I don't know if you
>> agree, but I guess writing it a few months after the code was written,
>> whenever we do the release, is too much work (and error prone).
>
> Yeah it sucks. Writing the changelog as we go would be better if we
> could do it, yes. If we do have to write the whole changelog at release
> time then having smaller more frequent releases would make it easier.
>
>> I think this is mainly because we a) work on branches inside the main repo,
>> and; b) consider branches in the main repo to be public, so don't
>> amend/rebase/change commits. To solve this, IMO, we need to change either
>> a) or b).
>
> I think once a commit has been pushed to any repo on github (including
> your own fork!) then it's public and shouldn't be changed, e.g. should
> not be deleted or amended. You can rebase but as I understand it you
> should do the rebase on a new branch and pull request. But I'm not sure
> what the best practices are here as we've never really done rebasing in
> CKAN.

I personally find working across repos is a pain I want to be able to
do all git stuff like log/cherry-pick etc and I can't if you do stuff
in your repo.  Just use a branch in the main repo.  If you want a nice
clean branch then just make a new one. but splitting across repos
seems madness.  Our commit history is ugly but lets clean it properly
not by hiding stuff elsewhere.  We need to just keep making progress

Also not sure github issues work well with other repo code.

>
>> This is a good point, to give a summary of the discussions that led to
>> the commit.
>>
>> But I guess we're OK relying on GitHub issues as well. If they ever
>> get out of business (or we move to a new tool), we'll probably not
>> only import the code, but also their issues and pr, to our new home.
>
> I'm not so sure about that (we haven't imported trac tickets into github
> issues, for example).

yeah fresh start was good :) maybe we should just delete all the
issues every 3 months :p

>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev