Re: [HACKERS] Thoughts on unit testing?

[Torsten Zuehlsdorff]

On 13.08.2017 21:19, Peter Geoghegan wrote:

On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro
 wrote:

The current regression tests, isolation tests and TAP tests are very
good (though I admit my experience with TAP is limited), but IMHO we
are lacking support for C-level unit testing.  Complicated, fiddly
things with many states, interactions, edge cases etc can be hard to
get full test coverage on from the outside.  Consider
src/backend/utils/mmgr/freepage.c as a case in point.


It is my understanding that much of the benefit of unit testing comes
from maintainability. 


I never had this understanding. I write tests to test expected behavior 
and not the coded one. If possible i separate the persons writing 
unit-tests from the ones writing the function itself. Having someone 
really read the documentation or translate the expectation into a 
test-case, makes sure, the function itself works well.


Also it really safes time in the long run. Subtle changes / bugs can be 
caught which unit-tests. Also a simple bug-report can be translated into 
a unit-test make sure that the bugfix really works and that no 
regression will happen later. I literally saved ones a week of work with 
a single unit-test.


There are many other advantages, but to earn them the code need to be 
written to be testable. And this is often not the case. Most literature 
advises to Mocking, mixins or other techniques, which most times just 
translate into "this code is not written testable" or "the technique / 
language / concept / etc is not very good in being testable".


Greetings,
Torsten


--
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] Remove 1MB size limit in tsvector

[Torsten Zuehlsdorff]

On 01.08.2017 22:00, Ildus K wrote:

On Tue, 1 Aug 2017 15:33:08 -0400
Robert Haas  wrote:


On Tue, Aug 1, 2017 at 3:10 PM, Ildus K
 wrote:

So this would break pg_upgrade for tsvector columns?


I added a function that will convert old tsvectors on the fly. It's
the approach used in hstore before.


Does that mean the answer to the question that I asked is "yes, but I
have a workaround" or does it mean that the answer is "no"?



It's a workaround. DatumGetTSVector and
DatumGetTSVectorCopy will upgrade tsvector on the fly if it
has old format.


I'm not familiar with pg_upgrade, but want to ask: should this 
workaround be part of pg_upgrade?


Greetings,
Torsten


--
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] Checksums by default?

[Torsten Zuehlsdorff]

On 21.01.2017 19:35, Tom Lane wrote:

Andres Freund  writes:

Sure, it might be easy, but we don't have it.  Personally I think
checksums just aren't even ready for prime time. If we had:
- ability to switch on/off at runtime (early patches for that have IIRC
  been posted)
- *builtin* tooling to check checksums for everything
- *builtin* tooling to compute checksums after changing setting
- configurable background sweeps for checksums


Yeah, and there's a bunch of usability tooling that we don't have,
centered around "what do you do after you get a checksum error?".
AFAIK there's no way to check or clear such an error; but without
such tools, I'm afraid that checksums are as much of a foot-gun
as a benefit.


I wanted to raise the same issue. A "something is broken" flag is fine 
to avoid more things get broken. But if you can't repair them, its not 
very useful.


Since i'm a heavy user of ZFS: there are checksums and if you enable 
shadow-copies or using a raid, checksums are helpful, since the allow to 
recover from the problems.


I personally would prefer to enable checksums manually and than get the 
possibility to repair damages. Manually because this would at least 
double the needed space.


Greetings,
Torsten


--
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] Checksums by default?

[Torsten Zuehlsdorff]

On 21.01.2017 19:37, Stephen Frost wrote:

* Tom Lane (t...@sss.pgh.pa.us) wrote:

Stephen Frost  writes:

Because I see having checksums as, frankly, something we always should
have had (as most other databases do, for good reason...) and because
they will hopefully prevent data loss.  I'm willing to give us a fair
bit to minimize the risk of losing data.


To be perfectly blunt, that's just magical thinking.  Checksums don't
prevent data loss in any way, shape, or form.  In fact, they can *cause*
data loss, or at least make it harder for you to retrieve your data,
in the event of bugs causing false-positive checksum failures.


This is not a new argument, at least to me, and I don't agree with it.


I don't agree also. Yes, statistically it is more likely that checksum 
causes data-loss. The IO is greater, therefore the disc has more to do 
and breaks faster.
But the same is true for RAID: adding more disk increases the odds of an 
disk-fallout.


