Ühel kenal päeval, R, 02.12.2016 kell 11:26, kirjutas Matt Turner: > 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. >
That makes me think that it might be an idea to have no KEYWORDS on the intermediate commits. So removing them at first for the -r1 copy in tis example, even if -r0 had them, and then after all is done add back ~arch ones. Just an idea, not even sure I think it's a good idea myself.
