1 |
On 12/02/2016 07:14 AM, Andrew Savchenko wrote: |
2 |
> Hi all! |
3 |
> |
4 |
> Right now we have two somewhat conflicting policies (at least up to |
5 |
> my understanding of them): |
6 |
> |
7 |
> 1) git atomic commits [1]: |
8 |
> each logical change should be a separate commit. |
9 |
> |
10 |
> 2) revision bump policy [2]: |
11 |
> each change sufficiently affecting application run-time or |
12 |
> installed files should have a revision bump. |
13 |
> |
14 |
> Let's consider the following quite common scenario: package foo-1.0 |
15 |
> should be updated to foo-1.1, but aside from version bump there is |
16 |
> a set of accumulated issues which maintainer is willing to handle, |
17 |
> e.g.: |
18 |
> - bump to EAPI 6; |
19 |
> - fix several runtime bugs (still present in the new version); |
20 |
> - install missing documentation; |
21 |
> - add previously omitted USE flags for some tools of controllable |
22 |
> functionalities; |
23 |
> - etc... |
24 |
> |
25 |
> If both policies are to be followed, users will see something like: |
26 |
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as |
27 |
> a separate commit with a revision bump). |
28 |
> |
29 |
> While such versioning change is technically correct, it is |
30 |
> confusing for our users and makes future maintainance harder, |
31 |
> because of multiple file renames (yeah, I know about git diff |
32 |
> --find-renames, but this kludge is not perfect). |
33 |
> |
34 |
> What about the following forkflow: |
35 |
> - version bump first with minimal changes required, but without |
36 |
> pushing commit to the tree; |
37 |
> - make each logical change as a separate commit without revision |
38 |
> bumps and without pushing stuff to the tree (of course repoman |
39 |
> scan/full is required as usual for each commit); |
40 |
> - well test package after the last commit (that it builds with |
41 |
> various USE flag combinations, old and new functionality works fine |
42 |
> and so on); |
43 |
> - fix any problems found and only afterwards push changes to the |
44 |
> tree. |
45 |
> |
46 |
> This way users will see only foo-1.0 -> foo-1.1 change in the tree, |
47 |
> while git will still retain each logical change as a separate |
48 |
> commit, which will make future maintenance and debugging much |
49 |
> easier. |
50 |
> |
51 |
> Of course a separate git branch may be used as well, but using |
52 |
> branches for each half-a-dozen set of commits looks like an |
53 |
> overkill to me. |
54 |
> |
55 |
> Thoughts, comments? |
56 |
> |
57 |
> [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html |
58 |
> [2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html |
59 |
> |
60 |
> Best regards, |
61 |
> Andrew Savchenko |
62 |
> |
63 |
I've always worked as if each commit needed to be working for Gentoo |
64 |
users. So if I need to version bump, that's a separate commit. However, |
65 |
let's say I found a bug in the ebuild itself for foo-1.0. The way I see |
66 |
it is I should bump to foo-1.0-r1 to fix the bug in that ebuild, _then_ |
67 |
version bump so that foo-1.1 already has the fixes that foo-1.0-r1 has. |
68 |
If I version bump first, then I have to revbump both and that just |
69 |
increases my odds of forgetting to put the fixes into all the correct |
70 |
ebuilds. |
71 |
|
72 |
It results in the appropriate fixes in the older package, and the new |
73 |
version comes with the old one's fixes (plus any changes the new ebuild |
74 |
might need due to upstream changes). |
75 |
|
76 |
Does that make any sense? |
77 |
|
78 |
-- |
79 |
Daniel Campbell - Gentoo Developer |
80 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
81 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |