On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko <birc...@gentoo.org> wrote: > Hi all! > > Right now we have two somewhat conflicting policies (at least up to > my understanding of them): > > 1) git atomic commits [1]: > each logical change should be a separate commit. > > 2) revision bump policy [2]: > each change sufficiently affecting application run-time or > installed files should have a revision bump. > > Let's consider the following quite common scenario: package foo-1.0 > should be updated to foo-1.1, but aside from version bump there is > a set of accumulated issues which maintainer is willing to handle, > e.g.: > - bump to EAPI 6; > - fix several runtime bugs (still present in the new version); > - install missing documentation; > - add previously omitted USE flags for some tools of controllable > functionalities; > - etc... > > If both policies are to be followed, users will see something like: > foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as > a separate commit with a revision bump). > > While such versioning change is technically correct, it is > confusing for our users and makes future maintainance harder, > because of multiple file renames (yeah, I know about git diff > --find-renames, but this kludge is not perfect). > > 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?
Thanks for starting the discussion. I completely agree. Though my case might have been a bit more clear-cut since I was working on an ebuild that initially didn't have any KEYWORDS, I think what I did for freeradius is the best way of handling the situation you describe. See 97704b400b7^..e84dc52a816 An initial commit that copied the 3.0.12 ebuild to 3.0.12-r1 without making any other changes, followed by three self-contained fixes/commits, and finally a patch to add KEYWORDS to 3.0.12-r1.
