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
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
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
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
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
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.
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
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
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.
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
> >
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
-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
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
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
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
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
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
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
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
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
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;
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
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
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
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 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
> >
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
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
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,
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
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.
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
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
* 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
>
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
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 --
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
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
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 Herrera
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:
--
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
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
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
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
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:"
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
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:
>> >> ?
>> >
>> >
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
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
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
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
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
* 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
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
56 matches
Mail list logo