Re: [HACKERS] Template for commit messages

2016-02-01 Thread Alvaro Herrera
Joshua D. Drake wrote:
> On 01/31/2016 04:34 PM, Michael Paquier wrote:

> >This page would need a refresh IMO. I think it has not been touched
> >for the last couple of years.
> 
> No doubt but if we can't bother to keep that refreshed what makes us think
> that a structured format in commit messages that magically (through a lot of
> hard work and extra parsing anyway) is going to be any more accurate?

If you're proposing to keep that page updated, please propose that in
pgsql-www instead of hijacking this thread.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Andres Freund
On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote:
> Let's just assume that we can fix that part. As in, we can expose either an
> internal db id or a short hash or something, from the archives server. We
> could then have that visible/linkable directly on the archives page, and
> one could copy/paste that link into the commit message. That way we can
> avoid the long messageids.

Raw messageids have the big big advantage that you can get them locally
in your mailreader, and you can dereference them locally... I type
esc-X id:$id and 20ms later I have the whole thread open.  Maybe
I just travel too much, but travel time is often long and uninterrupted
and thus pretty nice to work on patches.

I don't really see the problem, even with gmail style messageids
Discussion: cabuevez_uja0ddrw7apjh3nm4p0kghwopm0wpw4mh_gt2-n...@mail.gmail.com
isn't that bad.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Alvaro Herrera
Andres Freund wrote:
> On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote:
> > Let's just assume that we can fix that part. As in, we can expose either an
> > internal db id or a short hash or something, from the archives server. We
> > could then have that visible/linkable directly on the archives page, and
> > one could copy/paste that link into the commit message. That way we can
> > avoid the long messageids.
> 
> Raw messageids have the big big advantage that you can get them locally
> in your mailreader, and you can dereference them locally... I type
> esc-X id:$id and 20ms later I have the whole thread open.

Yes, +1 on that.

> Maybe I just travel too much, but travel time is often long and
> uninterrupted and thus pretty nice to work on patches.

I don't travel as much as you or Magnus do (!) but I do offline work a
lot, so I appreciate full message-ids.

> I don't really see the problem, even with gmail style messageids
> Discussion: cabuevez_uja0ddrw7apjh3nm4p0kghwopm0wpw4mh_gt2-n...@mail.gmail.com
> isn't that bad.

Yes, yes, I prefer to use the full URL because then a machine can tell
whether it's an email address and not a message-id, which is useful for
mangling addresses while at the same time not mangling message-ids.  But
I'm not going to force that on anybody.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Magnus Hagander
On Mon, Feb 1, 2016 at 12:53 PM, Michael Paquier 
wrote:

> On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund  wrote:
> > I personally, and I realize that I'm likely alone on that, would really
> > like to see references to relevant threads. A year after a commit or
> > such it often starts to get hard to know which threads a commit was
> > about.  Often it's easy enough if it's about a single feature, but
> > bugfixes often originate in threads that have no directly corresponding
> > thread. And often the commit happens a while after there's been activity
> > in a thread.  I spent days searching what thread "per discussion" in
> > commit messages refers to.
>
> +1. Having to look at the archives to find to which discussion a
> commit is attached is a pain. Last time this was suggested though
> there were concerns regarding the 72-80 character limit per line in a
> commit message.
>

Let's just assume that we can fix that part. As in, we can expose either an
internal db id or a short hash or something, from the archives server. We
could then have that visible/linkable directly on the archives page, and
one could copy/paste that link into the commit message. That way we can
avoid the long messageids.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Heikki Linnakangas

On 01/02/16 13:36, Andres Freund wrote:

On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote:

Reported-by:
Bug:
Author:
Reviewed-by:
Tested-by:
Backpatch-through:


I personally, and I realize that I'm likely alone on that, would really
like to see references to relevant threads. A year after a commit or
such it often starts to get hard to know which threads a commit was
about.  Often it's easy enough if it's about a single feature, but
bugfixes often originate in threads that have no directly corresponding
thread. And often the commit happens a while after there's been activity
in a thread.  I spent days searching what thread "per discussion" in
commit messages refers to.


+1. I also quite often look at a commit message, and then hunt the "per 
discussion". A message-id would save some time there. I've seen you add 
annotations like that to your commits, which is nice. I'll start doing 
that myself. You've used the "Discussion: " format for that, 
so I'll go with that too. (Even if the message-id is given in free-form 
in the paragraphs, that's helpful, but might as well use a fixed form.)


And that's a proposal that's not "we must all do it or it's useless". If 
half of commit messages include that, then hunting the "per discussion" 
for those commits becomes easier, and the rest are the same as now.


- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Andres Freund
On 2016-02-01 20:53:56 +0900, Michael Paquier wrote:
> Last time this was suggested though there were concerns regarding the
> 72-80 character limit per line in a commit message.

That seems like a misdirect. The limit is there to keep things readable,
not because there's a hard technical limit. So if a messageid is longer,
it doesn't have much consequence.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Michael Paquier
On Mon, Feb 1, 2016 at 6:13 PM, Alvaro Herrera 
wrote:

> Joshua D. Drake wrote:
> > On 01/31/2016 04:34 PM, Michael Paquier wrote:
>
> > >This page would need a refresh IMO. I think it has not been touched
> > >for the last couple of years.
> >
> > No doubt but if we can't bother to keep that refreshed what makes us
> think
> > that a structured format in commit messages that magically (through a
> lot of
> > hard work and extra parsing anyway) is going to be any more accurate?
>
> If you're proposing to keep that page updated, please propose that in
> pgsql-www instead of hijacking this thread.
>

Oops. Sorry about that.
-- 
Michael


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Andres Freund
On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote:
>   Reported-by:
>   Bug:
>   Author:
>   Reviewed-by:
>   Tested-by:
>   Backpatch-through:

I personally, and I realize that I'm likely alone on that, would really
like to see references to relevant threads. A year after a commit or
such it often starts to get hard to know which threads a commit was
about.  Often it's easy enough if it's about a single feature, but
bugfixes often originate in threads that have no directly corresponding
thread. And often the commit happens a while after there's been activity
in a thread.  I spent days searching what thread "per discussion" in
commit messages refers to.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Michael Paquier
On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund  wrote:
> I personally, and I realize that I'm likely alone on that, would really
> like to see references to relevant threads. A year after a commit or
> such it often starts to get hard to know which threads a commit was
> about.  Often it's easy enough if it's about a single feature, but
> bugfixes often originate in threads that have no directly corresponding
> thread. And often the commit happens a while after there's been activity
> in a thread.  I spent days searching what thread "per discussion" in
> commit messages refers to.

