1 |
On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt <m.j.everitt@×××.org> wrote: |
2 |
|
3 |
> On 23/09/18 22:27, Kent Fredric wrote: |
4 |
> > On Sat, 22 Sep 2018 15:36:23 -0500 |
5 |
> > Matthew Thode <prometheanfire@g.o> wrote: |
6 |
> >> My hand slipped. What ever happened to assuming the best :( Are you |
7 |
> >> going to ping the list every time my hand slips up and I mistype |
8 |
> >> something? Not sure you'll have time for it :P |
9 |
> > Personally, I would love it if more people tried harder to provide |
10 |
> > meaningful commit messages. |
11 |
> > |
12 |
> > "bup" vs "bump" isn't really achieving much, just one of the two are |
13 |
> > substantially more egregious. |
14 |
> > |
15 |
> > Perhaps, if the commit messages were crafted with clarity as their |
16 |
> > intent, the consequence of accidental typos would be much more |
17 |
> > inconsequential. |
18 |
> > |
19 |
> > ( I seriously think we could do with a *little* more chiding here than |
20 |
> > we generally see, but like, I'm typically just biting my tongue every |
21 |
> > time somebody doesn't invest any more effort than to write the word |
22 |
> > "bump" in their text editor when committing with repoman, cos I really |
23 |
> > don't want to be a dick about it. There's room for more than 4 |
24 |
> > characters and a space in the subject, and infinitely more space in the |
25 |
> > body, why do we have to choose the least clear of all options? ) |
26 |
> > |
27 |
> > Occasional accidents are still gonna happen, but it would be nice if we |
28 |
> > didn't define accidents and siblings of accidents as the status quo. |
29 |
> > |
30 |
> I think Kent has pretty much the point here .. we try to stipulate that |
31 |
> the commit message describes what the update is, and is clear for *all* |
32 |
> users of the repository, and not just the relevant maintainer. There is |
33 |
> also a cronic double-standard for existing or long-standing devs, and |
34 |
> newer devs, recruits and proxy-maintainers (who get a double-scrutiny |
35 |
> typically) - and I could easily see how this breeds resentment... |
36 |
> |
37 |
> Perhaps it would be simple enough to add a check to repoman for commit |
38 |
> messages less than 10 characters, and with at least one *additional* |
39 |
> space, mandating two words in the commit message. It seems draconian, |
40 |
> but if developers continue to be lazy, what choice does one have?! |
41 |
> |
42 |
> |
43 |
I don't see a problem with 'version bump' as a description. Sometimes you |
44 |
bump an ebuild because upstream released a new version and you want to |
45 |
track. I'm fairly against changes describing what was changed (typically |
46 |
the reader can git show and observe the changes.) The useful information is |
47 |
*why* the change was made. Sometimes its because "upstream released a new |
48 |
version." |
49 |
|
50 |
Like Matt I'm curious what others expect to see in the description. |
51 |
|
52 |
-A |