On 02/12/16 10:32 AM, Dirkjan Ochtman wrote: > On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko <birc...@gentoo.org> wrote: >> What about the following forkflow: >> - version bump first with minimal changes required, but without >> pushing commit to the tree; >> - make each logical change as a separate commit without revision >> bumps and without pushing stuff to the tree (of course repoman >> scan/full is required as usual for each commit); >> - well test package after the last commit (that it builds with >> various USE flag combinations, old and new functionality works fine >> and so on); >> - fix any problems found and only afterwards push changes to the >> tree. >> >> This way users will see only foo-1.0 -> foo-1.1 change in the tree, >> while git will still retain each logical change as a separate >> commit, which will make future maintenance and debugging much >> easier. >> >> Of course a separate git branch may be used as well, but using >> branches for each half-a-dozen set of commits looks like an >> overkill to me. >> >> Thoughts, comments? > > Sounds sensible to me, possibly to the point of not having to spell it > out? (As in, I don't see the mentioned policies as necessarily > conflicting.) > > Cheers, > > Dirkjan >
If it matters, it may make sense to adhere to the order of operations presented above more precisely. For instance, I tend to do all of the minor changes first and then revbump the ebuild (usually because I'm adjusting these changes over a few days and then evaluate if it needs a revbump once it's done).
signature.asc
Description: OpenPGP digital signature