+1. Having to look at the archives to find to which discussion a
commit is attached is a pain. Last time this was suggested though
there were concerns regarding the 72-80 character limit per line in a
commit message.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Magnus Hagander
On Mon, Feb 1, 2016 at 1:04 PM, Andres Freund  wrote:

> On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote:
> > Let's just assume that we can fix that part. As in, we can expose either
> an
> > internal db id or a short hash or something, from the archives server. We
> > could then have that visible/linkable directly on the archives page, and
> > one could copy/paste that link into the commit message. That way we can
> > avoid the long messageids.
>
> Raw messageids have the big big advantage that you can get them locally
> in your mailreader, and you can dereference them locally... I type
> esc-X id:$id and 20ms later I have the whole thread open.  Maybe
> I just travel too much, but travel time is often long and uninterrupted
> and thus pretty nice to work on patches.
>

If it was a short hash of the same thing, you could equally find them
locally though, couldn't you?



> I don't really see the problem, even with gmail style messageids
> Discussion:
> cabuevez_uja0ddrw7apjh3nm4p0kghwopm0wpw4mh_gt2-n...@mail.gmail.com
> isn't that bad.
>

If people don't actually have a problem with it, that of course makes it
even easier :)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Noah Misch
On Mon, Feb 01, 2016 at 01:55:23PM +0200, Heikki Linnakangas wrote:
> On 01/02/16 13:36, Andres Freund wrote:
> >On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote:
> >>Reported-by:
> >>Bug:
> >>Author:
> >>Reviewed-by:
> >>Tested-by:
> >>Backpatch-through:
> >
> >I personally, and I realize that I'm likely alone on that, would really
> >like to see references to relevant threads. A year after a commit or
> >such it often starts to get hard to know which threads a commit was
> >about.  Often it's easy enough if it's about a single feature, but
> >bugfixes often originate in threads that have no directly corresponding
> >thread. And often the commit happens a while after there's been activity
> >in a thread.  I spent days searching what thread "per discussion" in
> >commit messages refers to.
> 
> +1. I also quite often look at a commit message, and then hunt the "per
> discussion". A message-id would save some time there.

+1


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-02-01 Thread Greg Sabino Mullane

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


FWIW, I read the git logs quite a bit, especially after a release to 
gather some stats, and I *love* the commits that have some nice 
standard, easy to read fields (Alvaro for one does a great job 
at this). I don't think we need to mandate it, or even ensure they 
are machine-parseable, but I would like to see a few fields encouraged. 
I think it also helps the committers to not forget some important 
things, the way the free-form text can.

tl;dr be like Alvaro, please

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201602011037
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlavfNwACgkQvJuQZxSWSsg4YgCgmWoL38qljypgUn082aWVp4y8
WDsAn24IwFKwqaudYRF1e3rvd0yz5btw
=2Jc2
-END PGP SIGNATURE-




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-31 Thread Alvaro Herrera
Joshua D. Drake wrote:
> On 01/29/2016 03:05 PM, Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >
> >>I think the best question to ask is:
> >>
> >>"What is the problem we are trying to solve?"
> >
> >The problem is alluring more patch reviewers, beta testers and bug
> >reporters.
> 
> Do we really want patch reviewers, beta testers and bug reporters that are
> doing it because we created a fixed template for commit messages that may
> mention their name?

