Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Revision bumps vs git commits atomicity
Date: Fri, 02 Dec 2016 15:14:40
Message-Id: 20161202181405.0b2fb703db09c061c1c3d595@gentoo.org
1 Hi all!
2
3 Right now we have two somewhat conflicting policies (at least up to
4 my understanding of them):
5
6 1) git atomic commits [1]:
7 each logical change should be a separate commit.
8
9 2) revision bump policy [2]:
10 each change sufficiently affecting application run-time or
11 installed files should have a revision bump.
12
13 Let's consider the following quite common scenario: package foo-1.0
14 should be updated to foo-1.1, but aside from version bump there is
15 a set of accumulated issues which maintainer is willing to handle,
16 e.g.:
17 - bump to EAPI 6;
18 - fix several runtime bugs (still present in the new version);
19 - install missing documentation;
20 - add previously omitted USE flags for some tools of controllable
21 functionalities;
22 - etc...
23
24 If both policies are to be followed, users will see something like:
25 foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
26 a separate commit with a revision bump).
27
28 While such versioning change is technically correct, it is
29 confusing for our users and makes future maintainance harder,
30 because of multiple file renames (yeah, I know about git diff
31 --find-renames, but this kludge is not perfect).
32
33 What about the following forkflow:
34 - version bump first with minimal changes required, but without
35 pushing commit to the tree;
36 - make each logical change as a separate commit without revision
37 bumps and without pushing stuff to the tree (of course repoman
38 scan/full is required as usual for each commit);
39 - well test package after the last commit (that it builds with
40 various USE flag combinations, old and new functionality works fine
41 and so on);
42 - fix any problems found and only afterwards push changes to the
43 tree.
44
45 This way users will see only foo-1.0 -> foo-1.1 change in the tree,
46 while git will still retain each logical change as a separate
47 commit, which will make future maintenance and debugging much
48 easier.
49
50 Of course a separate git branch may be used as well, but using
51 branches for each half-a-dozen set of commits looks like an
52 overkill to me.
53
54 Thoughts, comments?
55
56 [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html
57 [2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
58
59 Best regards,
60 Andrew Savchenko

Replies