| 1 |
Ühel kenal päeval, R, 02.12.2016 kell 11:26, kirjutas Matt Turner: |
| 2 |
> On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko <bircoph@g.o> |
| 3 |
> wrote: |
| 4 |
> > |
| 5 |
> > Hi all! |
| 6 |
> > |
| 7 |
> > Right now we have two somewhat conflicting policies (at least up to |
| 8 |
> > my understanding of them): |
| 9 |
> > |
| 10 |
> > 1) git atomic commits [1]: |
| 11 |
> > each logical change should be a separate commit. |
| 12 |
> > |
| 13 |
> > 2) revision bump policy [2]: |
| 14 |
> > each change sufficiently affecting application run-time or |
| 15 |
> > installed files should have a revision bump. |
| 16 |
> > |
| 17 |
> > Let's consider the following quite common scenario: package foo-1.0 |
| 18 |
> > should be updated to foo-1.1, but aside from version bump there is |
| 19 |
> > a set of accumulated issues which maintainer is willing to handle, |
| 20 |
> > e.g.: |
| 21 |
> > - bump to EAPI 6; |
| 22 |
> > - fix several runtime bugs (still present in the new version); |
| 23 |
> > - install missing documentation; |
| 24 |
> > - add previously omitted USE flags for some tools of controllable |
| 25 |
> > functionalities; |
| 26 |
> > - etc... |
| 27 |
> > |
| 28 |
> > If both policies are to be followed, users will see something like: |
| 29 |
> > foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as |
| 30 |
> > a separate commit with a revision bump). |
| 31 |
> > |
| 32 |
> > While such versioning change is technically correct, it is |
| 33 |
> > confusing for our users and makes future maintainance harder, |
| 34 |
> > because of multiple file renames (yeah, I know about git diff |
| 35 |
> > --find-renames, but this kludge is not perfect). |
| 36 |
> > |
| 37 |
> > What about the following forkflow: |
| 38 |
> > - version bump first with minimal changes required, but without |
| 39 |
> > pushing commit to the tree; |
| 40 |
> > - make each logical change as a separate commit without revision |
| 41 |
> > bumps and without pushing stuff to the tree (of course repoman |
| 42 |
> > scan/full is required as usual for each commit); |
| 43 |
> > - well test package after the last commit (that it builds with |
| 44 |
> > various USE flag combinations, old and new functionality works fine |
| 45 |
> > and so on); |
| 46 |
> > - fix any problems found and only afterwards push changes to the |
| 47 |
> > tree. |
| 48 |
> > |
| 49 |
> > This way users will see only foo-1.0 -> foo-1.1 change in the tree, |
| 50 |
> > while git will still retain each logical change as a separate |
| 51 |
> > commit, which will make future maintenance and debugging much |
| 52 |
> > easier. |
| 53 |
> > |
| 54 |
> > Of course a separate git branch may be used as well, but using |
| 55 |
> > branches for each half-a-dozen set of commits looks like an |
| 56 |
> > overkill to me. |
| 57 |
> > |
| 58 |
> > Thoughts, comments? |
| 59 |
> |
| 60 |
> Thanks for starting the discussion. I completely agree. |
| 61 |
> |
| 62 |
> Though my case might have been a bit more clear-cut since I was |
| 63 |
> working on an ebuild that initially didn't have any KEYWORDS, I think |
| 64 |
> what I did for freeradius is the best way of handling the situation |
| 65 |
> you describe. |
| 66 |
> |
| 67 |
> See 97704b400b7^..e84dc52a816 |
| 68 |
> |
| 69 |
> An initial commit that copied the 3.0.12 ebuild to 3.0.12-r1 without |
| 70 |
> making any other changes, followed by three self-contained |
| 71 |
> fixes/commits, and finally a patch to add KEYWORDS to 3.0.12-r1. |
| 72 |
> |
| 73 |
|
| 74 |
That makes me think that it might be an idea to have no KEYWORDS on the |
| 75 |
intermediate commits. So removing them at first for the -r1 copy in tis |
| 76 |
example, even if -r0 had them, and then after all is done add back |
| 77 |
~arch ones. |
| 78 |
Just an idea, not even sure I think it's a good idea myself. |
Archives