We want *some* patch reviewers and beta testers.  We don't really care
what's their motivation, as long as their do their thing.  The
motivating factor is supposed to be getting credit -- not in the commit
messages (because other people don't look at those) but having their
names appear in the release notes.

> >One of the offers is to credit them (I'm not exactly clear
> >on what is the group to benefit from this, but the phrasing used in the
> >meeting was "contributors to the release") by having a section somewhere
> >in the release notes with a list of their names.
> 
> I can see this as being a nice thing but knowing that someone is a
> contributor isn't hard. There is a contributor list on the website and it is
> obvious from mail lists, archives and simple searches who is actually
> participating.

It's not obvious, which is why this is being discussed at all, and the
contributor list in the website is useless for the purposes at hand.
And it is hard, which is why the issue was raised in the first place --
heck, when this was mentioned, somebody said "but we would have to wait
until 9.7 because we don't have that information in existing commit
messages in 9.6 already" (he was promptly made to shut up, because most
if not all committers are already crediting reviewers in their commit
messages and we don't want to wait *two years* to implement this idea.)

> >So the problem, of course, is collating that list of names, and the
> >point of having a commit template is to have a single, complete source
> >of truth from where to extract the info.
> 
> I think the problem is that we think that this is somehow going to allure
> more people.

How come the issue of crediting people comes up so often, if it is, as
you seem to be saying, so worthless?

> I also think it is a quick step from:
> 
> Oh, Alvaro helped a lot with that.
> 
> vs
> 
> On, 2Q wrote that feature.

I'm not sure what's your point here, but the release notes are going to
list individuals, not companies.  (FWIW if it were up to me committers
and major contributors would not be in the list anyway.)

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-31 Thread Joshua D. Drake

On 01/29/2016 03:05 PM, Alvaro Herrera wrote:

Joshua D. Drake wrote:


I think the best question to ask is:

"What is the problem we are trying to solve?"


The problem is alluring more patch reviewers, beta testers and bug
reporters.


Do we really want patch reviewers, beta testers and bug reporters that 
are doing it because we created a fixed template for commit messages 
that may mention their name?



One of the offers is to credit them (I'm not exactly clear
on what is the group to benefit from this, but the phrasing used in the
meeting was "contributors to the release") by having a section somewhere
in the release notes with a list of their names.


I can see this as being a nice thing but knowing that someone is a 
contributor isn't hard. There is a contributor list on the website and 
it is obvious from mail lists, archives and simple searches who is 
actually participating.



This proposal is
different from the previous proposal because their names wouldn't appear
next to each feature.


That certainly is a good thing.



So the problem, of course, is collating that list of names, and the
point of having a commit template is to have a single, complete source
of truth from where to extract the info.



I think the problem is that we think that this is somehow going to 
allure more people. I also think it is a quick step from:


Oh, Alvaro helped a lot with that.

vs

On, 2Q wrote that feature.

Any smart business is going to push for that once we start down this 
path in earnest.


Sincerely,

Joshua D. Drake


--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-31 Thread Joshua D. Drake

On 01/31/2016 04:34 PM, Michael Paquier wrote:

On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote:

On 01/29/2016 03:05 PM, Alvaro Herrera wrote:

Joshua D. Drake wrote:
One of the offers is to credit them (I'm not exactly clear
on what is the group to benefit from this, but the phrasing used in the
meeting was "contributors to the release") by having a section somewhere
in the release notes with a list of their names.



I can see this as being a nice thing but knowing that someone is a
contributor isn't hard. There is a contributor list on the website and it is
obvious from mail lists, archives and simple searches who is actually
participating.


This page would need a refresh IMO. I think it has not been touched
for the last couple of years.


No doubt but if we can't bother to keep that refreshed what makes us 
think that a structured format in commit messages that magically 
(through a lot of hard work and extra parsing anyway) is going to be any 
more accurate?


Sincerely,

JD






--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-31 Thread Sachin Kotwal
Sorry for little late.

Can we add Severity level of patch? with only three levels as (High,
Moderate, Low)

Many of our customers might not understand overall important of patch.
If we add this people/customers can choose patch is important for them or
not.
Other than Author and hackers can not easily understand overall importance
of patch.

Please consider if you feel it is important to add this parameter in commit
message format.







On Mon, Feb 1, 2016 at 10:04 AM, Joshua D. Drake 
wrote:

> On 01/31/2016 04:34 PM, Michael Paquier wrote:
>
>> On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote:
>>
>>> On 01/29/2016 03:05 PM, Alvaro Herrera wrote:
>>>
 Joshua D. Drake wrote:
 One of the offers is to credit them (I'm not exactly clear
 on what is the group to benefit from this, but the phrasing used in the
 meeting was "contributors to the release") by having a section somewhere
 in the release notes with a list of their names.

>>>
>>>
>>> I can see this as being a nice thing but knowing that someone is a
>>> contributor isn't hard. There is a contributor list on the website and
>>> it is
>>> obvious from mail lists, archives and simple searches who is actually
>>> participating.
>>>
>>
>> This page would need a refresh IMO. I think it has not been touched
>> for the last couple of years.
>>
>
> No doubt but if we can't bother to keep that refreshed what makes us think
> that a structured format in commit messages that magically (through a lot
> of hard work and extra parsing anyway) is going to be any more accurate?
>
> Sincerely,
>
> JD
>
>
>>
>
> --
> Command Prompt, Inc.  http://the.postgres.company/
> +1-503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 

Thanks and Regards,
Sachin Kotwal


Re: [HACKERS] Template for commit messages

2016-01-31 Thread Michael Paquier
On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote:
> On 01/29/2016 03:05 PM, Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>> One of the offers is to credit them (I'm not exactly clear
>> on what is the group to benefit from this, but the phrasing used in the
>> meeting was "contributors to the release") by having a section somewhere
>> in the release notes with a list of their names.
>
>
> I can see this as being a nice thing but knowing that someone is a
> contributor isn't hard. There is a contributor list on the website and it is
> obvious from mail lists, archives and simple searches who is actually
> participating.

This page would need a refresh IMO. I think it has not been touched
for the last couple of years.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-30 Thread Christopher Browne
On 30 January 2016 at 05:11, Robert Haas  wrote:
>
> Well, this gets at one of the problems here, which is that you can't
> fix a commit message once the commit has been pushed.  So even if we
> all agreed in principle to a standard format, it's not clear that you
> could enforce compliance with that format to a degree sufficient to
> make machine-parseability a reality.

Yep, there's the rub in it.

Commit messages are authoritative for the things that ARE found in
commit messages.

If making them authoritative for a whole bunch of things means it is
necessary to force everyone to run some piece of commit-message-
monitoring code against their own repo, and any failure to run the
message monitoring code causes the project to fail to have
authoritative information, then it should be clear that we've
constructed something a wee bit too fragile.

A thing plausible instead is to collect the authoritative-at-commit-time
message information into an external system (hey, I wonder if anyone
has some sort of structured data store implemented that could be
good at this!), and then have a way to feed additional information into
that system that would become the authoritative source for any
requirements for the extra metadata.

That, of course, smells like a database that draws metadata from git,
and augments with further streams of inputs.  There is certainly
something problematic about assuming that we can *always* get
supplementary data.  Begs the question of how we shame people
into going back and filling the blanks we wanted filled.

It seems foolish to me to imagine that we can ensure that the
data *always* arrives at commit time; any laziness there represents
a permanent "data fault"; making it asynchronous shifts the problem
to a different spot.  I suspect we can only approach success on it,
and get *partial* metadata, at best.  If it's enough better than nothing,
then maybe that's good enough.  And I'll bet that the Commitfest
database already contains a lot of the data desired to fill blanks...

Further, if the point is to encourage reviews by making sure credit
(and hence data to support GIVING credit) is given, then it is not
inapropos for those keen on receiving credit to be responsible for
marking off the patches they know they contributed to.  That's
less fragile than expecting all credit to be attached by the
committer at commit time.

--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


Re: [HACKERS] Template for commit messages

2016-01-30 Thread Robert Haas
On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
 wrote:
>> I think the best question to ask is:
>>
>> "What is the problem we are trying to solve?"
>
> The problem is alluring more patch reviewers, beta testers and bug
> reporters.  One of the offers is to credit them (I'm not exactly clear
> on what is the group to benefit from this, but the phrasing used in the
> meeting was "contributors to the release") by having a section somewhere
> in the release notes with a list of their names.  This proposal is
> different from the previous proposal because their names wouldn't appear
> next to each feature.
>
> So the problem, of course, is collating that list of names, and the
> point of having a commit template is to have a single, complete source
> of truth from where to extract the info.
>
> Personally I don't see value in having the commit message follow a
> machine-parseable format; like if you say "Backpatch to" instead of
> "Backpatch-through:" makes your commit message wrong.  I think what was
> being proposed is to have committers ensure that the commit messages
> always carried the necessary info (which, as far as I know, they do.)

Well, this gets at one of the problems here, which is that you can't
fix a commit message once the commit has been pushed.  So even if we
all agreed in principle to a standard format, it's not clear that you
could enforce compliance with that format to a degree sufficient to
make machine-parseability a reality.

But let's say you could somehow make it so that every commit message
was machine-parseable.  Then you could write a script which went
through the commit log since the branch point for the prior release
and extracted every name listed as a reviewer and printed them all
out.  Then you could put that in the release notes or on the project
web site someplace and say "The PostgreSQL Project thanks the
following list of people for reviewing patches during the 9.23 release
cycle".  Doing that same thing without machine-parseable commit
messages can of course also be done, but it's going to require
somebody to manually review every commit, which is a lot more work.

Similarly, you could do write a script to do things like "show me all
patches with person X as an author".  Right now that's actually kind
of hard to do, especially if that author happens to be a committer.
Or you could write a script to print out all commits from the last
week in the format: COMMITTER committed a patch from AUTHOR to do
SUMMARY, and then you could stick that into PWN, again instead of
having to do it by manually reviewing the commit message.

I'm not sure that those benefits are sufficient to justify the hassle
of trying to make a fixed template work.  But I think it's a little
strange to hear a bunch of people whose develop the world's most
advanced open source relational database system argue that structured
data is an intrinsically unused thing to have, and therefore we should
just store all of our information freeform in one very wide text
column.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-30 Thread Alvaro Herrera
Robert Haas wrote:
> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
>  wrote:

> > Personally I don't see value in having the commit message follow a
> > machine-parseable format; like if you say "Backpatch to" instead of
> > "Backpatch-through:" makes your commit message wrong.  I think what was
> > being proposed is to have committers ensure that the commit messages
> > always carried the necessary info (which, as far as I know, they do.)
> 
> Well, this gets at one of the problems here, which is that you can't
> fix a commit message once the commit has been pushed.

Yes, I'm aware that this is a problem.  I tried to raise the point that
we could use "git notes" to provide additional information after the
fact but was quickly made to shut up before it could be recorded in the
minutes.

If we were to adopt git notes or a similar system(*), we could use those
as a mechanism to install the machine-parseable data for each commit,
which I think fixes all the problems you point out.

(*) Another idea that comes to mind now that you mention this database
thingy of yours is to make a table or tables with commits and their
associated data, which could initially be populated from the commit
message and later updated.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-30 Thread Robert Haas
On Sat, Jan 30, 2016 at 5:22 AM, Alvaro Herrera
 wrote:
> Robert Haas wrote:
>> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera
>>  wrote:
>
>> > Personally I don't see value in having the commit message follow a
>> > machine-parseable format; like if you say "Backpatch to" instead of
>> > "Backpatch-through:" makes your commit message wrong.  I think what was
>> > being proposed is to have committers ensure that the commit messages
>> > always carried the necessary info (which, as far as I know, they do.)
>>
>> Well, this gets at one of the problems here, which is that you can't
>> fix a commit message once the commit has been pushed.
>
> Yes, I'm aware that this is a problem.  I tried to raise the point that
> we could use "git notes" to provide additional information after the
> fact but was quickly made to shut up before it could be recorded in the
> minutes.

Yeah, shut up, Alvaro!  We don't want to hear about you and your fancy
technological solutions!  :-)

