On 24/09/18 03:27, Matthew Thode wrote: > On 18-09-23 21:39:01, Alec Warner wrote: >> On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt <m.j.ever...@iee.org> wrote: >> >>> On 23/09/18 22:27, Kent Fredric wrote: >>>> On Sat, 22 Sep 2018 15:36:23 -0500 >>>> Matthew Thode <prometheanf...@gentoo.org> wrote: >>>>> My hand slipped. What ever happened to assuming the best :( Are you >>>>> going to ping the list every time my hand slips up and I mistype >>>>> something? Not sure you'll have time for it :P >>>> Personally, I would love it if more people tried harder to provide >>>> meaningful commit messages. >>>> >>>> "bup" vs "bump" isn't really achieving much, just one of the two are >>>> substantially more egregious. >>>> >>>> Perhaps, if the commit messages were crafted with clarity as their >>>> intent, the consequence of accidental typos would be much more >>>> inconsequential. >>>> >>>> ( I seriously think we could do with a *little* more chiding here than >>>> we generally see, but like, I'm typically just biting my tongue every >>>> time somebody doesn't invest any more effort than to write the word >>>> "bump" in their text editor when committing with repoman, cos I really >>>> don't want to be a dick about it. There's room for more than 4 >>>> characters and a space in the subject, and infinitely more space in the >>>> body, why do we have to choose the least clear of all options? ) >>>> >>>> Occasional accidents are still gonna happen, but it would be nice if we >>>> didn't define accidents and siblings of accidents as the status quo. >>>> >>> I think Kent has pretty much the point here .. we try to stipulate that >>> the commit message describes what the update is, and is clear for *all* >>> users of the repository, and not just the relevant maintainer. There is >>> also a cronic double-standard for existing or long-standing devs, and >>> newer devs, recruits and proxy-maintainers (who get a double-scrutiny >>> typically) - and I could easily see how this breeds resentment... >>> >>> Perhaps it would be simple enough to add a check to repoman for commit >>> messages less than 10 characters, and with at least one *additional* >>> space, mandating two words in the commit message. It seems draconian, >>> but if developers continue to be lazy, what choice does one have?! >>> >>> >> I don't see a problem with 'version bump' as a description. Sometimes you >> bump an ebuild because upstream released a new version and you want to >> track. I'm fairly against changes describing what was changed (typically >> the reader can git show and observe the changes.) The useful information is >> *why* the change was made. Sometimes its because "upstream released a new >> version." >> >> Like Matt I'm curious what others expect to see in the description. >> > That's exactly why I release much of the stuff I do, I get a task in > todoist via ifttt monitoring a github atom feed that a new release is > out and I package it. > If you have automated tooling, surely it's not impossible to make that tooling generate a semi-meaningful commit message on-the-fly too ... just sayin' ...
signature.asc
Description: OpenPGP digital signature
