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 personall
-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,
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 visi
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 archive
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/
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
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 re
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
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 enou
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
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 refr
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 messa
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 ea
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
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 t
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 rea
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 repo
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 th
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
>> > "Backpat
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
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 wh
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
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 agre
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 list
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
>>
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
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
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 o
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
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): *$"
>
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
* 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
>
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 pejor
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.
* 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 pe
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 tha
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
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 human
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 o
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
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 "Su
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. M
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-sug
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
Enterpris
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 th
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
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 -
>
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.2ndQua
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:" --
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-hacke
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
paragrap
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
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.
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 tha
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:
-- e
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 --
56 matches
Mail list logo