> If we were to adopt git notes or a similar system(*), we could use those
> as a mechanism to install the machine-parseable data for each commit,
> which I think fixes all the problems you point out.

I haven't experimented enough to know whether it would or not, but I
think it would be interesting to find out whether it would or not.

> (*) Another idea that comes to mind now that you mention this database
> thingy of yours is to make a table or tables with commits and their
> associated data, which could initially be populated from the commit
> message and later updated.

Yeah.  It's a crazy thought, but it's almost like this databasey thing
was designed precisely for the purpose of allowing people to structure
their data in relational ways and then interact with it in convenient
fashion.

Personally, I think that if we had a database of commit metadata, we
could use that to do all sorts of interesting reporting.  I don't
think any of that reporting is absolutely necessary for the survival
of the project, but sometimes things that aren't absolutely necessary
can still be awfully nice.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Andres Freund
On 2016-01-29 04:42:08 -0500, Bruce Momjian wrote:
> On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote:
> > I have no prejudice in this area, other than one in favor of any
> > rules being fairly precise. As for nuances, I guess they can be
> > specified in the commit message. The one thing I do find annoying
> > from time to time is the limit on subject size. Sometimes it's very
> > difficult to be sufficiently communicative in, say, 50 characters.
> 
> Agreed, but that is a gitweb limit we can't control, I think.

That's not that hard to change. And neither git nor kernel people use 50
char limits. I'm *strongly* opposed to making 50 chars the limit for the
first line.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Tom Lane
Robert Haas  writes:
> On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane  wrote:
>> FWIW, I'm a bit suspicious of the idea that we need to make the commit
>> messages automated-tool-friendly.  What tools are there that would need
>> to extract this info, and would we trust them if they didn't understand
>> "nuances"?

> Well, I think what people are asking for is precisely a fixed format,
> and I do think there is value in that.  It's nice to capture the
> nuance, but the nuance is going to get flattened out anyway when the
> release notes are created.  If we all agree to use a fixed format,
> then a bunch of work there that probably has to be done manually can
> be automated.

I'm not particularly impressed by this argument --- as someone who
regularly prepares release notes, I see exactly zero value in this
to me.  I'm willing to go along with it if there's consensus, but the
argument that "Foo: Bar" format has more value than free-form hasn't
actually been made in any form that withstands any skepticism.

In any case, agreeing on a set of "Foo:" keywords isn't nearly enough
to allow any useful automated processing.  You have to standardize
the "Bar" part as well, and that hasn't been addressed at all.
Some example questions:

In "Bug:", bug number with or without "#"?  What format to use if
there's more than one related bug?

In headers referring to people: name? email? both? what if we have
incomplete information (not unusual in bug reports)? what about
referencing multiple people in same header? what can we do to avoid
variant spellings in different commit messages?

In "Backpatch-through:", how are we to indicate version numbers
exactly? what about special cases such as a patch applied
only to older branches?  And perhaps most importantly, why are
we bothering with that at all when git can tell us that much
more reliably?  (Personally, I only bother with mentioning this
in the commit message to the extent that I'm explaining *why*
I patched back so far and no further.  Which I think is useful
information that a "backpatch-through: N.N" kind of entry would
entirely fail to capture.)

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Heikki Linnakangas


On 28 January 2016 15:57:15 CET, Robert Haas  wrote:
>On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane  wrote:
>> Robert Haas  writes:
>>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
>>>  wrote:
 Why can't we do both? That is, have a free-form text with the
>nuances, and
 then Reviewed-By listing the main reviewers? The first one is for
>humans,
 the other one for automated tools.
>>
>>> I'm not objecting to or endorsing any specific proposal, just asking
>>> what we want to do about this.  I think the trick if we do it that
>way
>>> will be to avoid having it seem like too much duplication, but there
>>> may be a way to manage that.
>>
>> FWIW, I'm a bit suspicious of the idea that we need to make the
>commit
>> messages automated-tool-friendly.  What tools are there that would
>need
>> to extract this info, and would we trust them if they didn't
>understand
>> "nuances"?
>>
>> I'm on board with Bruce's template as being a checklist of points to
>be
>> sure to cover when composing a commit message.  I'm not sure we need
>> fixed-format rules.
>
>Well, I think what people are asking for is precisely a fixed format,
>and I do think there is value in that.  It's nice to capture the
>nuance, but the nuance is going to get flattened out anyway when the
>release notes are created.  If we all agree to use a fixed format,
>then a bunch of work there that probably has to be done manually can
>be automated.  However, if we all agree to use a fixed format except
>for you, we might as well just forget the whole thing, because the
>percentage of commits that are done by you is quite high.

