On Sun, 23 Sep 2018 17:45:27 -0500 Matthew Thode <prometheanf...@gentoo.org> wrote:
> On 18-09-24 09:27:57, 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. > > > > What would you rather see for when a package is bumped (that is, simply > copying the ebuild and editing the keywords)? > I personally try to use something of the form: "Bump version to 12.234.1567" Mostly, because it gives some vaguely useful context when reading a commit summary log, that doesn't necessitate you running "git log -p" or "git diff" to find out what actually changed. This lends itself to good user-feedback mechanisms when the log is relayed via IRC on #gentoo-commits, and allows one to determine what's going on at-a-glance via gitweb. If the version bump is in response to a bug request, I'll try to mention that in the subject too. If I made changes in the ebuild in the bump itself, I'll attempt to describe the nature of those changes (from the perspective of the consumer)' And where possible, I attempt to summarize the nature of the changes between our largest in-tree version and the new version, as far as upstream changes are concerned. Eg: if version went from 1.0 to 1.3, but 1.1-1.2 existed, I'll attempt a summary for the imagined user upgrading from 1.0 to 1.3. If for instance something is added in 1.1 and then redacted in 1.2, there's no need to mention that in 1.0 -> 1.3. I Try to think of it as "a list of reasons why a user might want to upgrade, or might want to avoid upgrading" from a context of "xxx changed, if you were using this your code might break" or "xxx is new, if you need this, you need to upgrade" All of this is "nice to have" stuff I'd try to gently nudge others into the direction of, in effort to provide useful information to not only our users, but to other developers, and our future selves looking back in the history trying to ascertain the importance of a given version. Achieving all of the above is of course not always possible, sometimes there are too many changes to summarize, or upstream is made of too much insane for you to assess the differences, that's life. But you can imagine how I get *just* a little bit frustrated when this is the sort of direction I'm trying to aspire towards, but what I'm seeing on the list is debates about "bup" vs "bump" :)
pgp3Tp9pj89v0.pgp
Description: OpenPGP digital signature
