From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A85F8138334 for ; Mon, 24 Sep 2018 01:39:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E4CEE08EC; Mon, 24 Sep 2018 01:39:15 +0000 (UTC) Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 21997E08DC for ; Mon, 24 Sep 2018 01:39:14 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id l5so14921338edw.9 for ; Sun, 23 Sep 2018 18:39:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ksCSEHyxpxO2XR0EuQ2qWR0+C0w6hdM8ReKu/gx8jKA=; b=NKZ+KbE30tp/1WCba6RbCCUYvJqKfAaue/YMREYGN3P/EcjIYG3sUDQIAvMfgTIUdv bpRZqcOXZxwdQqHU9isqZMXSEhcLQVE7XIJbiF4s05GgEL0C/lmSBUz+4vJaQU91Sn98 wVA1qtIht2nv6xjV7iMWi9KtaN3m7VnCOfM8UasYMtA2EkccQWkklsoDeBSU8RWya8k9 PVFggOaEJYACaoc9vDqVfTReB7U/JGjJjQKSQ5n9QENaA4sTPvFITXT9R/2nprBVSf/B mdZ6BIjGd8qyqdEUB/dSdgdRqUDRa+4yDDDO008Zv9LpQMO4/ukRNxBrmeuAwypSlyV4 eTBw== X-Gm-Message-State: ABuFfogWmMfu9tuy0nuF7Px5kF34efxnPeXsndRcvjgCEBLm94fQxWGg 2Z0EzwIYZHmXM4SAxrH6H4jfhK7e+w3crddOkZu29w2+ X-Google-Smtp-Source: ACcGV63j/Zr9I2Dgk8egkjADCDK2FTlcTpFj2waDZXMveBZlcIT9M+p2FmfnP/0nipo0kYx16mktbWifSryHUd+imGU= X-Received: by 2002:a50:afc4:: with SMTP id h62-v6mr13930114edd.251.1537753153084; Sun, 23 Sep 2018 18:39:13 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <2118089b-4d6d-0a89-ce78-8d5597fb0141@gentoo.org> <20180718072657.fnz45gc44v3m4n6v@gentoo.org> <20180922203623.5ls6dcc73rifhuo5@gentoo.org> <20180924092757.5c714f9d@katipo2.lan> In-Reply-To: From: Alec Warner Date: Sun, 23 Sep 2018 21:39:01 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: What means bup? To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000712f250576940eeb" X-Archives-Salt: a4608851-2f09-4552-9598-b43479e2da42 X-Archives-Hash: d212c4249efc4036ae1fc2467207a00a --000000000000712f250576940eeb Content-Type: text/plain; charset="UTF-8" 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 --000000000000712f250576940eeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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.=C2=A0 What ever happened to assuming the best :(= =C2=A0 Are you
>> going to ping the list every time my hand slips up and I mistype >> something?=C2=A0 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, j= ust 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 ev= ery
> time somebody doesn't invest any more effort than to write the wor= d
> "bump" in their text editor when committing with repoman, co= s 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 th= e
> 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 w= e
> didn't define accidents and siblings of accidents as the status qu= o.
>
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 've= rsion bump' as a description. Sometimes you bump an ebuild because upst= ream released a new version and you want to track. I'm fairly against c= hanges describing what was changed (typically the reader can git show and o= bserve the changes.) The useful information is *why* the change was made. S= ometimes its because "upstream released a new version."

Like Matt I'm curious what others expect to see in the = description.

-A
=C2=A0
--000000000000712f250576940eeb--