Before I agree to adding fixed format lines to my commits, I'd like to know 
exactly what people would want to do with the information. "Bunch of work that 
probably could be automated" doesn't cut it. For example, if I tag someone as 
"Reviewed-by", does it mean that his name will automatically appear in the 
release notes? Or if there's a bug, is the reviewer then somehow responsible 
for missing it?

As a way of saying "thank you", I like a personalised, nuanced, message much 
better. True, we can do both. A good thing about processing the commit messages 
manually e.g  for compiling release notes is that there's human judgement on 
what to include.  Of course, that's a lot of work. Which is why I'd like to 
hear from whoever wants to make use of these lines to explain in more detail 
what information they need,  and what they would do with it, to make sure that 
what we add is actually useful, and that we don't add noise to the commit 
messages unnecessarily.

- Heikki



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote:
> I have no prejudice in this area, other than one in favor of any
> rules being fairly precise. As for nuances, I guess they can be
> specified in the commit message. The one thing I do find annoying
> from time to time is the limit on subject size. Sometimes it's very
> difficult to be sufficiently communicative in, say, 50 characters.

Agreed, but that is a gitweb limit we can't control, I think.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 03:16:18PM -0500, Stephen Frost wrote:
> > OK, but keep in mind whatever script committers user should remove tags
> > that are empty after exiting the editor.  I can provide the grep regex
> > in git somewhere too:
> > 
> >   egrep -v 
> > "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$"
> 
> If the template is there then, for my part at least, I wouldn't mind
> killing the empty lines.  Having a decent script would work too, of
> course... but I have to admit that I've not tried having a script modify
> my commit messages right before they're committed and, well, it'd take a
> bit for me to be comfortable with it.
> 
> No one wants garbled commit messages from a script that went awry. ;)

I have always used a script.  This removes trailing blank lines:

sed -e :a -e '/./,$!d;/^\n*$/{$d;N;};/\n$/ba'

and this removes adjacent blank lines:

cat --squeeze-blank

I can publish my script at the appropriate time.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Tom Lane
Andres Freund  writes:
> That's not that hard to change. And neither git nor kernel people use 50
> char limits. I'm *strongly* opposed to making 50 chars the limit for the
> first line.

Ditto.  It's hard enough to fit a useful headline in 75 characters.
I personally will ignore any rule that says it must be even less.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Joshua D. Drake

On 01/29/2016 02:59 AM, Heikki Linnakangas wrote:


Well, I think what people are asking for is precisely a fixed format,
and I do think there is value in that.  It's nice to capture the
nuance, but the nuance is going to get flattened out anyway when the
release notes are created.  If we all agree to use a fixed format,
then a bunch of work there that probably has to be done manually can
be automated.  However, if we all agree to use a fixed format except
for you, we might as well just forget the whole thing, because the
percentage of commits that are done by you is quite high.


Before I agree to adding fixed format lines to my commits, I'd like to know exactly what people 
would want to do with the information. "Bunch of work that probably could be automated" 
doesn't cut it. For example, if I tag someone as "Reviewed-by", does it mean that his 
name will automatically appear in the release notes? Or if there's a bug, is the reviewer then 
somehow responsible for missing it?

As a way of saying "thank you", I like a personalised, nuanced, message much 
better. True, we can do both. A good thing about processing the commit messages manually 
e.g  for compiling release notes is that there's human judgement on what to include.  Of 
course, that's a lot of work. Which is why I'd like to hear from whoever wants to make 
use of these lines to explain in more detail what information they need,  and what they 
would do with it, to make sure that what we add is actually useful, and that we don't add 
noise to the commit messages unnecessarily.

- Heikki


I think the best question to ask is:

"What is the problem we are trying to solve?"

"A bunch of work that probably could be automated"

Does not answer that question.

Sincerely,

Joshua D. Drake


--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-29 Thread Alvaro Herrera
Joshua D. Drake wrote:

> I think the best question to ask is:
> 
> "What is the problem we are trying to solve?"

The problem is alluring more patch reviewers, beta testers and bug
reporters.  One of the offers is to credit them (I'm not exactly clear
on what is the group to benefit from this, but the phrasing used in the
meeting was "contributors to the release") by having a section somewhere
in the release notes with a list of their names.  This proposal is
different from the previous proposal because their names wouldn't appear
next to each feature.

So the problem, of course, is collating that list of names, and the
point of having a commit template is to have a single, complete source
of truth from where to extract the info.

Personally I don't see value in having the commit message follow a
machine-parseable format; like if you say "Backpatch to" instead of
"Backpatch-through:" makes your commit message wrong.  I think what was
being proposed is to have committers ensure that the commit messages
always carried the necessary info (which, as far as I know, they do.)

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread David Fetter
On Thu, Jan 28, 2016 at 03:52:25PM +0100, Tom Lane wrote:
> Robert Haas  writes:
> > On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
> >  wrote:
> >> Why can't we do both? That is, have a free-form text with the nuances, and
> >> then Reviewed-By listing the main reviewers? The first one is for humans,
> >> the other one for automated tools.
> 
> > I'm not objecting to or endorsing any specific proposal, just asking
> > what we want to do about this.  I think the trick if we do it that way
> > will be to avoid having it seem like too much duplication, but there
> > may be a way to manage that.
> 
> FWIW, I'm a bit suspicious of the idea that we need to make the commit
> messages automated-tool-friendly.  What tools are there that would need
> to extract this info, and would we trust them if they didn't understand
> "nuances"?
> 
> I'm on board with Bruce's template as being a checklist of points to be
> sure to cover when composing a commit message.  I'm not sure we need
> fixed-format rules.

I've been asking for them for years so I can spend my time on the
PostgreSQL Weekly News more efficiently.  Maybe it's more efficient
for me to do this arranging than for each committer to do it.  I'd
like to imagine that committers are in a better position than I to
summarize their work.

Whatever we decide on here, I'd really appreciate it if every patch
sent to the list came with a sentence describing what that version of
it does, as scope drift frequently makes Subject: lines completely
wrong.