So: yes. If you use checksums at a single disc its more likely to cause 
problems. But if you managed it right (like ZFS for example) its an 
overall gain.



What checksums can do for you, perhaps, is notify you in a reasonably
timely fashion if you've already lost data due to storage-subsystem
problems.  But in a pretty high percentage of cases, that fact would
be extremely obvious anyway, because of visible data corruption.


Exactly, and that awareness will allow a user to prevent further data
loss or corruption.  Slow corruption over time is a very much known and
accepted real-world case that people do experience, as well as bit
flipping enough for someone to write a not-that-old blog post about
them:

https://blogs.oracle.com/ksplice/entry/attack_of_the_cosmic_rays1

A really nice property of checksums on pages is that they also tell you
what data you *didn't* lose, which can be extremely valuable.


Indeed!

Greetings,
Torsten


--
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] kqueue

[Torsten Zuehlsdorff]

On 28.09.2016 23:39, Thomas Munro wrote:

On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske  wrote:

On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro
 wrote:

Ok, here's a version tweaked to use EVFILT_PROC for postmaster death
detection instead of the pipe, as Tom Lane suggested in another
thread[1].

[...]


Ran benchmarks on unaltered 96rc1 again just to be safe. Those are first.
Decided to throw a 32 process test in there as well to see if there's
anything going on between 4 and 64


Thanks!  A summary:

[summary]

The variation in the patched 64 client numbers is quite large, ranging
from ~66.5k to ~79.5k.  The highest number matched the unpatched
numbers which ranged 77.9k to 80k.  I wonder if that is noise and we
need to run longer (in which case the best outcome might be 'this
patch is neutral on FreeBSD'), or if something the patch does is doing
is causing that (for example maybe EVFILT_PROC proc filters causes
contention on the process table lock).

[..]

It's difficult to draw any conclusions at this point.


I'm currently setting up a new FreeBSD machine. Its a FreeBSD 11 with 
ZFS, 64 GB RAM and Quad Core. If you're interested in i can give you 
access for more tests this week. Maybe this will help to draw any 
conclusion.


Greetings,
Torsten


--
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] Why we lost Uber as a user

[Torsten Zuehlsdorff]

On 03.08.2016 21:05, Robert Haas wrote:

On Wed, Aug 3, 2016 at 2:23 PM, Tom Lane  wrote:

Robert Haas  writes:

I don't think they are saying that logical replication is more
reliable than physical replication, nor do I believe that to be true.
I think they are saying that if logical corruption happens, you can
fix it by typing SQL statements to UPDATE, INSERT, or DELETE the
affected rows, whereas if physical corruption happens, there's no
equally clear path to recovery.


Well, that's not an entirely unreasonable point, but I dispute the
implication that it makes recovery from corruption an easy thing to do.
How are you going to know what SQL statements to issue?  If the master
database is changing 24x7, how are you going to keep up with that?


I think in many cases people fix their data using business logic.  For
example, suppose your database goes down and you have to run
pg_resetxlog to get it back up.  You dump-and-restore, as one does,
and find that you can't rebuild one of your unique indexes because
there are now two records with that same PK.  Well, what you do is you
look at them and judge which one has the correct data, often the one
that looks more complete or the one with the newer timestamp.  Or,
maybe you need to merge them somehow.  In my experience helping users
through problems of this type, once you explain the problem to the
user and tell them they have to square it on their end, the support
call ends.  The user may not always be entirely thrilled about having
to, say, validate a problematic record against external sources of
truth, but they usually know how to do it.  Database bugs aren't the
only way that databases become inaccurate.  If the database that they
use to keep track of land ownership in the jurisdiction where I live
says that two different people own the same piece of property,
somewhere there is a paper deed in a filing cabinet.  Fishing that out
to understand what happened may not be fun, but a DBA can explain that
problem to other people in the organization and those people can get
it fixed.  It's a problem, but it's fixable.

On the other hand, if a heap tuple contains invalid infomask bits that
cause an error every time you read the page (this actually happened to
an EnterpriseDB customer!), the DBA can't tell other people how to fix
it and can't fix it personally either.  Instead, the DBA calls me.


