Le 25 juillet 2017 00:46:03 GMT+02:00, Cyril Brulebois <k...@debian.org> a écrit : >Hi, > >Yves-Alexis Perez <cor...@debian.org> (2017-07-24): >> On Sat, 2017-07-22 at 08:47 +0200, Aurélien COUDERC wrote: >> > With my brand new knowledge of the available tools, I’d go for the >following >> > workflow : >> > - Iterate on : >> > o commit and push changes without touching d/changelog >> > - When ready to push a package, from a clean git tree : >> > o gbp dch -R >> > o Review/fix changelog >> > o git commit -a -m "Prepare for $version release" >> > o gbp buildpackage --git-tag
After a bit more research it can even be trimmed to : - During development cycle : o git commit x n - For release : o gbp dch -R --commit o gbp buildpackage --git-tag >> I usually commit with debcommit, so I do the changelog edit at the >same time. >> Not sure how other teams do though. I'm not really familiar with gbp >workflow >> either. > >FWIW we're also doing changelog edits along with the actual changes on >the >debian-boot@ side, and debcommit -a (plus -e or git commit --amend) >works >just fine; plus there's no special magic when release time comes. Just >dch -r, done. (Worked also fine for debian-x@.) Right, thanks for your feedbacks. I must say I don't like so much to have to edit d/changelog every time during development. In my opinion it mostly contains redundant (= commit messages) and incorrect (release distribution, date, author) information. So I prefer the idea that it can be mostly auto-generated when preparing a release. It must have drawbacks like the need to have a clean git history (drawback, really ?) and probably other things I didn't think of. Thoughts on this ? Cheers, --Aurélien