While I'm at it, I'd like to thank Andres Freund, Peter Geoghegan, and
Robert Haas in particular for making a habit of writing detailed
summaries and splitting patches into logical chunks.  All errors in
the PostgreSQL Weekly News are mine, but a little organization like
theirs would go a very long way, and not just for me.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote:
> * Joshua D. Drake (j...@commandprompt.com) wrote:
> > On 01/28/2016 06:57 AM, Robert Haas wrote:
> > 
> > >>I'm on board with Bruce's template as being a checklist of points to be
> > >>sure to cover when composing a commit message.  I'm not sure we need
> > >>fixed-format rules.
> > >
> > >Well, I think what people are asking for is precisely a fixed format,
> > >and I do think there is value in that.  It's nice to capture the
> > >nuance, but the nuance is going to get flattened out anyway when the
> > >release notes are created.  If we all agree to use a fixed format,
> > >then a bunch of work there that probably has to be done manually can
> > >be automated.  However, if we all agree to use a fixed format except
> > >for you, we might as well just forget the whole thing, because the
> > >percentage of commits that are done by you is quite high.
> > 
> > Yes, we are either all in or we may as well forgo this.
> 
> I don't have a particular issue with it, but would like whatever
> template is decided upon to be included in our git repo and then we
> should be able to make it the template that's opened up when people go
> to commit pretty easily.

OK, but keep in mind whatever script committers user should remove tags
that are empty after exiting the editor.  I can provide the grep regex
in git somewhere too:

  egrep -v "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): 
*$"

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Joshua D. Drake

On 01/28/2016 06:34 AM, Bruce Momjian wrote:

On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote:

On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
 wrote:

How about
User-Interface-Bikeshedded-By:
?


+1


That's sort of implicitly pejorative.   Maybe we could find another
way to phrase that, like "Design-suggestions-by" or maybe a more
general "Suggestions-by".


I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch,
or to the discussion of labels for the commit messages.


Contribution-by:

Definition: Individuals who provided notable review which may or may not 
have been code review.


Sincerely,

Joshua D. Drake


--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Tomas Vondra

On 01/28/2016 03:37 PM, Robert Haas wrote:

On Thu, Jan 28, 2016 at 9:34 AM, Bruce Momjian  wrote:

On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote:

On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
 wrote:

How about
User-Interface-Bikeshedded-By:
?


+1


That's sort of implicitly pejorative.   Maybe we could find another
way to phrase that, like "Design-suggestions-by" or maybe a more
general "Suggestions-by".


I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch,
or to the discussion of labels for the commit messages.


I thought it was a proposed commit message label and that the original
suggestion was tongue-in-cheek, but I might be misreading things.


Perhaps I'm wrong, but I believe that particular header was not really 
meant seriously.



--
Tomas Vondra  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Stephen Frost
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote:
> > * Joshua D. Drake (j...@commandprompt.com) wrote:
> > > On 01/28/2016 06:57 AM, Robert Haas wrote:
> > > 
> > > >>I'm on board with Bruce's template as being a checklist of points to be
> > > >>sure to cover when composing a commit message.  I'm not sure we need
> > > >>fixed-format rules.
> > > >
> > > >Well, I think what people are asking for is precisely a fixed format,
> > > >and I do think there is value in that.  It's nice to capture the
> > > >nuance, but the nuance is going to get flattened out anyway when the
> > > >release notes are created.  If we all agree to use a fixed format,
> > > >then a bunch of work there that probably has to be done manually can
> > > >be automated.  However, if we all agree to use a fixed format except
> > > >for you, we might as well just forget the whole thing, because the
> > > >percentage of commits that are done by you is quite high.
> > > 
> > > Yes, we are either all in or we may as well forgo this.
> > 
> > I don't have a particular issue with it, but would like whatever
> > template is decided upon to be included in our git repo and then we
> > should be able to make it the template that's opened up when people go
> > to commit pretty easily.
> 
> OK, but keep in mind whatever script committers user should remove tags
> that are empty after exiting the editor.  I can provide the grep regex
> in git somewhere too:
> 
>   egrep -v 
> "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$"

If the template is there then, for my part at least, I wouldn't mind
killing the empty lines.  Having a decent script would work too, of
course... but I have to admit that I've not tried having a script modify
my commit messages right before they're committed and, well, it'd take a
bit for me to be comfortable with it.

No one wants garbled commit messages from a script that went awry. ;)

Thanks!

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Alvaro Herrera
Stephen Frost wrote:

> > OK, but keep in mind whatever script committers user should remove tags
> > that are empty after exiting the editor.  I can provide the grep regex
> > in git somewhere too:
> > 
> >   egrep -v 
> > "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$"
> 
> If the template is there then, for my part at least, I wouldn't mind
> killing the empty lines.  Having a decent script would work too, of
> course... but I have to admit that I've not tried having a script modify
> my commit messages right before they're committed and, well, it'd take a
> bit for me to be comfortable with it.
> 
> No one wants garbled commit messages from a script that went awry. ;)

Maybe it'd be better to have the lines start with a # , because then
git commit itself removes those as comments.  So the committer would
need to remove the # and then fill in the data for the field.

git-commit(1) says:

   -t , --template=
   When editing the commit message, start the editor with the contents
   in the given file. The commit.template configuration variable is
   often used to give this option implicitly to the command. This
   mechanism can be used by projects that want to guide participants
   with some hints on what to write in the message in what order. If
   the user exits the editor without editing the message, the commit
   is aborted. This has no effect when a message is given by other
   means, e.g. with the -m or -F options.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Andrew Dunstan



On 01/28/2016 09:57 AM, Robert Haas wrote:

On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane  wrote:

Robert Haas  writes:

On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
 wrote:

Why can't we do both? That is, have a free-form text with the nuances, and
then Reviewed-By listing the main reviewers? The first one is for humans,
the other one for automated tools.

I'm not objecting to or endorsing any specific proposal, just asking
what we want to do about this.  I think the trick if we do it that way
will be to avoid having it seem like too much duplication, but there
may be a way to manage that.

FWIW, I'm a bit suspicious of the idea that we need to make the commit
messages automated-tool-friendly.  What tools are there that would need
to extract this info, and would we trust them if they didn't understand
"nuances"?

I'm on board with Bruce's template as being a checklist of points to be
sure to cover when composing a commit message.  I'm not sure we need
fixed-format rules.

Well, I think what people are asking for is precisely a fixed format,
and I do think there is value in that.  It's nice to capture the
nuance, but the nuance is going to get flattened out anyway when the
release notes are created.  If we all agree to use a fixed format,
then a bunch of work there that probably has to be done manually can
be automated.  However, if we all agree to use a fixed format except
for you, we might as well just forget the whole thing, because the
percentage of commits that are done by you is quite high.




Yeah.

