On 05/12/2012 09:02 PM, Bruce Momjian wrote:
On Sat, May 12, 2012 at 03:42:48PM -0700, Josh Berkus wrote:
How many names on a single item is ideal? The activity of reviewers and
their names on commit messages has greatly expanded the number of
potential names per item.
How much of a downside is having the names in the release notes? For
example, we decided that company names shouldn't be on release note
items, so there is a case where we decided names were more of a negative
than a positive. Are there other negatives? Do other project release
notes have developer names? How are these names perceived by our
general readers?
The two paragraphs above show the main problem.
Who gets listed on each item is a matter of some contention. For
example, if Robert Haas reviews a patch, and makes substantial
suggesitons and fixes to the patch, should he be listed on it as well?
If so, how much work is required for someone to be listed if they're not
the original author? What if we merge two patches, but take 90% of
Patch A and only 10% of Patch B? etc.
One idea I just had was to optionally put developer names on section
headings. That would remove my name from the nine pg_upgrade entries in
the pg_upgrade section. We could put Tom Lane's name at the top of the
optimizer section, and some of the server-side languages could be
trimmed down this way.
Say you do eight and someone else does one. I just don't see any benefit
in this. The fact that a name is repeated a few times really doesn't matter.
Should we go with a single developer per item, and then let people
suggest corrections? With reviewers involved, and often multiple commit
messages per release note item, the just isn't enough detail in git logs
to reproduce this accurately. I also over-emphasized new
developers/reviewers, but that seems to have distorted the other goals
unacceptably.
Most cases should be pretty clear. Most features have a single major
commit. The author(s) mentioned there are who should be listed, IMNSHO.
That might leave a handful of cases where more judgement is required.
We seem to be in danger of overthinking this.
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
