Re: Nonlinear git-buildpackage workflow?
Hi Ferenc, On Sun, Aug 12, 2018 at 09:56:17AM +0200, Ferenc Wágner wrote: > Lumin writes: > > > The problem is, if I maintain the two releases in parallel, the > > dch would become a mess when moving the 1.0 release to sid. > > dch will contain duplicated changelog entries (e.g. fixing > > common problems found in both 0.7 and 1.0) and the timeline > > is also screwed up. > > Do you know dpkg-mergechangelogs? I think fixing common problems in the > experimental branch and periodically merging it into the unstable branch > would work out fairly well with its help. Of course you'd still have to > fix up the version number after the merge. Thank you for this reminder! I had forgotten to activate the merge driver in .git/info/attributes in the repo of the one bpo I maintain where a no-change bpo is not possible. For anyone else reading this, the easy and convenient solution is at the bottom of dpkg-mergechangelogs(1) <- and that's a manpage. So with gbp, you git merge the new debian tag, the mergechangelogs magic occurs, then you 'dch --bpo', commit the changelog, and you're good to go--unless new changes are required, of course! Cheers, Nicholas signature.asc Description: PGP signature
Re: Nonlinear git-buildpackage workflow?
Lumin writes: > The problem is, if I maintain the two releases in parallel, the > dch would become a mess when moving the 1.0 release to sid. > dch will contain duplicated changelog entries (e.g. fixing > common problems found in both 0.7 and 1.0) and the timeline > is also screwed up. Do you know dpkg-mergechangelogs? I think fixing common problems in the experimental branch and periodically merging it into the unstable branch would work out fairly well with its help. Of course you'd still have to fix up the version number after the merge. -- Regards, Feri
Nonlinear git-buildpackage workflow?
Hi mentors, I'm one of the julia package maintainers and I encountered a temporary non-linear workflow problem. Julia released two stable releases in parallel, 0.7 and 1.0 . I uploaded 0.7 to unstable and planned to upload 1.0 to exp. After a round of bug fix in the future the 1.0 release should eventually replace the 0.7 release in sid. The problem is, if I maintain the two releases in parallel, the dch would become a mess when moving the 1.0 release to sid. dch will contain duplicated changelog entries (e.g. fixing common problems found in both 0.7 and 1.0) and the timeline is also screwed up. Unlike the parallel maintenance between sid and stable. I'm not aware of any workflow suitable for this temporary situation. Umm... Maybe the best solution is to fix the remaining problems in 0.7 first, then prepare for the 1.0 upload (serial). @ginggs Opinion? -- Best,