I have no prejudice in this area, other than one in favor of any rules 
being fairly precise. As for nuances, I guess they can be specified in 
the commit message. The one thing I do find annoying from time to time 
is the limit on subject size. Sometimes it's very difficult to be 
sufficiently communicative in, say, 50 characters.


cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
There has been a request in the FOSDEM developers meeting that
committers use a more consistent format for commit messages.  This is
the format I use:

-- email subject limit -
-- gitweb summary limit --


Report by

Patch by

Reviewed by

Backpatch through

The dashed lines are used to specify a target length for the summary
line and are automatically removed before the commit message is posted.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Tomas Vondra

On 01/28/2016 01:57 PM, Robert Haas wrote:
...

One of the things I like about the current free-form approach is that
you can indicate nuances, like:

Person X reviewed an earlier version of this patch that was a lot
different than this one.
Person X reviewed this patch but didn't totally endorse it.
Person X wrote the documentation for the patch, but none of the code.
Person X wrote the vast bulk of this patch, even though there are some
other authors.

Should I just abandon the idea of trying to capture those details, or
does this format contemplate a way to include them?


Why can't we do both? That is, have a free-form text with the nuances, 
and then Reviewed-By listing the main reviewers? The first one is for 
humans, the other one for automated tools.




(Also an important question: Has Tom agreed to use this new format?
Because I think that anything the rest of agree on that he's not
prepared to endorse is not going to have much value.)



I can't speak for Tom, but I'm sitting fairly close to him and I haven't 
heard any complains or even groaning.


regards

--
Tomas Vondra  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Robert Haas
On Thu, Jan 28, 2016 at 3:52 AM, Bruce Momjian  wrote:
> There has been a request in the FOSDEM developers meeting that
> committers use a more consistent format for commit messages.  This is
> the format I use:
>
> -- email subject limit -
> -- gitweb summary limit --
>
>
> Report by
>
> Patch by
>
> Reviewed by
>
> Backpatch through
>
> The dashed lines are used to specify a target length for the summary
> line and are automatically removed before the commit message is posted.

One of the things I like about the current free-form approach is that
you can indicate nuances, like:

Person X reviewed an earlier version of this patch that was a lot
different than this one.
Person X reviewed this patch but didn't totally endorse it.
Person X wrote the documentation for the patch, but none of the code.
Person X wrote the vast bulk of this patch, even though there are some
other authors.

Should I just abandon the idea of trying to capture those details, or
does this format contemplate a way to include them?

(Also an important question: Has Tom agreed to use this new format?
Because I think that anything the rest of agree on that he's not
prepared to endorse is not going to have much value.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 11:30:58AM +0100, Tomas Vondra wrote:
> Any reason why not to adapt the git message conventions from kernel?
> 
> https://git.wiki.kernel.org/index.php/CommitMessageConventions
> 
> I'd expect there are tools already working with that format, making
> the life easier for us.

Good idea.  :-)  Updated template:

-- email subject limit -
-- gitweb summary limit --


Reported-by:

Bug:

Patch-by:

Reviewed-by:

Backpatch through:

I had to make up "Patch-by:" as it wasn't listed.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Tomas Vondra
Dne 28. 1. 2016 11:57 napsal uživatel "Alvaro Herrera" <
alvhe...@2ndquadrant.com>:
>
> Magnus Hagander wrote:
>
> > They also had tested-by, it might be an idea to include that as well?
>
> How about
> User-Interface-Bikeshedded-By:
> ?

+1

>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 03:52:00AM -0500, Bruce Momjian wrote:
> There has been a request in the FOSDEM developers meeting that
> committers use a more consistent format for commit messages.  This is
> the format I use:

Here is an updated version that includes a potential bug number:

-- email subject limit -
-- gitweb summary limit --


Report by

Bug #

Patch by

Reviewed by

Backpatch through

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Tomas Vondra

Hi,

On 01/28/2016 11:06 AM, Bruce Momjian wrote:

On Thu, Jan 28, 2016 at 03:52:00AM -0500, Bruce Momjian wrote:

There has been a request in the FOSDEM developers meeting that
committers use a more consistent format for commit messages.  This is
the format I use:


Here is an updated version that includes a potential bug number:

-- email subject limit -
-- gitweb summary limit --


Report by

Bug #

Patch by

Reviewed by

Backpatch through



Any reason why not to adapt the git message conventions from kernel?

https://git.wiki.kernel.org/index.php/CommitMessageConventions

I'd expect there are tools already working with that format, making the 
life easier for us.


regards

--
Tomas Vondra  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Alvaro Herrera
Magnus Hagander wrote:

> They also had tested-by, it might be an idea to include that as well?

How about
User-Interface-Bikeshedded-By:
?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Alvaro Herrera
Bruce Momjian wrote:
> There has been a request in the FOSDEM developers meeting that
> committers use a more consistent format for commit messages.

Let me point out that the reason this is being put forward is to make
sure we have the reviewers listed for each patch, so that we can add a
paragraph somewhere at the bottom of the release notes listing people
that helped with the release.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Magnus Hagander
On Thu, Jan 28, 2016 at 11:49 AM, Bruce Momjian  wrote:

> On Thu, Jan 28, 2016 at 11:30:58AM +0100, Tomas Vondra wrote:
> > Any reason why not to adapt the git message conventions from kernel?
> >
> > https://git.wiki.kernel.org/index.php/CommitMessageConventions
> >
> > I'd expect there are tools already working with that format, making
> > the life easier for us.
>
> Good idea.  :-)  Updated template:
>
> -- email subject limit -
> -- gitweb summary limit --
>
>
> Reported-by:
>
> Bug:
>
> Patch-by:
>
> Reviewed-by:
>
> Backpatch through:
>
> I had to make up "Patch-by:" as it wasn't listed.
>
>
The original format uses the author for that (author != committer in git),
but that changes how we work a bit more. I'd be happy to just clal it
"Author" rather than "Patch-by".

I also suggest a - in "Backpatch-through:" -- since all the others are
intentionally mad ewithout a space, I assume that's for easier parsing.

They also had tested-by, it might be an idea to include that as well?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 11:53:44AM +0100, Magnus Hagander wrote:
> The original format uses the author for that (author != committer in git), but
> that changes how we work a bit more. I'd be happy to just clal it "Author"
> rather than "Patch-by".
> 
> I also suggest a - in "Backpatch-through:" -- since all the others are
> intentionally mad ewithout a space, I assume that's for easier parsing.
> 
> They also had tested-by, it might be an idea to include that as well? 

OK, updated based on those suggestions:

-- email subject limit -
-- gitweb summary limit --


