| | <<<Back 1 day (to 2016/06/23) | 20160624 |
| PaulePanter | Hi. Would you be willing to accept a patch to support reproducible builds? | 11:47.28 |
| | https://anonscm.debian.org/cgit/printing/ghostscript.git/tree/debian/patches/2010_add_build_timestamp_setting.patch | 11:47.33 |
| | That means, should I open a ticket for that? | 11:47.42 |
| chrisl | PaulePanter: We've already argued that at length, and we couldn't come to an accommodation that both parties were happy with | 11:49.42 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=696765 | 11:50.17 |
| PaulePanter | chrisl: Interesting. Thank you for providing that URL. | 14:53.20 |
| | chrisl: Is there a reason why `Makefile` is not part of `.gitignore` after being removed in commit 6948650 (Commit of build_consolidation branch). | 15:24.21 |
| chrisl | PaulePanter: I forgot | 15:24.39 |
| PaulePanter | hopes that commits from a branch are not squashed into one commit in the Ghostscript project anymore. | 15:24.51 |
| | chrisl: Do you want me to send a patch? | 15:24.58 |
| chrisl | No, I have it - I haven't pushed it yet | 15:25.19 |
| PaulePanter | chrisl: Understood. | 15:26.59 |
| chrisl | PaulePanter: branches are always squash to one commit before inclusion onto master | 15:27.37 |
| | PaulePanter: our policy is to keep the branch with all the individual commits, so the history is still available | 15:28.55 |
| PaulePanter | chrisl: What is the reason for such a policy? | 15:30.21 |
| chrisl | PaulePanter: Doing otherwise breaks our regression testing | 15:31.50 |
| Robin_Watts | To be clearer... where possible we develop stuff so that every commit works and tests out cleanly. When we can do that, we rebase onto the tip of master and commit the whole lot at once. | 15:36.00 |
| | Where that is not possible, we are faced with the choice of committing a branch with broken stages in, which makes bisection hard. | 15:36.39 |
| | Hence we commit the entire branch so we keep a historical record of the changes, but only put the squashed version onto master. | 15:37.14 |
| PaulePanter | I still do not fully understand that. Because the regression testing needs a linear(?) tree? | 15:38.02 |
| Robin_Watts | PaulePanter: There are 2 issues. | 15:38.30 |
| | 1) Having failing commits within the tree makes it hard to bisect. | 15:38.47 |
| | 2) Having merges gives the regression testing a hernia. | 15:39.06 |
| | hence we endeavour to keep a linear tree. | 15:39.19 |
| PaulePanter | Robin_Watts: Shouldnât it be possible to ensure that each commit in a branch builds fine? | 15:41.09 |
| Robin_Watts | PaulePanter: And tests out fine? | 15:41.26 |
| | In many cases, yes. | 15:41.32 |
| PaulePanter | Sure. | 15:41.33 |
| Robin_Watts | In some cases, such as where large amounts of refactoring are done, that's harder to achieve. | 15:41.54 |
| | In those cases, that's when we flatten. | 15:42.06 |
| PaulePanter | What regression testing system do you use. I still do not see a difference between squashing commits from a branch to one commit or merging that branch. (Especially if it has been rebased on master beforehand.) | 15:42.33 |
| Robin_Watts | PaulePanter: It's custom software of our own, running a cluster of machines. | 15:47.28 |
| PaulePanter | I see. | 15:48.23 |
| | I still have a hard time to understand it, as a merge is nothing also in my understand. | 15:48.47 |
| | bbl | 15:48.52 |
| PaulePanter | thinks itâs not a good idea to discuss the merits of squashing commits on a Friday evening and will think more about it over the weekend. | 20:16.56 |
| | Forward 1 day (to 2016/06/25)>>> | |
IRC Logs