1 |
On Fri, 2 Dec 2016 18:14:05 +0300 |
2 |
Andrew Savchenko <bircoph@g.o> wrote: |
3 |
|
4 |
> Hi all! |
5 |
> |
6 |
> Right now we have two somewhat conflicting policies (at least up to |
7 |
> my understanding of them): |
8 |
> |
9 |
> 1) git atomic commits [1]: |
10 |
> each logical change should be a separate commit. |
11 |
> |
12 |
> 2) revision bump policy [2]: |
13 |
> each change sufficiently affecting application run-time or |
14 |
> installed files should have a revision bump. |
15 |
> |
16 |
> Let's consider the following quite common scenario: package foo-1.0 |
17 |
> should be updated to foo-1.1, but aside from version bump there is |
18 |
> a set of accumulated issues which maintainer is willing to handle, |
19 |
> e.g.: |
20 |
> - bump to EAPI 6; |
21 |
> - fix several runtime bugs (still present in the new version); |
22 |
> - install missing documentation; |
23 |
> - add previously omitted USE flags for some tools of controllable |
24 |
> functionalities; |
25 |
> - etc... |
26 |
> |
27 |
> If both policies are to be followed, users will see something like: |
28 |
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as |
29 |
> a separate commit with a revision bump). |
30 |
> |
31 |
> While such versioning change is technically correct, it is |
32 |
> confusing for our users and makes future maintainance harder, |
33 |
> because of multiple file renames (yeah, I know about git diff |
34 |
> --find-renames, but this kludge is not perfect). |
35 |
|
36 |
To be honest, I don't really see how multiple successive renames are |
37 |
really any worse than a single rename in git. Not that I oppose your |
38 |
idea, just nitpicking. |
39 |
|
40 |
> What about the following forkflow: |
41 |
> - version bump first with minimal changes required, but without |
42 |
> pushing commit to the tree; |
43 |
> - make each logical change as a separate commit without revision |
44 |
> bumps and without pushing stuff to the tree (of course repoman |
45 |
> scan/full is required as usual for each commit); |
46 |
> - well test package after the last commit (that it builds with |
47 |
> various USE flag combinations, old and new functionality works fine |
48 |
> and so on); |
49 |
> - fix any problems found and only afterwards push changes to the |
50 |
> tree. |
51 |
> |
52 |
> This way users will see only foo-1.0 -> foo-1.1 change in the tree, |
53 |
> while git will still retain each logical change as a separate |
54 |
> commit, which will make future maintenance and debugging much |
55 |
> easier. |
56 |
|
57 |
Well, this is pretty much what we're doing and what fits common sense, |
58 |
and I'm not sure if we really need to word this into a formal policy. |
59 |
|
60 |
The definition of 'one logical change' is pretty inconclusive. One |
61 |
could claim the whole bump to be one logical change, and I don't think |
62 |
that we should really force people to split every change into a single |
63 |
commit because it is too cumbersome. |
64 |
|
65 |
What really makes sense is using the common sense to determine which |
66 |
changes are best made together, and which really deserve a separate |
67 |
commit. And of course, once a revbump or version bump is necessary, you |
68 |
have to do it on the first commit involved (to avoid altering the old |
69 |
file, in case you are keeping it) and you don't have to bump further |
70 |
until the thing hits users. |
71 |
|
72 |
What we need to keep in mind is the spirit of doing split commits -- |
73 |
it's meant to: |
74 |
|
75 |
a) ease reviewing, through providing better context for each change, |
76 |
|
77 |
b) ease reverting, especially in case one of the changes is more likely |
78 |
to cause mayhem than others. |
79 |
|
80 |
-- |
81 |
Best regards, |
82 |
Michał Górny |
83 |
<http://dev.gentoo.org/~mgorny/> |