1 |
On 24/09/18 03:27, Matthew Thode wrote: |
2 |
> On 18-09-23 21:39:01, Alec Warner wrote: |
3 |
>> On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt <m.j.everitt@×××.org> wrote: |
4 |
>> |
5 |
>>> On 23/09/18 22:27, Kent Fredric wrote: |
6 |
>>>> On Sat, 22 Sep 2018 15:36:23 -0500 |
7 |
>>>> Matthew Thode <prometheanfire@g.o> wrote: |
8 |
>>>>> My hand slipped. What ever happened to assuming the best :( Are you |
9 |
>>>>> going to ping the list every time my hand slips up and I mistype |
10 |
>>>>> something? Not sure you'll have time for it :P |
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 |
>>> I think Kent has pretty much the point here .. we try to stipulate that |
33 |
>>> the commit message describes what the update is, and is clear for *all* |
34 |
>>> users of the repository, and not just the relevant maintainer. There is |
35 |
>>> also a cronic double-standard for existing or long-standing devs, and |
36 |
>>> newer devs, recruits and proxy-maintainers (who get a double-scrutiny |
37 |
>>> typically) - and I could easily see how this breeds resentment... |
38 |
>>> |
39 |
>>> Perhaps it would be simple enough to add a check to repoman for commit |
40 |
>>> messages less than 10 characters, and with at least one *additional* |
41 |
>>> space, mandating two words in the commit message. It seems draconian, |
42 |
>>> but if developers continue to be lazy, what choice does one have?! |
43 |
>>> |
44 |
>>> |
45 |
>> I don't see a problem with 'version bump' as a description. Sometimes you |
46 |
>> bump an ebuild because upstream released a new version and you want to |
47 |
>> track. I'm fairly against changes describing what was changed (typically |
48 |
>> the reader can git show and observe the changes.) The useful information is |
49 |
>> *why* the change was made. Sometimes its because "upstream released a new |
50 |
>> version." |
51 |
>> |
52 |
>> Like Matt I'm curious what others expect to see in the description. |
53 |
>> |
54 |
> That's exactly why I release much of the stuff I do, I get a task in |
55 |
> todoist via ifttt monitoring a github atom feed that a new release is |
56 |
> out and I package it. |
57 |
> |
58 |
If you have automated tooling, surely it's not impossible to make that |
59 |
tooling generate a semi-meaningful commit message on-the-fly too ... |
60 |
just sayin' ... |