Reported-by:

Bug:

Author:

Reviewed-by:

Tested-by:

Backpatch-through:

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Bruce Momjian
On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
>  wrote:
> >> How about
> >> User-Interface-Bikeshedded-By:
> >> ?
> >
> > +1
> 
> That's sort of implicitly pejorative.   Maybe we could find another
> way to phrase that, like "Design-suggestions-by" or maybe a more
> general "Suggestions-by".

I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch,
or to the discussion of labels for the commit messages.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Robert Haas
On Thu, Jan 28, 2016 at 9:34 AM, Bruce Momjian  wrote:
> On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote:
>> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
>>  wrote:
>> >> How about
>> >> User-Interface-Bikeshedded-By:
>> >> ?
>> >
>> > +1
>>
>> That's sort of implicitly pejorative.   Maybe we could find another
>> way to phrase that, like "Design-suggestions-by" or maybe a more
>> general "Suggestions-by".
>
> I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch,
> or to the discussion of labels for the commit messages.

I thought it was a proposed commit message label and that the original
suggestion was tongue-in-cheek, but I might be misreading things.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Alvaro Herrera
Robert Haas wrote:
> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
>  wrote:
> >> How about
> >> User-Interface-Bikeshedded-By:
> >> ?
> >
> > +1
> 
> That's sort of implicitly pejorative.   Maybe we could find another
> way to phrase that, like "Design-suggestions-by" or maybe a more
> general "Suggestions-by".

Apologies, I was kidding actually -- I don't think we should list people
on patches just because they provided some input in the thread, but
people that actually reviewed the patch.  Otherwise we risk diluting the
list in the release notes (or wherever it is that we end up crediting
reviewers/contributors), which is also undesirable.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Tom Lane
Robert Haas  writes:
> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
>  wrote:
>> Why can't we do both? That is, have a free-form text with the nuances, and
>> then Reviewed-By listing the main reviewers? The first one is for humans,
>> the other one for automated tools.

> I'm not objecting to or endorsing any specific proposal, just asking
> what we want to do about this.  I think the trick if we do it that way
> will be to avoid having it seem like too much duplication, but there
> may be a way to manage that.

FWIW, I'm a bit suspicious of the idea that we need to make the commit
messages automated-tool-friendly.  What tools are there that would need
to extract this info, and would we trust them if they didn't understand
"nuances"?

I'm on board with Bruce's template as being a checklist of points to be
sure to cover when composing a commit message.  I'm not sure we need
fixed-format rules.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Robert Haas
On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra
 wrote:
>> How about
>> User-Interface-Bikeshedded-By:
>> ?
>
> +1

That's sort of implicitly pejorative.   Maybe we could find another
way to phrase that, like "Design-suggestions-by" or maybe a more
general "Suggestions-by".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Robert Haas
On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
 wrote:
> On 01/28/2016 01:57 PM, Robert Haas wrote:
>> One of the things I like about the current free-form approach is that
>> you can indicate nuances, like:
>>
>> Person X reviewed an earlier version of this patch that was a lot
>> different than this one.
>> Person X reviewed this patch but didn't totally endorse it.
>> Person X wrote the documentation for the patch, but none of the code.
>> Person X wrote the vast bulk of this patch, even though there are some
>> other authors.
>>
>> Should I just abandon the idea of trying to capture those details, or
>> does this format contemplate a way to include them?
>
> Why can't we do both? That is, have a free-form text with the nuances, and
> then Reviewed-By listing the main reviewers? The first one is for humans,
> the other one for automated tools.

I'm not objecting to or endorsing any specific proposal, just asking
what we want to do about this.  I think the trick if we do it that way
will be to avoid having it seem like too much duplication, but there
may be a way to manage that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Joshua D. Drake

On 01/28/2016 06:57 AM, Robert Haas wrote:


I'm on board with Bruce's template as being a checklist of points to be
sure to cover when composing a commit message.  I'm not sure we need
fixed-format rules.


Well, I think what people are asking for is precisely a fixed format,
and I do think there is value in that.  It's nice to capture the
nuance, but the nuance is going to get flattened out anyway when the
release notes are created.  If we all agree to use a fixed format,
then a bunch of work there that probably has to be done manually can
be automated.  However, if we all agree to use a fixed format except
for you, we might as well just forget the whole thing, because the
percentage of commits that are done by you is quite high.


Yes, we are either all in or we may as well forgo this.

Sincerely,

Joshua D. Drake





--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Stephen Frost
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 01/28/2016 06:57 AM, Robert Haas wrote:
> 
> >>I'm on board with Bruce's template as being a checklist of points to be
> >>sure to cover when composing a commit message.  I'm not sure we need
> >>fixed-format rules.
> >
> >Well, I think what people are asking for is precisely a fixed format,
> >and I do think there is value in that.  It's nice to capture the
> >nuance, but the nuance is going to get flattened out anyway when the
> >release notes are created.  If we all agree to use a fixed format,
> >then a bunch of work there that probably has to be done manually can
> >be automated.  However, if we all agree to use a fixed format except
> >for you, we might as well just forget the whole thing, because the
> >percentage of commits that are done by you is quite high.
> 
> Yes, we are either all in or we may as well forgo this.

I don't have a particular issue with it, but would like whatever
template is decided upon to be included in our git repo and then we
should be able to make it the template that's opened up when people go
to commit pretty easily.

Thanks!

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Template for commit messages

2016-01-28 Thread Robert Haas
On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
>>  wrote:
>>> Why can't we do both? That is, have a free-form text with the nuances, and
>>> then Reviewed-By listing the main reviewers? The first one is for humans,
>>> the other one for automated tools.
>
>> I'm not objecting to or endorsing any specific proposal, just asking
>> what we want to do about this.  I think the trick if we do it that way
>> will be to avoid having it seem like too much duplication, but there
>> may be a way to manage that.
>
> FWIW, I'm a bit suspicious of the idea that we need to make the commit
> messages automated-tool-friendly.  What tools are there that would need
> to extract this info, and would we trust them if they didn't understand
> "nuances"?
>
> I'm on board with Bruce's template as being a checklist of points to be
> sure to cover when composing a commit message.  I'm not sure we need
> fixed-format rules.

Well, I think what people are asking for is precisely a fixed format,
and I do think there is value in that.  It's nice to capture the
nuance, but the nuance is going to get flattened out anyway when the
release notes are created.  If we all agree to use a fixed format,
then a bunch of work there that probably has to be done manually can
be automated.  However, if we all agree to use a fixed format except
for you, we might as well just forget the whole thing, because the
percentage of commits that are done by you is quite high.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers