[gentoo-dev] What means bup?

[gentoo-dev] What means bup?

[Johannes Huber]

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.

Best regards,
Johannes

[gentoo-dev] Re: What means bup?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] What means bup?

[Philip Webb]

180718 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

Surely, it's a typo for 'bump'.

As a native speaker, I've never seen it & Dictionary.com doesn't know it.
The OED is the ultimate authority on such matters,
but I don't have free access : perhaps someone else does.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

[gentoo-dev] Re: What means bup?

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Alexis Ballier]

On Wed, 18 Jul 2018 10:35:41 +0200
Ulrich Mueller <ulm@gentoo.org> 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.

Re: [gentoo-dev] Re: What means bup?

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 602 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1651 bytes --]

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 <cat>/<pkg> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Alexis Ballier]

On Wed, 18 Jul 2018 14:20:56 +0200
Kristian Fiskerstrand <k_f@gentoo.org> 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.

Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

[Peter Stuge]

M. J. Everitt wrote:
> I'm thinking something along the lines of the following:
> - Line one is limited to <cat>/<pkg> 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?

[Matt Turner]

On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
<prometheanfire@gentoo.org> 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: [gentoo-dev] Re: What means bup?

[Mike Gilbert]

On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
<prometheanfire@gentoo.org> 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?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On 18-07-18 11:28:16, Mike Gilbert wrote:
> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
> <prometheanfire@gentoo.org> 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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Johannes Huber]

[-- Attachment #1.1: Type: text/plain, Size: 884 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Wed, 18 Jul 2018 13:47:03 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> - Line one is limited to <cat>/<pkg> 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!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Mikle Kolyada]

[-- Attachment #1.1.1: Type: text/plain, Size: 1223 bytes --]



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
>> <prometheanfire@gentoo.org> 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.


[-- Attachment #1.1.2: Type: text/html, Size: 2320 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: What means bup?

[David Seifert]

On Wed, 2018-07-18 at 11:12 -0400, Matt Turner wrote:
> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
> <prometheanfire@gentoo.org> 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?

[Andreas K. Huettel]

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
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Re: What means bup?

[Jonas Stein]

[-- Attachment #1.1: Type: text/plain, Size: 535 bytes --]

>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 636 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Sat, 22 Sep 2018 15:36:23 -0500
Matthew Thode <prometheanfire@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.

 







[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On 18-09-24 09:27:57, Kent Fredric wrote:
> On Sat, 22 Sep 2018 15:36:23 -0500
> Matthew Thode <prometheanfire@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)?

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2063 bytes --]

On 23/09/18 22:27, Kent Fredric wrote:
> On Sat, 22 Sep 2018 15:36:23 -0500
> Matthew Thode <prometheanfire@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?!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]

On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt <m.j.everitt@iee.org> wrote:

> On 23/09/18 22:27, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode <prometheanfire@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.

-A

[-- Attachment #2: Type: text/html, Size: 3324 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]

On Sun, 23 Sep 2018 17:45:27 -0500
Matthew Thode <prometheanfire@gentoo.org> wrote:

> On 18-09-24 09:27:57, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode <prometheanfire@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" :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]

On 18-09-23 21:39:01, Alec Warner wrote:
> On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt <m.j.everitt@iee.org> wrote:
> 
> > On 23/09/18 22:27, Kent Fredric wrote:
> > > On Sat, 22 Sep 2018 15:36:23 -0500
> > > Matthew Thode <prometheanfire@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.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: What means bup?

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3180 bytes --]

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.everitt@iee.org> wrote:
>>
>>> On 23/09/18 22:27, Kent Fredric wrote:
>>>> On Sat, 22 Sep 2018 15:36:23 -0500
>>>> Matthew Thode <prometheanfire@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' ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Matthias Maier]

On Sun, Sep 23, 2018, at 21:26 CDT, Kent Fredric <kentnl@gentoo.org> 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?

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Ü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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]

On Sun, Sep 23, 2018 at 10:27 PM Kent Fredric <kentnl@gentoo.org> wrote:

> On Sun, 23 Sep 2018 17:45:27 -0500
> Matthew Thode <prometheanfire@gentoo.org> wrote:
>
> > On 18-09-24 09:27:57, Kent Fredric wrote:
> > > On Sat, 22 Sep 2018 15:36:23 -0500
> > > Matthew Thode <prometheanfire@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.
>

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" :)
>
>

[-- Attachment #2: Type: text/html, Size: 6357 bytes --]

Re: [gentoo-dev] Re: What means bup?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

On Mon, 24 Sep 2018 10:59:40 -0400
Alec Warner <antarus@gentoo.org> 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 )



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]