[ckan-dev] CHANGELOG for CKAN 2.0

[Vitor Baptista]

Hi Sean,

2013/3/11 Sean Hammond <sean.hammond at okfn.org>

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


What's the difference between rebasing/amending commits in a branch, or
deleting that branch and creating a new one? IHMO, changing history has the
same problems as deleting it. We use code reviews, so we need to show our
code not in its final state to gather feedback or ask for help. This
naturally creates a few refactoring or tidying-up commits, which don't add
much value to our history IMHO.

Linus' suggestion in http://lwn.net/Articles/328438/ is to, if you want to
ask for suggestions/feedback, do that in a private repository, or send
patches around. I understand why they do that. Specially him, as the main
repository is his, and there're a few other devs that people follow.
There's no "Linux Foundation" repository. But for us, I feel it just makes
the process even more cumbersome.

I'm not so sure about that (we haven't imported trac tickets into github
> issues, for example).


But that wasn't because we couldn't, just because we didn't thought it was
worthy, right?

Cheers,
Vítor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130311/da58cad5/attachment-0001.html>