After reading this statement the ZFS filesystem pops into my mind. It 
has protection build in against various problems (data degradation, 
current spikes, phantom writes, etc).


For me this raises two questions:

1) would the usage of ZFS prevent such errors?

My feeling would say yes, but i have no idea about how a invalid 
infomask bit could occur.


2) would it be possible to add such prevention to PostgreSQL

I know this could add a massive overhead, but it its optional this could 
be a fine thing?


Greetings,
Torsten


--
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] Add generate_series(date,date) and generate_series(date,date,integer)

[Torsten Zuehlsdorff]

On 26.01.2016 07:52, Simon Riggs wrote:


Imagine for example a script that in some rare cases passes happens to
pass infinity into generate_series() - in that case I'd much rather error
out than wait till the end of the universe.

So +1 from me to checking for infinity.



+1

ERROR infinite result sets are not supported, yet


Maybe we should skip the "yet". Or do we really plan to support them in 
(infinite) future? ;)


+1 from me to check infinity also.

Greetings,
Torsten



--
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] Releasing in September

[Torsten Zuehlsdorff]

On 26.01.2016 02:09, Peter Eisentraut wrote:

On 1/25/16 2:48 AM, Torsten Zühlsdorff wrote:

Nobody, but there are different solutions. And the same solutions works
different in quality and quantity in the different projects.
In FreeBSD for example there is an online tool for review
(http://review.freebsd.org) which was opened to public. There you can
review any code, left comments in the parts you wanted, submit different
users to it etc.
It is not perfect, but a huge step forward for the project. And
something i misses here often.
But as stated earlier in another thread: for a not-so-deep-involved
volunteer, it is often unclear *what* to review. The threads are long
and often there is no final description about how the patch is supposed
to work. That make testing quite hard and time consuming.


I agree better code review tooling could help a bit.  The URL you post
above doesn't work at the moment (for me), though.


I'm sorry, the url contains a typo. The correct one is:
https://reviews.freebsd.org/

Greetings,
Torsten


--
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] Extracting fields from 'infinity'::TIMESTAMP[TZ]

[Torsten Zuehlsdorff]

On 09.11.2015 17:41, Tom Lane wrote:

Kevin Grittner  writes:

On Monday, November 9, 2015 9:37 AM, Robert Haas  wrote:

That doesn't seem like enough consensus to commit this patch, which
would change everything to +/-infinity.  That particular choice
wouldn't bother me much, but it sounds like other people aren't sold.
I think we need to try to hash that out a little more rather than
rushing into a backward-incompatible change.



I agree that none of this should be back-patched.


Definitely.


I agree that a timestamp[tz] of infinity should yield infinity for
epoch.


I think everybody is sold on that much.


My first choice for other things would be NaN, but throwing an
error instead would be OK.


Since the function hasn't thrown error for such cases in the past, making
it do so now would likely break applications.  More than once, we've
had to modify functions to avoid throwing errors so that you don't get
incidental errors when blindly applying a function to all entries in a
column.  I think going in the opposite direction would elicit protests.


An error will also break legit SQL statements.


I could see using NaN except for one thing: it'd mean injecting a rather
fundamental dependence on IEEE math into a basic function definition.  You
can be just about 100% certain that if the SQL committee ever addresses
this case, it won't be with NaN.


ACK.


What about returning NULL for the ill-defined cases?  That seems to
comport with SQL's notion of NULL as "unknown/undefined".


This is the first i would expect in such a case.

+ 1 for NULL.

Greetings,
Torsten


--
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] September 2015 Commitfest

[Torsten Zuehlsdorff]

On 05.11.2015 13:49, Craig Ringer wrote:


I believe that we need to lower the barrier for testing.


While I agree, I'd also like to note that formulaic testing is often
of limited utility. Good testing still requires a significant
investment of time and effort to understand the changes made by a
patch, which areas need focused attention, think about corner cases,
etc.


Yes, you are right. But a limited test is better than no test at all. 
But of course not enough.


For me it is easy to check comments or sql commands, but not the c code. 
But with lower barriers it would be easier to test 2 of the 3 mentioned 
items. At the moment its often none, because its hard.



"make check passes" doesn't really tell anyone that much.


I could even imagine to set up an open for everyone test-instance of HEAD
where users are allowed to test like the wanted. Than the barrier is reduced
to "connect to PostgreSQL and execute SQL".


