Re: [gentoo-dev] Re: What means bup?
On Mon, 24 Sep 2018 10:59:40 -0400 Alec Warner wrote: > > So e.g.: > > "Bump to x.y.z for bug 12345"? > > Is there an annotation for "this commit is relevant to bug X, but does not > close bug X?" > > I'm less sure we need the metadata all in the summary (because its supposed > to be a summary.) > If the commits are annotated (Closes: bugX, BugRef: bugX...) we can amend > the tools to look at the annotatoins and not hand parse the summary. > It also helps for linkification. Well, yes, there's a limit to the summary length anyway that repoman enforces ;) But the point being to *maximise* the use of this "summary" message, and make good use of the "body" section of the "commit message". And there's already annotations for this in the body section, Bug: https://bugs.gentoo.org/123456 ( This references but does not close ) Closes: https://bugs.gentoo.org/123456 ( This closes ) In the summary line, you don't really need to clarify if it closes or not. Much of the benefit is knowing wilikins will see that message in #gentoo-commits, and then cite the entire bug summary in response. ( Including its current status of closed/open ) > > > > > 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)' > > > > You don't do that in the shortlog though..right? There is very little room. See above. > > Just for clarity, this all sounds like "changelog" stuff; are we still > generating changelogs from git commit descriptions? If so, this all seems > on the up and up to me. Generated changelogs are something that we were supposed to have, but they got culled from rsync tree for a host of reasons. ( One being they weren't generated in reverse-chronological order, which made them a boon to read ) But I still find having it documented useful even without this feature ( In the long term, we may find our users collectively start to prefer git to rsync, and having good change notes makes that even better for them ) pgpNfaBcL7KT5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On Sun, Sep 23, 2018 at 10:27 PM Kent Fredric wrote: > On Sun, 23 Sep 2018 17:45:27 -0500 > Matthew Thode wrote: > > > On 18-09-24 09:27:57, Kent Fredric wrote: > > > On Sat, 22 Sep 2018 15:36:23 -0500 > > > Matthew Thode 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. > So e.g.: "Bump to x.y.z for bug 12345"? Is there an annotation for "this commit is relevant to bug X, but does not close bug X?" I'm less sure we need the metadata all in the summary (because its supposed to be a summary.) If the commits are annotated (Closes: bugX, BugRef: bugX...) we can amend the tools to look at the annotatoins and not hand parse the summary. It also helps for linkification. > > 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)' > You don't do that in the shortlog though..right? There is very little room. > > 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. > Just for clarity, this all sounds like "changelog" stuff; are we still generating changelogs from git commit descriptions? If so, this all seems on the up and up to me. > > 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" :) > >
Re: [gentoo-dev] Re: What means bup?
Ühel kenal päeval, P, 23.09.2018 kell 21:39, kirjutas Alec Warner: > 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. I expect to see the version number being bumped to. At least something like "cat/pkg: bump to 1.2.3" This help tremendously for git shortlog, and just "bump" is something you do all the time, so not a good summary. But bump to a specific version is a good summary, as it says it exactly enough and in summary. However Matthew does that already, in the form of "cat/pkg: 1.2.3 bump". I don't agree with "bup", but it indeed mostly has been "bump" now, and my only problem there is that I'm not used to that order (vs "bump to 1.2.3"). Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: What means bup?
On Sun, Sep 23, 2018, at 21:26 CDT, Kent Fredric wrote: > 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. ++ > [...] > 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. ++ > [...] > 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" :) ++ There is nothing more to add. Best, Matthias
Re: [gentoo-dev] Re: What means bup?
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 wrote: >> >>> On 23/09/18 22:27, Kent Fredric wrote: On Sat, 22 Sep 2018 15:36:23 -0500 Matthew Thode 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
Re: [gentoo-dev] Re: What means bup?
On Sun, 23 Sep 2018 17:45:27 -0500 Matthew Thode wrote: > On 18-09-24 09:27:57, Kent Fredric wrote: > > On Sat, 22 Sep 2018 15:36:23 -0500 > > Matthew Thode 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
Re: [gentoo-dev] Re: What means bup?
On 18-09-23 21:39:01, Alec Warner wrote: > On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt wrote: > > > On 23/09/18 22:27, Kent Fredric wrote: > > > On Sat, 22 Sep 2018 15:36:23 -0500 > > > Matthew Thode 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. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt wrote: > On 23/09/18 22:27, Kent Fredric wrote: > > On Sat, 22 Sep 2018 15:36:23 -0500 > > Matthew Thode 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. -A
Re: [gentoo-dev] Re: What means bup?
On 23/09/18 22:27, Kent Fredric wrote: > On Sat, 22 Sep 2018 15:36:23 -0500 > Matthew Thode 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?! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-24 09:27:57, Kent Fredric wrote: > On Sat, 22 Sep 2018 15:36:23 -0500 > Matthew Thode 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)? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Sat, 22 Sep 2018 15:36:23 -0500 Matthew Thode 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. pgpg0CvstIsLc.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-22 16:16:28, Jonas Stein wrote: > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > There are again new commits with "bup". > Please do not misuse the commit message for jokes and word games. > 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 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
>> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. > *boop* There are again new commits with "bup". Please do not misuse the commit message for jokes and word games. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
Am Freitag, 20. Juli 2018, 02:55:51 CEST schrieb Mikle Kolyada: > > I think more recently I've been following this format. > > > > cat/pkg: x.y.z bup > > But can you please *stop* doing this as well? It is neither clear > language *nor* useful reduction. ++ Please stop it. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
Re: [gentoo-dev] Re: What means bup?
On Wed, 2018-07-18 at 11:12 -0400, Matt Turner wrote: > On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode > wrote: > > On 18-07-18 09:16:07, Johannes Huber wrote: > > > Hi all, > > > > > > english is not my mother language, so please clarify what bup > > > means, just > > > seen here: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478c > > > f30b3ced0405f6b89391e05d2397 > > > > > > Just checked if it was a typo, but can't be: > > > git log --oneline --grep bup | count -l > > > Expected 0 lines, got 1248. > > > > > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > > I just prefer bup instead. I generally only use it when doing > > simple > > bumps of packages (copy ebuilds with only keyword edits). > > Cute. > > Since 94.5% of the 1248 instances were from you... can you please > stop? > +1
Re: [gentoo-dev] Re: What means bup?
On 18.07.2018 19:57, Matthew Thode wrote: > On 18-07-18 11:28:16, Mike Gilbert wrote: >> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode >> wrote: >>> On 18-07-18 09:16:07, Johannes Huber wrote: Hi all, english is not my mother language, so please clarify what bup means, just seen here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 Just checked if it was a typo, but can't be: git log --oneline --grep bup | count -l Expected 0 lines, got 1248. >>> It's similiar to a sound you make when you touch something's nose. >>> *boop* >>> >>> I just prefer bup instead. I generally only use it when doing simple >>> bumps of packages (copy ebuilds with only keyword edits). >> My preference is to mention the version being added when committing a >> version bump. eg. "cat/pkg: bump to x.y.z". >> >> Yes, it does take a few more seconds, but I think it is worth the effort. >> > I think more recently I've been following this format. > > cat/pkg: x.y.z bup > But can you please *stop* doing this as well? It is neither clear language *nor* useful reduction. signature.asc Description: OpenPGP digital signature
Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 13:47:03 +0100 "M. J. Everitt" wrote: > - Line one is limited to / and some Key Word that defines > the type of change made, similar to bugzilla perhaps eg. "REVBUMP, > VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get > around the issue of long package-names and/or overlays and other > lengthy prefixes. Hell no. I want to see as *much* data as possible in the limited summary, not the *LEAST*. That's why we have this problem in the first place: Developers are trying *HARD* to put sufficiently quality information. This proposal as-is basically champions the line length limitation to absurdity. If you go down this road you may as well "Fix" the problem by forcing everyone to make the commit summary the shortened SHA1 of the rest of the text in the commit message at least that way you're *GUARANTEED* to never exceed 50 odd characters. The commit summary will be useless, but hey, we got that message length down alright. Yay! pgpd2migo1z58.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
Am 18.07.2018 um 09:26 schrieb Matthew Thode: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). > Hi Matthew, thank you for the explanation. As the ChangeLogs are expanded for rsync or can be inspected via git I would expect from a user standpoint to read proper entries. Thanks in advance, Johannes signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 18-07-18 11:28:16, Mike Gilbert wrote: > On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode > wrote: > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> Hi all, > >> > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > >> > > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > > I just prefer bup instead. I generally only use it when doing simple > > bumps of packages (copy ebuilds with only keyword edits). > > My preference is to mention the version being added when committing a > version bump. eg. "cat/pkg: bump to x.y.z". > > Yes, it does take a few more seconds, but I think it is worth the effort. > I think more recently I've been following this format. cat/pkg: x.y.z bup -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). My preference is to mention the version being added when committing a version bump. eg. "cat/pkg: bump to x.y.z". Yes, it does take a few more seconds, but I think it is worth the effort.
Re: [gentoo-dev] Re: What means bup?
On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). Cute. Since 94.5% of the 1248 instances were from you... can you please stop?
Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
M. J. Everitt wrote: > I'm thinking something along the lines of the following: > - Line one is limited to / and some Key Word that defines the > type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, > EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the > issue of long package-names and/or overlays and other lengthy prefixes. This would remove one of two information atoms in commit messages, reducing human expression in commit messages to mere 50%, or to 0% for --oneline output. I think that's unacceptably poor usability. > This should satisfy line length limitations, My counter-proposal is to bup the repoman line length limitation. //Peter
Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 14:20:56 +0200 Kristian Fiskerstrand wrote: > On 07/18/2018 02:10 PM, Alexis Ballier wrote: > > I often find myself in the > > need to use/invent some abbreviation in order to fit the limit. > > Considering this is an error, this sends the message that short is > > preferred over clear. > > Or that the summary should be concise and a longer proper description > can be written in the body of the commit message instead. Potentially > mixed in with multiple commits for different logical changes etc etc. > Sure, but that somewhat defeats the point of a summary if it's not possible to clearly express what it is about without relying on the long description.
[RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
On 18/07/18 13:20, Kristian Fiskerstrand wrote: > On 07/18/2018 02:10 PM, Alexis Ballier wrote: >> I often find myself in the >> need to use/invent some abbreviation in order to fit the limit. >> Considering this is an error, this sends the message that short is >> preferred over clear. > Or that the summary should be concise and a longer proper description > can be written in the body of the commit message instead. Potentially > mixed in with multiple commits for different logical changes etc etc. > Perhaps the time has come to re-assess the commit message "standard". I'm thinking something along the lines of the following: - Line one is limited to / and some Key Word that defines the type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the issue of long package-names and/or overlays and other lengthy prefixes. - Line two remains a blank line at present - Line three+ actually describe what the change is, in plain English. - Footer~3: Bug/Pull reference - Footer~2: Signed/Authored/etc standard footer text(s) - Footer: Package manager/repoman as appropriate where: 3+ (line three onwards), ~n: approx. line prior to end (EOF-n) This should satisfy line length limitations, whilst still preserving some Basic information about commit type, which can then be sub-filtered if necessary. I can't presently see anything that would preclude tool-friendly parsing of such messages... or repoman applying appropriate checks... NB. I may have swapped F~3 and F~2 lines around .. order can be preserved as present. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 07/18/2018 02:10 PM, Alexis Ballier wrote: > I often find myself in the > need to use/invent some abbreviation in order to fit the limit. > Considering this is an error, this sends the message that short is > preferred over clear. Or that the summary should be concise and a longer proper description can be written in the body of the commit message instead. Potentially mixed in with multiple commits for different logical changes etc etc. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 10:35:41 +0200 Ulrich Mueller wrote: > > On Wed, 18 Jul 2018, Matthew Thode wrote: > > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> english is not my mother language, so please clarify what bup > >> means, just seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > I just prefer bup instead. I generally only use it when doing > > simple bumps of packages (copy ebuilds with only keyword edits). > > We used to have the rule that ChangeLog messages "should be well > explained and written in clean English". I think this applies to > commit messages, too. While it does not really apply in this precise case, this rule's weight has been lowered a lot with repoman enforcing 'cat/pkg: ...' + hard limit on the commit message length. I often find myself in the need to use/invent some abbreviation in order to fit the limit. Considering this is an error, this sends the message that short is preferred over clear.
[gentoo-dev] Re: What means bup?
> On Wed, 18 Jul 2018, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. > *boop* > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). We used to have the rule that ChangeLog messages "should be well explained and written in clean English". I think this applies to commit messages, too. Ulrich pgpJC7WRzPn3h.pgp Description: PGP signature
[gentoo-dev] Re: What means bup?
On 18-07-18 09:16:07, Johannes Huber wrote: > Hi all, > > english is not my mother language, so please clarify what bup means, just > seen here: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > > Just checked if it was a typo, but can't be: > git log --oneline --grep bup | count -l > Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. *boop* I just prefer bup instead. I generally only use it when doing simple bumps of packages (copy ebuilds with only keyword edits). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
