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