Gee, that'd be fun to host ;)

>

More seriously, it's not HEAD that's of that much interest, it's HEAD
+ [some patch or set of patches].

There are systems that can pull in patchsets, build a project, and run
it. But for something like PostgreSQL it'd be pretty hard to offer
wide public access, given the trivial potential for abuse.


Yes, but i would do this. Creating a FreeBSD Jail which is reset 
regularly is no great deal and very secure. My bigger problem is the 
lack of IPv4 addresses. At the moment i am limited to IPv6 only hosts.


Greetings,
Torsten


--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 01.10.2015 00:27, Tom Lane wrote:

Josh Berkus  writes:

On 09/30/2015 03:10 PM, Tom Lane wrote:

I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
something happen here".  The lack of any volunteers suggests strongly
that this thread is a waste of time, just as the several similar ones
before it have been.



Hmmm?  Frost volunteered to stand up debbugs.


So he did, and did anyone volunteer to put data into it, or to do ongoing
curation of said data?


Yes, i did.

Greetings,
Torsten



--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

Hello,

On 29.09.2015 00:34, Tom Lane wrote:

Jim Nasby  writes:

On 9/28/15 11:43 AM, Andres Freund wrote:

It has been stated pretty clearly in this thread by a number of senior
community people that we're not going to use a closed source system.



GitLab OTOH is released under a MIT license, so it is an option. I don't
know how it compares to other suggested options, but if YUriy wants to
propose it it's at least a viable option.


I think a more accurate summary of what's been said is that we won't
consider putting any important functionality on proprietary platforms,
of which closed-source tools would be a subset.  The intention of the
community is that we'll be around for as long as there's a critical mass
of people interested in maintaining Postgres.  We will not be dependent
on any one company, and that's why e.g. github is out.  (A lot of smaller
open-source projects don't have the luxury of rejecting such options ...
but we do, and we will.)

Now, running gitlab on community-owned hardware would potentially be an
option, if we find gitlab attractive from a functionality standpoint.
The question I'd have about that is whether it has a real development
community, or is open-source in name only.  If github did go belly up,
would we find ourselves maintaining the gitlab code all by ourselves?
That might not be the end of the world, but it wouldn't be a good use
of community time either.


I ported GitLab to run on FreeBSD. From this progress i can say, that 
there is an active community. Many of the features (and bugfixes) came 
directly from the community.


I'm not for or against GitLab. I just wanted to point this out.

As mentioned in another Thread Bugzilla is used by LibreOffice and 
Linux. I want to add FreeBSD to the list.


Greetings,
Torsten



--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 29.09.2015 05:54, Tom Lane wrote:

Stephen Frost  writes:

* Jim Nasby (jim.na...@bluetreble.com) wrote:

2 years ago is when they first released the enterprise edition,
which according to [1] had "The most important new feature is that
you can now add members to groups of projects."



It needed a lot more than a single feature.


Just going to their primary web page, and noting that the first line gives
links to "Features" and "Pricing" (but not "Documentation"), and the
second line makes it clear that there's a big difference between the
"Community Edition" and the "Enterprise Edition", is already enough to
turn me off.  We've seen that model before (mysql...) and it doesn't bode
well in the long run.

Further poking shows no evidence of any decent email integration, to name
just one of the things that have been mentioned as requirements in this
thread.


That is a fair point. First steps into this direction are done with 
version 8.0. This was released a week ago.



On the other hand, they are big on LDAP logins, and even
two-factor authentication.  (We need this for an issue tracker that's
supposed to provide visibility and easier reporting to people outside the
project?)


Login methods are well supported. There are various login strategies 
supported.



And JIRA integration, which seems to be an anti-feature to some
on this thread.


It is not only JIRA. Jira is one of a long list. Many like the Jenkins 
integration to support CI for example.



And they'd sure love to be in charge of our code repo.


Mh - i'm not a native speaker. I didn't understand this line.


And the main, possibly only, metadata they can track about an issue is
"assignee" and "milestone".


Indeed - GitLab is *not* a bugtracker. It's an web based git repository 
manager. It also offers issue tracking, but this is not the main idea of 
GitLab. Therefore i doubt that its the best choice for the community, too.


Greetings,
Torsten



--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 25.09.2015 10:04, Albert Cervera i Areny wrote:

2015-09-25 9:57 GMT+02:00 Torsten Zuehlsdorff <mailingli...@toco-domains.de>:

On 24.09.2015 20:23, David Fetter wrote:


On Thu, Sep 24, 2015 at 12:10:07PM -0600, Ryan Pedela wrote:


Kam Lasater wrote:


I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.



Why not just use Github issues?



Is Github issues something we can run ourselves?

If not, it's a proprietary system which has a proprietor whose
existence even next month is not guaranteed, and whose interests are
not guaranteed to align with ours into an indefinite future.

In some very important sense, it does not matter what features a
system has if it isn't one we can control.  At a minimum, this means
we need to run it in its entirety on resources we control, and we need
to be able to patch any piece of it on our own say-so.


+ 1

Instead of Github maybe GitLab is a good choice. There is an open source
community edition you have the full control over. And it is used by more
than 100.000 organizations:

https://en.wikipedia.org/wiki/GitLab


Of course everyone has their own preferences. Just wanted to point you
to roundup [1].


You're right. Though GitLab is not my own preference, but i'm currently 
porting it to FreeBSD. ;) But it is a good choice if you like Github.


There is a greater list of tools to for source code hosting:
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities

Greetings,
Torsten


--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 24.09.2015 20:23, David Fetter wrote:

On Thu, Sep 24, 2015 at 12:10:07PM -0600, Ryan Pedela wrote:

Kam Lasater wrote:

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.


Why not just use Github issues?


Is Github issues something we can run ourselves?

If not, it's a proprietary system which has a proprietor whose
existence even next month is not guaranteed, and whose interests are
not guaranteed to align with ours into an indefinite future.

In some very important sense, it does not matter what features a
system has if it isn't one we can control.  At a minimum, this means
we need to run it in its entirety on resources we control, and we need
to be able to patch any piece of it on our own say-so.


+ 1

Instead of Github maybe GitLab is a good choice. There is an open source 
community edition you have the full control over. And it is used by more 
than 100.000 organizations:


https://en.wikipedia.org/wiki/GitLab

Greetings,
Torsten


--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 23.09.2015 20:43, Robert Haas wrote:

On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater  wrote:

Thanks for the suggestion. However, an issue tracker is not a
replacement for mailing list(s) and vice versa. They are both
necessary for success.


I venture to say that we are succeeding as it is, although of course
we might have more success if we did some things better, including
this.  However, as Stephen says, the problem with an issue tracker is
that, unless some person or persons committed to keep it up to date,
it would just fill up with crap. We have an issue tracker for database
server issues here at EnterpriseDB, and keeping it up to date is a ton
of work.  If nobody's volunteering to do that work in the PostgreSQL
community, an issue tracker is going to end up not being useful,
because it will just be wrong all the time.


I would volunteering to do that work if the community decides to get a 
bug tracker.


Greetings,
Torsten


--
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] No Issue Tracker - Say it Ain't So!

[Torsten Zuehlsdorff]

On 24.09.2015 01:33, Josh Berkus wrote:

On 09/23/2015 03:05 PM, Jim Nasby wrote:

On 9/23/15 3:12 PM, Thomas Kellerer wrote:

They also support Postgres as their backend (and you do find hints
here and
there
that it is the recommended open source DBMS for them - but they don't
explicitly state it like that). We are using Jira at the company I
work for
and
all Jira installations run on Postgres there.


I'll second Jira as well. It's the only issue tracker I've seen that you
can actually use for multiple different things without it becoming a
mess. IE: it could track Postgres bugs, infrastructure issues, and the
TODO list if we wanted, allow issues to reference each other
intelligently, yet still keep them as 3 separate bodies.


Speaking as someone who uses Jira for commericial work, I'm -1 on them.


Full ACK. -1 from me too.

Greetings,
Torsten


--
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] Commitfest problems

[Torsten Zuehlsdorff]

On 16.12.2014 08:33, David Rowley wrote:

