Re: [HACKERS] Thoughts on unit testing?
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
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?
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?
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
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
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)
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
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]
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
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!
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!
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!
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!
On 25.09.2015 10:04, Albert Cervera i Areny wrote: 2015-09-25 9:57 GMT+02:00 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 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!
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!
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] No Issue Tracker - Say it Ain't So!
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] Commitfest problems
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 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
Re: [HACKERS] Commitfest problems
On 16.12.2014 08:33, David Rowley wrote: On 16 December 2014 at 18:18, Josh Berkus 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
[HACKERS] Missing IPv6 for pgbuildfarm.org
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