1 |
On Sun, 23 Sep 2018 17:45:27 -0500 |
2 |
Matthew Thode <prometheanfire@g.o> wrote: |
3 |
|
4 |
> On 18-09-24 09:27:57, Kent Fredric wrote: |
5 |
> > On Sat, 22 Sep 2018 15:36:23 -0500 |
6 |
> > Matthew Thode <prometheanfire@g.o> wrote: |
7 |
> > > My hand slipped. What ever happened to assuming the best :( Are you |
8 |
> > > going to ping the list every time my hand slips up and I mistype |
9 |
> > > something? Not sure you'll have time for it :P |
10 |
> > |
11 |
> > Personally, I would love it if more people tried harder to provide |
12 |
> > meaningful commit messages. |
13 |
> > |
14 |
> > "bup" vs "bump" isn't really achieving much, just one of the two are |
15 |
> > substantially more egregious. |
16 |
> > |
17 |
> > Perhaps, if the commit messages were crafted with clarity as their |
18 |
> > intent, the consequence of accidental typos would be much more |
19 |
> > inconsequential. |
20 |
> > |
21 |
> > ( I seriously think we could do with a *little* more chiding here than |
22 |
> > we generally see, but like, I'm typically just biting my tongue every |
23 |
> > time somebody doesn't invest any more effort than to write the word |
24 |
> > "bump" in their text editor when committing with repoman, cos I really |
25 |
> > don't want to be a dick about it. There's room for more than 4 |
26 |
> > characters and a space in the subject, and infinitely more space in the |
27 |
> > body, why do we have to choose the least clear of all options? ) |
28 |
> > |
29 |
> > Occasional accidents are still gonna happen, but it would be nice if we |
30 |
> > didn't define accidents and siblings of accidents as the status quo. |
31 |
> > |
32 |
> |
33 |
> What would you rather see for when a package is bumped (that is, simply |
34 |
> copying the ebuild and editing the keywords)? |
35 |
> |
36 |
|
37 |
I personally try to use something of the form: |
38 |
|
39 |
"Bump version to 12.234.1567" |
40 |
|
41 |
Mostly, because it gives some vaguely useful context when reading a |
42 |
commit summary log, that doesn't necessitate you running "git log -p" |
43 |
or "git diff" to find out what actually changed. |
44 |
|
45 |
This lends itself to good user-feedback mechanisms when the log is |
46 |
relayed via IRC on #gentoo-commits, and allows one to determine what's |
47 |
going on at-a-glance via gitweb. |
48 |
|
49 |
If the version bump is in response to a bug request, I'll try to |
50 |
mention that in the subject too. |
51 |
|
52 |
If I made changes in the ebuild in the bump itself, I'll attempt to |
53 |
describe the nature of those changes (from the perspective of the |
54 |
consumer)' |
55 |
|
56 |
And where possible, I attempt to summarize the nature of the changes |
57 |
between our largest in-tree version and the new version, as far as |
58 |
upstream changes are concerned. |
59 |
|
60 |
Eg: if version went from 1.0 to 1.3, but 1.1-1.2 existed, |
61 |
I'll attempt a summary for the imagined user upgrading from 1.0 to 1.3. |
62 |
If for instance something is added in 1.1 and then redacted in 1.2, |
63 |
there's no need to mention that in 1.0 -> 1.3. |
64 |
|
65 |
I Try to think of it as "a list of reasons why a user might want to |
66 |
upgrade, or might want to avoid upgrading" from a context of "xxx |
67 |
changed, if you were using this your code might break" or "xxx is new, |
68 |
if you need this, you need to upgrade" |
69 |
|
70 |
All of this is "nice to have" stuff I'd try to gently nudge others into |
71 |
the direction of, in effort to provide useful information to not only |
72 |
our users, but to other developers, and our future selves looking back |
73 |
in the history trying to ascertain the importance of a given version. |
74 |
|
75 |
Achieving all of the above is of course not always possible, sometimes |
76 |
there are too many changes to summarize, or upstream is made of too |
77 |
much insane for you to assess the differences, that's life. |
78 |
|
79 |
But you can imagine how I get *just* a little bit frustrated when this |
80 |
is the sort of direction I'm trying to aspire towards, but what I'm |
81 |
seeing on the list is debates about "bup" vs "bump" :) |