On 16 December 2014 at 18:18, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.com wrote:

 Man. You're equating stuff that's not the same. You didn't get your way
 (and I'm tentatively on your side onthat one) and take that to imply
 that we don't want more reviewers.

During that thread a couple people said that novice reviewers added no
value to the review process, and nobody argued with them then.  I've
also been told this to my face at pgCon, and when I've tried organizing
patch review events.  I got the message, which is why I stopped trying
to get new reviewers.

And frankly: if we're opposed to giving credit to patch reviewers, we're
opposed to having them.



I'd just like to add something which might be flying below the radar of
more senior people. There are people out there  (ike me)  working on
PostgreSQL more for the challenge and perhaps the love of the product,
who make absolutely zero money out of it. For these people getting
credit where it's due is very important. I'm pretty happy with this at
the moment and I can't imagine any situation where not crediting
reviewers would be beneficial to anyone.


I want to focus this point a little more. I'm educate young people to 
become developers and i always try to encourage them to participate in 
open source projects for many reasons.


In my experience people are very different and one of the key arguments 
to make some becoming part of a community is the credit the can earn.
Finding their own name in the release-note of a known project is very 
good for the ego and one of their main motivations. This is especially 
import for *young* people.
Also its easy to argue that credits makes it easier to get a good job 
later. If you can write have a look at the release notes of $x, i make 
the feature you're using in your references of a application for 
employment this is a big plus for you.


People are very different, but there are some groups of motivations to 
address. For me its very unimportant if you name me or not. 10 years ago 
i would not have participate in anything without somebody stretching out 
this was my genius work :(


Apart of this social addressing problem i believe there are some other 
problems in the process of reviewing patches in the context of novice 
reviewers. I'm trying to write it in a separate note.


Greetings,
Torsten


--
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] Commitfest problems

[Torsten Zuehlsdorff]

On 17.12.2014 20:00, Stephen Frost wrote:

* Jaime Casanova (ja...@2ndquadrant.com) wrote:

On Tue, Dec 16, 2014 at 11:32 AM, Robert Haas robertmh...@gmail.com wrote:


It has been proposed that we do a general list of people at the bottom
of the release notes who helped review during that cycle.  That would
be less intrusive and possibly a good idea, but would we credit the
people who did a TON of reviewing?  Everyone who reviewed even one
patch?  Somewhere in between? Would committers be excluded because we
just expect them to help or included because credit is important to
established community members too?  To what extent would this be
duplicative of http://www.postgresql.org/community/contributors/ ?


Not much really, I tried to get my name on that list a couple of years
ago, when i reviewed more than i do now, and never got it.
And while my name is in a couple commit messages, that is a lot harder
to show to people...


Having your name in a list of other names at the bottom of the release
notes page, without any indication of what you helped with, would work
better?  Perhaps it would but I tend to doubt it.


Out of my personal experience in Germany: yes, it helps. It is not very 
logical, but many people need a simple way (Website against git log) 
to see something.


(I've rarely seen that something like that is considered not trustable 
even if there are strong indications that its faked.)


But i think it is a good point that the release notes should not become 
to big.



you know, it's kind of frustrating when some not-yet customers ask for
certificated engineers, and there isn't any official (as in from
community) certificate so you need to prove you're a contributor so
let's see this random commit messages...


Another thought I had was to suggest we consider *everyone* to be a
contributor and implement a way to tie together the mailing list
archives with the commit history and perhaps the commitfest app and make
it searchable and indexed on some website.  eg:

contributors.postgresql.org/sfrost
   - Recent commits
   - Recent commit mentions
   - Recent emails to any list
   - Recent commitfest app activity
   - Recent wiki page updates
 ...

Ideally with a way for individuals to upload a photo, provide a company
link, etc, similar to what the existing Major Contributors have today.
Obviously, this is not a small task to develop and there is some risk of
abuse (which I expect the other folks on the infra team will point out
and likely tar and feather me for suggesting this at all..) but it might
be along the same lines as Bruce's PgLife..


That's an interesting idea. I'm not convinced that this is the best 
solution, but i would help, if community thinks this should be implemented.


Greetings,
Torsten


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

[HACKERS] Missing IPv6 for pgbuildfarm.org

[Torsten Zuehlsdorff]

Hello,

i've tried to setup a FreeBSD 10 machine as buildfarm-member. But it's 
an IPv6 only machine and there is no IPv6 for the homepage.


Can anyone add support for IPv6 to it?

Greetings,
Torsten


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