https://wiki.postgresql.org/api.php?action=feedcontributions&user=Jconway&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-29T14:46:58ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=Handling_Security_Issues&diff=38351Handling Security Issues2023-10-14T19:56:07Z<p>Jconway: /* Security team */</p>
<hr />
<div>This page contains information for developers on how to deal with security issues and how to prepare a security release.<br />
<br />
'''Note:''' If you are a user who wants to report a security issue or who wants to learn about how the PostgreSQL project deals with security issues, please go to http://www.postgresql.org/support/security. The wiki page you are looking at is aimed at developers.<br />
<br />
== security@postgresql.org ==<br />
<br />
The email address security@postgresql.org is the recommended contact point for all inquiries about security issues. It currently points at pgsql-security@postgresql.org.<br />
<br />
== Security team ==<br />
<br />
The security team is a closed-subscription list whose purpose is to be able to discuss security issues in a controlled group. The current members are:<br />
<br />
* Álvaro Herrera<br />
* Andres Freund<br />
* Andrew Dunstan<br />
* Bruce Momjian<br />
* Dave Page<br />
* Greg Stark<br />
* Heikki Linnakangas<br />
* Joe Conway<br />
* Jonathan Katz<br />
* Magnus Hagander<br />
* Michael Paquier<br />
* Noah Misch<br />
* Peter Eisentraut<br />
* Robert Haas<br />
* Stephen Frost<br />
* Stefan Kaltenbrunner<br />
* Tom Lane<br />
<br />
== Responding to security bug reports ==<br />
<br />
Respond to a security bug report reported via the security@ address in the same way as you would with a normal bug report on pgsql-bugs. The only difference is that the issue should not be disclosed to anyone outside the security team and the original reporter.<br />
<br />
== Committing patches for security issues ==<br />
<br />
If the git commit log message for a commit matches<br />
<br />
/^Security:/<br />
<br />
then the message on pgsql-committers will be held for moderation. This facility should be applied when committing a patch for a security issue, so that details of the fix don't get broadcast to the world before the release including the fix is made. See [http://archives.postgresql.org/pgsql-committers/2008-01/msg00100.php this example] for a commit message where this was done. As in that example, the recommended style is something like "Security: CVE-number" or some other reference to the reason for the security marker.<br />
<br />
== CVE numbers ==<br />
<br />
A CVE number should be requested for every security issue. This number should be included in all the commit messages, announcements, and so on. A document describing the process can be found on developer.postgresql.org at ~petere/can-request.txt (only available with shell access, because it is not a public document). The person who drives the process of fixing the issue and preparing the security release (often Tom Lane) is usually the one who deals with requesting the CVE numbers.<br />
<br />
[[Category:Development]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Committers&diff=38049Committers2023-07-12T01:15:58Z<p>Jconway: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
* David Rowley (drowley)<br />
* Daniel Gustafsson (d_gustafsson)<br />
* John Naylor (john.naylor)<br />
* Nathan Bossart (nathan)<br />
* Amit Langote (amitlan)<br />
* Masahiko Sawada (msawada)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PgCon_2023_Developer_Meeting&diff=37674PgCon 2023 Developer Meeting2023-03-21T13:56:20Z<p>Jconway: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 30 May, 2023 at the University of Ottawa, prior to pgCon 2023. In order to keep the numbers manageable, this meeting is by '''invitation only'''.<br />
Any questions regarding the invitations to this event should be directed to the team of individuals tasked with coming up with the list of people to invite:<br />
<br />
* Andres Freund<br />
* Stephen Frost<br />
* Dave Page<br />
<br />
An Unconference will be held on Friday for in-depth discussion of technical topics.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Define the schedule for the upcoming releases<br />
* Address any proposed timing, policy, or procedure issues<br />
* Receive updates from project sub-teams on their activities and discuss any resulting issues or concerns.<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
<br />
== Time & Location ==<br />
<br />
The meeting will (probably) be:<br />
<br />
* 9:00AM to 12PM<br />
* DMS 3105 - Desmarais Hall, 55 Laurier Avenue East<br />
* University of Ottawa.<br />
<br />
Lunch will be served during the meeting.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname). Note that we can accommodate a '''maximum of 30'''!<br />
<br />
# Joe Conway<br />
# Stephen Frost<br />
# Alexander Korotkov<br />
# Tom Lane<br />
# Dave Page<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
== Agenda Items ==<br />
<br />
* 16.0 release and commitfest schedule (Dave)<br />
* ''Please add suggestions for agenda items here. (with your name)''<br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave Page<br />
<br />
|- <br />
|09:10 - 09:20<br />
|Release and commitfest schedules<br />
|Dave Page<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- <br />
|11:50 - 12:00<br />
|Any other business<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:00<br />
|Lunch<br />
|<br />
<br />
|}<br />
<br />
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move materially however). Any remaining time before lunch may be used for Commitfest item triage or other activities.<br />
<br />
[[Category:Developer Meeting]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PgCon_2023_Developer_Meeting&diff=37673PgCon 2023 Developer Meeting2023-03-21T13:55:52Z<p>Jconway: </p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 30 May, 2023 at the University of Ottawa, prior to pgCon 2023. In order to keep the numbers manageable, this meeting is by '''invitation only'''.<br />
Any questions regarding the invitations to this event should be directed to the team of individuals tasked with coming up with the list of people to invite:<br />
<br />
* Andres Freund<br />
* Stephen Frost<br />
* Dave Page<br />
<br />
An Unconference will be held on Friday for in-depth discussion of technical topics.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Define the schedule for the upcoming releases<br />
* Address any proposed timing, policy, or procedure issues<br />
* Receive updates from project sub-teams on their activities and discuss any resulting issues or concerns.<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
<br />
== Time & Location ==<br />
<br />
The meeting will (probably) be:<br />
<br />
* 9:00AM to 12PM<br />
* DMS 3105 - Desmarais Hall, 55 Laurier Avenue East<br />
* University of Ottawa.<br />
<br />
Lunch will be served during the meeting.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname). Note that we can accommodate a '''maximum of 30'''!<br />
<br />
# Stephen Frost<br />
# Alexander Korotkov<br />
# Tom Lane<br />
# Dave Page<br />
# Joe Conway<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
== Agenda Items ==<br />
<br />
* 16.0 release and commitfest schedule (Dave)<br />
* ''Please add suggestions for agenda items here. (with your name)''<br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave Page<br />
<br />
|- <br />
|09:10 - 09:20<br />
|Release and commitfest schedules<br />
|Dave Page<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- <br />
|11:50 - 12:00<br />
|Any other business<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:00<br />
|Lunch<br />
|<br />
<br />
|}<br />
<br />
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move materially however). Any remaining time before lunch may be used for Commitfest item triage or other activities.<br />
<br />
[[Category:Developer Meeting]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Main_Page&diff=36879Main Page2022-05-05T12:08:44Z<p>Jconway: /* User Accounts */</p>
<hr />
<div>__NOTOC__<br />
{{Languages}}<br />
= Welcome to the PostgreSQL Wiki! =<br />
<br />
This wiki contains user documentation, how-tos, and tips 'n' tricks related to PostgreSQL. It also serves as a collaboration area for PostgreSQL contributors.<br />
<br />
== User Documentation ==<br />
* [[Frequently Asked Questions]]<br />
<br />
==== Community Generated Articles, Guides, and Documentation ====<br />
* [[Community Generated Articles, Guides, and Documentation|General articles and guides]]<br />
* [[PostgreSQL Tutorials]]<br />
* [[:Category:Snippets|PostgreSQL Related Code Snippets]]<br />
* [[Detailed installation guides]]<br />
* [[Converting from other Databases to PostgreSQL]]<br />
* [[Comparison with other Database systems]]<br />
* [[Database Administration and Maintenance]]<br />
* [[Development Articles|Development with PostgreSQL]]<br />
* [[Performance Optimization|PostgreSQL Performance Optimization]]<br />
* [[PostgreSQL Related Slides and Presentations]]<br />
<br />
==== Documentation on the main site ====<br />
* [http://www.postgresql.org/docs/manuals/ PostgreSQL Manuals] <br />
* [http://www.postgresql.org/docs/books/ PostgreSQL Books]<br />
<br />
== Alternate Languages ==<br />
<br />
The following pages contain user documentation in languages other than English.<br />
<br />
* [[Main Page/de|deutsch]]<br />
* [[Main Page/es|español]] <br />
* [[Main Page/fr|français]]<br />
* [[Main Page/he|עברית]]<br />
* [[Main Page/ja|日本語]]<br />
* [[Main Page/pt|português]]<br />
* [[Main Page/ru|русский]]<br />
* [[Main Page/zh|中文]]<br />
* [[Main Page/zh-hant|中文(繁體]]<br />
<br />
<br />
== Contributor Information ==<br />
* You can find many PostgreSQL users and developers chatting in [irc://irc.libera.chat/postgresql #postgresql on Libera]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].<br />
* [[Events | Upcoming Events]]<br />
* [[Development information]]<br />
* [[Advocacy]]<br />
<br />
== User Accounts ==<br />
* All activity on this site should follow the [[Policies|PostgreSQL Project Policies]]. <br />
* In order to edit or create documents on the site, you will need a [https://www.postgresql.org/account/login/ PostgreSQL community account]. This is the same account used when submitting news or events on [http://www.postgresql.org www.postgresql.org].<br />
'''NOTE: due to recent spam activity "editor" privileges are granted manually for the time being. If you just created a new community account or if your current account used to have "editor" privileges ask on either the [mailto:pgsql-www@postgresql.org PostgreSQL -www Mailinglist] or the [irc://irc.libera.chat/postgresql PostgreSQL IRC Channel] (direct your request to 'pginfra', multiple individuals in the channel highlight on that string) for help. Please include your community account name in those requests.</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36199Release process2021-06-22T21:10:02Z<p>Jconway: /* Tarball construction */</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure to mention the secret URL printed above. Something like:<br />
<br />
To: pgsql-packagers<br />
Subject: Postgres minor-release (or xbetaN) tarballs are up<br />
Body:<br />
<br />
... at<br />
https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
As usual, public announcement will be on Thursday.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
<br />
# optional, but a good idea to make sure you're not going to push any private tags<br />
git push -n --tags<br />
<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Building and making PDFs available ==<br />
Soon after tagging, PDFs need to be built and made available.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Building-and-making-PDFs-available here].<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the project's public servers.<br />
<br />
After that, publish the release announcement.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Actually-deploying-the-release here].</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36198Release process2021-06-22T21:09:41Z<p>Jconway: /* Tarball construction */</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure to mention the secret URL printed above. Something like:<br />
<br />
To: pgsql-packagers<br />
Subject: Postgres minor-release (or xbetaN) tarballs are up<br />
Body:<br />
<br />
... at<br />
https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
As usual, public announcement will be on Thursday.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
<br />
# optional, but a good idea to make sure you're not going to push any private tags<br />
git push -n --tags<br />
<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Building and making PDFs available ==<br />
Soon after tagging, PDFs need to be built and made available.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Building-and-making-PDFs-available here].<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the project's public servers.<br />
<br />
After that, publish the release announcement.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Actually-deploying-the-release here].</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36197Release process2021-06-22T19:47:19Z<p>Jconway: /* Final version tagging */</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure<br />
to mention the secret URL printed above.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
<br />
# optional, but a good idea to make sure you're not going to push any private tags<br />
git push -n --tags<br />
<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Building and making PDFs available ==<br />
Soon after tagging, PDFs need to be built and made available.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Building-and-making-PDFs-available here].<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the project's public servers.<br />
<br />
After that, publish the release announcement.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Actually-deploying-the-release here].</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36196Release process2021-06-22T19:45:03Z<p>Jconway: </p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure<br />
to mention the secret URL printed above.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
git push -n --tags # optional, but a good idea to make sure you're not going to push any private tags<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Building and making PDFs available ==<br />
Soon after tagging, PDFs need to be built and made available.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Building-and-making-PDFs-available here].<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the project's public servers.<br />
<br />
After that, publish the release announcement.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release#Actually-deploying-the-release here].</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36195Release process2021-06-22T19:42:33Z<p>Jconway: /* Release-day tasks */</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure<br />
to mention the secret URL printed above.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
git push -n --tags # optional, but a good idea to make sure you're not going to push any private tags<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the project's public servers.<br />
<br />
After that, publish the release announcement.<br />
<br />
The details for these steps are on Redmine [https://redmine.postgresql.org/projects/pgweb/wiki/Deploying_a_new_minor_release here].</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36191Release process2021-06-22T12:51:12Z<p>Jconway: /* Version stamping */</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp xbetaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure<br />
to mention the secret URL printed above.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
git push -n --tags # optional, but a good idea to make sure you're not going to push any private tags<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the<br />
project's public servers. (XXX details somebody?)<br />
<br />
After that, publish the release announcement (XXX details?)</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Release_process&diff=36187Release process2021-06-20T17:53:58Z<p>Jconway: Protected "Release process" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))</p>
<hr />
<div>This page documents the Postgres release-wrapping process. See src/tools/RELEASE_CHANGES for context, but this is meant to be a detailed checklist for whoever is wrapping tarballs.<br />
<br />
== Prerequisites ==<br />
<br />
* You must have the appropriate ''autoconf'' version installed for each Postgres branch you plan to wrap. For currently-supported branches, that's<br />
** 2.69 for PG 9.4 and up<br />
** 2.63 for PG 9.0 - 9.3<br />
To ensure we get the same results no matter who does version stamping, please use exactly the GNU-released autoconf versions; avoid distro-provided packages as they may contain assorted patches. Even if those patches are for the better, we don't want variation in our results. I tend to grab the GNU tarballs and tell them to install with<br />
./configure --prefix=/usr/local/autoconf-N.NN<br />
then put the appropriate /usr/local/autoconf-N.NN/bin into my PATH before stamping.<br />
<br />
== Before-wrap tasks ==<br />
<br />
* Update tzdata files if appropriate; see src/timezone/README.<br />
* Update release notes as appropriate.<br />
* Update translation files from the separate translation repository (XXX reference for this process?)<br />
<br />
It's best to not leave these things for the very last minute, so that we can get some buildfarm cycles verifying that nothing's horribly broken.<br />
<br />
== Version stamping ==<br />
<br />
This can be done by any committer, assuming the appropriate autoconf version is installed locally.<br />
The heavy lifting is all done by src/tools/version_stamp.pl, but in detail the process looks like this for each branch:<br />
<br />
git pull<br />
git checkout REL_x_STABLE<br />
src/tools/version_stamp.pl y<br />
run appropriate autoconf version<br />
run appropriate autoheader version # optional, shouldn't change anything if committers have been careful<br />
rm -rf autom4te.cache<br />
git diff # optional but good to check that nothing looks insane<br />
git commit -a -m "Stamp x.y." # or "Stamp x.betaN."<br />
git show # make a note of the commit hash, for use below<br />
git push<br />
<br />
version_stamp.pl will insist that ''y'' be a number or something else appropriate (such as ''beta2''), but it doesn't check further than that. The main thing I generally look for at the ''git diff'' step is that I correctly chose the next higher minor release number for this branch. Also, if you see anything except version-numbering-related diffs, it likely means that you or somebody else used an unapproved autoconf version; check closely before proceeding!<br />
<br />
Please follow exactly the commit message format shown above for version-stamping commits.<br />
<br />
== Tarball construction ==<br />
<br />
In principle this could be done anywhere, but again there's a concern about reproducibility, since the results may vary depending<br />
on installed bison, flex, docbook, etc versions. Current practice is to always do this as '''pgsql''' on '''borka.postgresql.org''', so it can only be done<br />
by people who have a login there. In detail:<br />
<br />
ssh borka.postgresql.org<br />
sudo -u pgsql -i<br />
<br />
mk-release commit-hash [ commit-hash ... ]<br />
<br />
where the ''commit-hashes'' are those of the stamping commits, or whatever you want to wrap on each branch.<br />
As indicated, you can specify multiple builds with one call of the script, and when releasing back branches that's the way to do it.<br />
Each tarball build takes 5-10 minutes, so go have a cup of coffee. When you come back, the built tarballs and checksum files<br />
will be in ~pgsql/output/.<br />
<br />
We generally restrict immediate access to the tarballs to members of the pgsql-packagers list, especially when security fixes are<br />
involved. Therefore, the next step is to select a random subdirectory name and put the new tarballs there:<br />
<br />
SUBDIR=`dd if=/dev/urandom count=1 bs=32 2>/dev/null | sha1sum | awk '{print $1}'`<br />
mkdir ~pgsql/staging/$SUBDIR<br />
mv ~pgsql/output/* ~pgsql/staging/$SUBDIR<br />
echo See https://borka.postgresql.org/staging/$SUBDIR/<br />
<br />
At this point, the files should be web-accessible at the URL printed by the last step.<br />
<br />
What I like to do next is download the tarballs to my own machine and diff them against my own git checkout, and do a spot check<br />
or two on the generated documentation. I don't recall that this has ever actually turned up a problem, but it gives me a warm fuzzy feeling.<br />
<br />
One way or another, once you are satisfied that the tarballs are OK, notify pgsql-packagers that the files are available, making sure<br />
to mention the secret URL printed above.<br />
<br />
== Final version tagging ==<br />
<br />
At this point we generally give the packagers at least 24 hours to verify that packages can be built from the tarballs. (And yes, they've<br />
found problems in the past.) In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump<br />
as seems appropriate.<br />
<br />
Whenever the dust seems reasonably well settled, publish tags into the Postgres git repo to mark which commit each release was actually<br />
built from. Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over:<br />
<br />
git tag REL_x_y commit-hash<br />
git push -n --tags # optional, but a good idea to make sure you're not going to push any private tags<br />
git push --tags<br />
<br />
Again, please follow past convention as to the exact formatting of the tag names. You can do this in your personal checkout, it doesn't need<br />
to be done on borka.<br />
<br />
== Release-day tasks ==<br />
<br />
When the announcement day arrives, the tarballs need to be copied from the staging directory on borka to appropriate places on the<br />
project's public servers. (XXX details somebody?)<br />
<br />
After that, publish the release announcement (XXX details?)</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Speaker_Bureau&diff=36054Speaker Bureau2021-05-25T13:04:08Z<p>Jconway: </p>
<hr />
<div>In order to help with the challenge of finding speakers for meetups please add your name to this page if you are willing to speak at a meetup. Currently (2021) the meetups will be virtual. '''At a minimum add your name, topic(s) and timezone'''. Feel free to add anything else you feel is relevant.<br />
<br />
For user group organizers who'd like to contact a speaker, please email the PgUS User Group Committee (ugcomm at PostgreSQL dot us), and we'll forward the request to the speaker. <br />
<br />
{| class="wikitable"<br />
|+ Speaker Bureau<br />
|-<br />
! style="width: 10em;" | Name !! Time zone !! style="width: 60em;" | Topics !! Mentor new speakers? !! Anything else you'd like us to know<br />
|-<br />
| Dave Cramer || EST || Java and Postgresql, Logical Decoding || Yes || <br />
|-<br />
| Joe Conway || EST || Security (variety of subtopics), Analytics (using PL/R, PostGIS, Python), Functions, Text Search and Pattern Matching, Shell Scripting with Postgres, Postgres Intro, Community and Development || Yes || <br />
|-<br />
| Jonathan Katz || EST || SCRAM, PostgreSQL + Kubernetes, PostgreSQL 13, Range Types + Applications, Building an App with a bunch of Postgres features (Logical decoding, CTEs, functions, range types, etc.), Data Types || || <br />
|-<br />
| Stephen Frost || || Security, PostgreSQL, other stuff || || <br />
|-<br />
| Keith Fiske || || Partitioning, Extensions, Administration, PG History & Features, Monitoring || || <br />
|-<br />
| David Christensen || || Replication, Bucardo, CTEs. || || <br />
|-<br />
| David Fetter || || PostgreSQL as a control plane, Fun with Foreign Data Wrappers, Hacking for Beginners || || <br />
|-<br />
| Jennifer Scheuerell || PST || Migrations, PostgreSQL and Django || Yes || <br />
|-<br />
| Harry Arroyo || || PostgreSQL with Laravel, Django, Java, IT Security Expert, TI Mentor, Sysadmin, FullStack Developer, Hacker, App Developer (Android and iOS), DBA and other Stuff || || <br />
|-<br />
| Jimmy Angelakos || GMT || PostgreSQL, performance, Full-Text Search, ETL with Python, Django || || <br />
|-<br />
| Tomas Vondra || CET || PostgreSQL, performance, various extensions, hacking, community stuff || || <br />
|-<br />
| Martín Marqués || Argentina || PostgreSQL, replication, backups, autovacuum || || <br />
|-<br />
| Andrew Dunstan || EST || PostgreSQL, vacuuming and freezing, Data Types, Foreign Data Wrappers, SSL, Pgbouncer || || <br />
|-<br />
| Nikhil Sontakke || India || PostgreSQL Architecture, Logical Decoding, BDR, PGLogical || || <br />
|-<br />
| Hari Kiran || India || PostgreSQL, Replication, Partitioning, Oracle Migration, Monitoring, DBA || || <br />
|-<br />
| Gianni Ciolli || GMT || Several topics, including: Physical/Logical Replication, Backup&restore, Query optimization, Database administration || || <br />
|-<br />
| Tom Kincaid || EST || High Availability, Deploying at Scale, MVCC, Partitioning, Performance Tuning || || <br />
|-<br />
| Muhammad Haroon || Pakistan || PostgreSQL, High Availability, Logical Replication, Vacuum/AutoVacuum, Database Administration, Extensions, Disaster Recovery || || <br />
|-<br />
| Álvaro Herrera || Chile || Postgres tuning, MVCC/vacuuming, Partitioning, Postgres hacking, community || || <br />
|-<br />
| Christophe Pettus || PST || Configuration and Tuning, Query Optimization, DBA Tasks and Mentoring, Disaster Recovery and Reliability Planning || || <br />
|-<br />
| Dave Page || GMT || pgAdmin, PostgreSQL project organisation/infrastructure || || <br />
|-<br />
| Boriss Mejías || CET || JSON, ENUM, replicationt || || <br />
|-<br />
| Pavan Deolasee || India || PostgreSQL Internals, Transaction Management, Performance, BDR || || <br />
|-<br />
| Euler Taveira || Sao Paulo || Logical Replication, Extensions, Tuning, Community || || <br />
|-<br />
| William Ivanski || || PostgreSQL, High Availability, BDR, Database Administration, Oracle Migration, Python || || <br />
|}</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGMembers&diff=36025PGFGMembers2021-05-21T13:49:15Z<p>Jconway: </p>
<hr />
<div>== Active PGFG Members ==<br />
<br />
{| cellpadding="5" cellspacing="0" border="1"<br />
!Name<br />
!Location<br />
!Role<br />
|-<br />
<br />
|Andreas Scherbaum<br />
| Germany<br />
|Member<br />
|-<br />
<br />
|Dave Cramer<br />
|Canada<br />
|Backup Liaison<br />
|-<br />
<br />
|Dave Page<br />
|U.K.<br />
|Member<br />
|-<br />
<br />
|David Fetter<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Devrim Gunduz<br />
|U.K.<br />
|Member<br />
|-<br />
<br />
|Granthana Biswas<br />
|Germany<br />
|Member<br />
|-<br />
<br />
|Greg Sabino Mullane<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Hans-Jürgen Schönig<br />
|Germany<br />
|Member<br />
|-<br />
<br />
|Joe Conway<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Jonathan Katz<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Lætitia Avrot<br />
|France<br />
|Member<br />
|-<br />
<br />
|Larry Rosenman<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Marc Fournier<br />
|Canada<br />
|Member<br />
|-<br />
<br />
|Mark Wong<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Michael Meskes<br />
|Germany<br />
|Member<br />
|-<br />
<br />
|Noah Misch<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Oleg Bartunov<br />
|Russian Fed.<br />
|Member<br />
|-<br />
<br />
|Peter Eisentraut<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Renee Phillips<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Robert Treat<br />
|U.S.A<br />
|Liaison<br />
|-<br />
<br />
|Valeria Kaplan<br />
|U.K.<br />
|Member<br />
|-<br />
<br />
|Vik Fearing<br />
|France<br />
|Member<br />
|-<br />
<br />
|}<br />
<br />
== Past PGFG Members ==<br />
<br />
{| cellpadding="5" cellspacing="0" border="1"<br />
!Name<br />
!Location<br />
!Role<br />
|-<br />
<br />
|A. Elein Mustain<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Andrew Sullivan<br />
|Canada<br />
|Member<br />
|-<br />
<br />
|Christopher Browne<br />
|Canada<br />
|Member<br />
|-<br />
<br />
|Gavin M. Roy<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Josh Berkus<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|Lamar Owen<br />
|U.S.A.<br />
|Member<br />
|-<br />
|Rod Taylor<br />
|Canada<br />
|Member<br />
|-<br />
|Tatsuo Ishii<br />
|Japan<br />
|Member<br />
|-<br />
<br />
|Joshua Drake<br />
|U.S.A.<br />
|Member<br />
|-<br />
<br />
|}<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=FOSDEM/PGDay_2020_Developer_Meeting&diff=34399FOSDEM/PGDay 2020 Developer Meeting2019-11-23T17:02:32Z<p>Jconway: /* Attendees */</p>
<hr />
<div>A meeting for PostgreSQL developers will be held in conjunction with the PostgreSQL Europe FOSDEM Devroom<br />
and FOSDEM/PGDay 2020 events in Brussels, Belgium. The meeting is planned for January 30. In order to keep the meeting focused, productive, and with a high level of interaction, the meeting is invite-only. Due to the large developer community, we cannot invite every active contributor. If you feel that you, or someone else, should've been invited then please contact [mailto:daniel@yesql.se Daniel Gustafsson].<br />
<br />
This is a Community event, organized and financed by PostgreSQL Europe.<br />
<br />
== Time and Location ==<br />
The meeting will be held at the [https://www3.hilton.com/en/hotels/brussels-capital-reg/hilton-brussels-grand-place-BRUGRHI/index.html Hilton Brussels Grand Place Hotel], which is the venue where [https://2020.fosdempgday.org/ FOSDEM PGDay 2020] is arranged the day after on January 31. The meeting starts at 9AM and is scheduled to end at 5PM. Coffee, tea and snacks will be provided during the day, as well as lunch.<br />
<br />
== Attendees ==<br />
The following hackers have RSVP'ed to the meeting and will be attending:<br />
* Daniel Gustafsson<br />
* Joe Conway<br />
<br />
== Suggested Topics ==<br />
Please add topics for discussion to the list:<br />
* CI build feedback/information directly in CF app (Daniel)<br />
* Commitfest triage<br />
<br />
== Agenda ==<br />
<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Daniel<br />
<br />
|- <br />
|09:10 - 09:20<br />
|TBD<br />
|All<br />
<br />
|- <br />
|09:20 - 09:40<br />
|TBD<br />
|All<br />
<br />
|- <br />
|09:40 - 10:00<br />
|TBD<br />
|All<br />
<br />
|- <br />
|10:00 - 10:20<br />
|TBD<br />
|All<br />
<br />
|- <br />
|10:20 - 10:30<br />
|TBD<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|<br />
<br />
|- <br />
|11:00 - 11:15<br />
|TBD<br />
|All<br />
<br />
|- <br />
|11:15 - 12:30<br />
|TBD<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch<br />
|<br />
<br />
|- <br />
|13:30 - 15:00<br />
|Commitfest Triage<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:00 - 15:30<br />
|Tea break<br />
|<br />
<br />
|- <br />
|15:30 - 16:45<br />
|Commitfest Triage<br />
|All<br />
<br />
<br />
|- <br />
|16:45 - 17:00<br />
|Any other business, plans for next year<br />
|Daniel<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
|<br />
|}</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGMembers&diff=34387PGFGMembers2019-11-20T14:26:44Z<p>Jconway: /* Active PGFG Members */</p>
<hr />
<div>== Active PGFG Members ==<br />
* Andreas Scherbaum Germany Member<br />
* Christopher Browne Canada Member<br />
* Dave Cramer Canada Backup Liaison<br />
* Dave Page U.K. Member<br />
* David Fetter U.S.A. Member<br />
* Devrim Gunduz Turkey Member<br />
* Greg Sabino Mullane U.S.A. Member<br />
* Hans-Jürgen Schönig Germany Member<br />
* Joe Conway U.S.A. Member<br />
* Jonathan Katz U.S.A. Member<br />
* Josh Berkus U.S.A. Member<br />
* Larry Rosenman U.S.A. Member<br />
* Marc Fournier Canada Member<br />
* Michael Meskes Germany Member<br />
* Noah Misch U.S.A. Member<br />
* Oleg Bartunov Russian Fed. Member<br />
* Peter Eisentraut Germany Member<br />
* Robert Treat U.S.A Liaison<br />
<br />
== Past PGFG Members ==<br />
* A. Elein Mustain U.S.A. Member<br />
* Andrew Sullivan Canada Member<br />
* Gavin M. Roy U.S.A. Member<br />
* Lamar Owen U.S.A. Member<br />
* Rod Taylor Canada Member<br />
* Tatsuo Ishii Japan Member<br />
* Joshua Drake U.S.A. Member<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PgCon_2019_Developer_Meeting&diff=33236PgCon 2019 Developer Meeting2019-04-08T11:51:44Z<p>Jconway: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 28 May, 2019 at the University of Ottawa, prior to pgCon 2019. In order to keep the numbers manageable, this meeting is by '''invitation only'''.<br />
<br />
The invitation list for the meeting has changed this year to include representatives from various project sub-teams, for example, packagers, the release team, Code of Conduct committee and more.<br />
<br />
As at last years event, an Unconference will be held on Wednesday for in-depth discussion of technical topics.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Define the schedule for the 13.0 release cycle<br />
* Address any proposed timing, policy, or procedure issues<br />
* Receive updates from project sub-teams on their activities and discuss any resulting issues or concerns.<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be:<br />
<br />
* 9:00AM to 12PM<br />
* DMS TBC<br />
* University of Ottawa.<br />
<br />
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be after the meeting.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname). Note that we can accommodate a '''maximum of 30'''!<br />
<br />
# Joe Conway<br />
# Magnus Hagander<br />
# Amit Kapila<br />
# Alexander Korotkov<br />
# Dave Page<br />
<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
* Christoph Berg<br />
* Andreas Scherbaum<br />
<br />
== Agenda Items ==<br />
<br />
* 13.0 release and commitfest schedule (Dave)<br />
<br />
* ''Please add suggestions for agenda items here. (with your name)''<br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:30<br />
|Welcome and introductions<br />
|Dave Page<br />
<br />
|- <br />
|09:30 - 09:45<br />
|12.0 release and commitfest schedule<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
|- <br />
|11:50 - 12:00<br />
|Any other business<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:00<br />
|Lunch<br />
|<br />
<br />
|}<br />
<br />
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move however). Any remaining time before lunch may be used for Commitfest item triage or other activities.</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGMembers&diff=33089PGFGMembers2019-02-23T18:57:15Z<p>Jconway: /* Active PGFG Members */</p>
<hr />
<div>== Active PGFG Members ==<br />
* Andreas Scherbaum Germany Member<br />
* Christopher Browne Canada Member<br />
* Dave Cramer Canada Backup Liaison<br />
* Dave Page U.K. Member<br />
* David Fetter U.S.A. Member<br />
* Devrim Gunduz Turkey Member<br />
* Greg Sabino Mullane U.S.A. Member<br />
* Hans-Jürgen Schönig Germany Member<br />
* Joe Conway U.S.A. Member<br />
* Jonathan Katz U.S.A. Member<br />
* Josh Berkus U.S.A. Member<br />
* Joshua Drake U.S.A. Member<br />
* Larry Rosenman U.S.A. Member<br />
* Marc Fournier Canada Member<br />
* Michael Meskes Germany Member<br />
* Oleg Bartunov Russian Fed. Member<br />
* Peter Eisentraut Germany Member<br />
* Robert Treat U.S.A Liaison<br />
<br />
== Past PGFG Members ==<br />
* A. Elein Mustain U.S.A. Member<br />
* Andrew Sullivan Canada Member<br />
* Gavin M. Roy U.S.A. Member<br />
* Lamar Owen U.S.A. Member<br />
* Rod Taylor Canada Member<br />
* Tatsuo Ishii Japan Member<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33079PGFGVotes2019-02-18T13:28:44Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
** Anything reasonably clear as to the vote is acceptable<br />
** Examples: yes/+1/aye/yea/affirmative, no/-1/nay,negative, abstain/0/pass<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Fund Requests<br />
* Fund requests must be for reimbursement of expenditures which generally fit within the [[Funding_Requests|funding request guidelines]]. <br />
* Fund requests less than or equal to $1000 USD may go through the following special process:<br />
** Any member may forward the request to the Funds Group mailing list, or the request might come directly to the list via moderation<br />
** If there are no objections, the Liaison may approve and fund the request after 72 hours<br />
** If there are any objections the request must be processed as any other motion, as discussed below<br />
* Fund requests greater than $1000 USD must be processed as any other motion, as discussed below<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded, unless a longer debate period was specifically requested as part of the motion (in no case shall debate be less than 72 hours)<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate, unless a longer voting period was specifically requested as part of the motion (in no case shall voting be less than 72 hours)<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33063PGFGVotes2019-02-17T18:53:24Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
** Anything reasonably clear as to the vote is acceptable<br />
** Examples: yes/+1/aye/yea/affirmative, no/-1/nay,negative, abstain/0/pass<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Fund Requests<br />
* Fund requests less than or equal to $2000 USD may go through the following special process:<br />
** Any member may forward the request to the Funds Group mailing list, or the request might come directly to the list via moderation<br />
** If there are no objections, the Liaison may approve and fund the request after 72 hours<br />
** If there are any objections the request must be processed as any other motion, as discussed below<br />
* Fund requests greater than $2000 USD must be processed as any other motion, as discussed below<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded, unless a longer debate period was specifically requested as part of the motion (in no case shall debate be less than 72 hours)<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate, unless a longer voting period was specifically requested as part of the motion (in no case shall voting be less than 72 hours)<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33062PGFGVotes2019-02-17T18:41:32Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
** Anything reasonably clear as to the vote is acceptable<br />
** Examples: yes/+1/aye/yea/affirmative, no/-1/nay,negative, abstain/0/pass<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Fund Requests<br />
* Fund requests less than or equal to $2000 USD may go through the following special process:<br />
** Any member may forward the request to the Funds Group mailing list, or the request might come directly to the list via moderation<br />
** If there are no objections, the Liaison may approve and fund the request after 72 hours<br />
* Fund requests greater than $2000 USD must be processed as any other motion, as discussed below<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded, unless a longer debate period was specifically requested as part of the motion (in no case shall debate be less than 72 hours)<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate, unless a longer voting period was specifically requested as part of the motion (in no case shall voting be less than 72 hours)<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33044PGFGVotes2019-02-10T12:28:46Z<p>Jconway: /* Methods */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
** Anything reasonably clear as to the vote is acceptable<br />
** Examples: yes/+1/aye/yea/affirmative, no/-1/nay,negative, abstain/0/pass<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded, unless a longer debate period was specifically requested as part of the motion (in no case shall debate be less than 72 hours)<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate, unless a longer voting period was specifically requested as part of the motion (in no case shall voting be less than 72 hours)<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33042PGFGVotes2019-02-09T14:53:32Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded, unless a longer debate period was specifically requested as part of the motion (in no case shall debate be less than 72 hours)<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate, unless a longer voting period was specifically requested as part of the motion (in no case shall voting be less than 72 hours)<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33041PGFGVotes2019-02-09T14:39:21Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger -- for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33040PGFGVotes2019-02-09T14:38:58Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger (for example, with 18 active members, (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 = 7, so the quorum is 7)<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33039PGFGVotes2019-02-09T14:37:01Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 5 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33038PGFGVotes2019-02-09T14:36:11Z<p>Jconway: /* Process */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 72 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 7 voting members, or (TRUNCATE(TRUNCATE(N/3)/2)*2) + 1 where N is the number of active members, whichever is larger<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain" -- votes of "abstain" are counted as participating for quorum purposes<br />
** Will remain open for 72 hours from the end of debate<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGCharter&diff=33036PGFGCharter2019-02-09T14:28:16Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
'''Governance Charter of the Relationship<br />
between the PostgreSQL project<br />
and Software in the Public Interest, Inc.'''<br />
<br />
== Core Team Membership ==<br />
The Core Team of the PostgreSQL project currently consists of the following people:<br />
Peter Eisentraut, Magnus Hagander, Tom Lane, Bruce Momjian, Dave Page. The Core Team appoints its own members.<br />
<br />
== Fundraising Group Membership ==<br />
The Fundraising Group (a.k.a. Funds Group) of the PostgreSQL project initially consisted of the members of The PostgreSQL Foundation Inc. that were active at the time of its termination. Thereafter, the Fundraising Group appoints its own members using the normal procedures for proposals and votes, as described below. The current membership is shown here: [[PGFGMembers|Fundraising Group members]]<br />
<br />
== Fundraising Group Elected Positions ==<br />
The Fundraising Group elects an SPI Liaison and an Deputy SPI Liaison. The appointments are subject to the veto of the Core<br />
Team. The appointments do not have an explicit duration, but either may be replaced at any time using the normal procedures for proposals and votes, as described below.<br />
<br />
The duty of the SPI Liaison is primarily to represent the interests and decisions of the Fundraising Group to SPI. Additionally the SPI Liaison will submit to SPI on an ongoing basis a list of persons eligible for automatic SPI contributing membership in recognition of their contributions to the PostgreSQL project.<br />
<br />
The duty of the Deputy SPI Liaison is to perform the duties of the SPI Liaison in the case that the SPI Liaison is unavailable for a non-trivial amount of time, or upon explicit request of the SPI Liaison or the Fundraising Group.<br />
<br />
== Proposals and Voting ==<br />
Proposals must be made explicitly via email on the Funds Group mailing list, and be seconded prior to discussion and voting.<br />
<br />
Decisions require discussion and voting in accordance with [[PGFGVotes|How the Fundraising Group votes]] in order to be valid.<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=33035Funding Requests2019-02-09T14:25:29Z<p>Jconway: /* Professional Services Funding */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Funding ==<br />
<br />
'''Types of fund requests:'''<br />
<br />
Examples of Fundraising Group fund requests:<br />
<br />
* Travel to technical conferences or tradeshows <br />
** We have provided funds to assist speakers of various PostgreSQL related conferences with their travel expenses<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request funding, send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking funds for<br />
* Total estimated amount of requested funds<br />
<br />
== What is considered for Funding approval ==<br />
<br />
* If requesting funds to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk under a FOSS or Creative Commons license<br />
<br />
* If requesting funds for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
<br />
* What is the benefit to the community?<br />
<br />
== Professional Services Funding ==<br />
<br />
Funding requests will be evaluated, if for professional services such as video editing, graphics design etc., according to the following (not necessarily complete) set of criteria:<br />
* What is the benefit to the community<br />
* At least one competitive bid<br />
** References for each vendor<br />
** Your recommendation for which vendor to select and why<br />
* Provide an estimate from the selected vendor in writing<br />
** The estimate should include exactly what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
<br />
We are *not* necessarily looking for the cheapest solution, but rather the overall *best* solution. We may be willing to pay more if a particular provider has a significantly superior track record (for example).<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=33034Funding Requests2019-02-09T14:25:10Z<p>Jconway: /* Professional Services Funding */</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Funding ==<br />
<br />
'''Types of fund requests:'''<br />
<br />
Examples of Fundraising Group fund requests:<br />
<br />
* Travel to technical conferences or tradeshows <br />
** We have provided funds to assist speakers of various PostgreSQL related conferences with their travel expenses<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request funding, send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking funds for<br />
* Total estimated amount of requested funds<br />
<br />
== What is considered for Funding approval ==<br />
<br />
* If requesting funds to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk under a FOSS or Creative Commons license<br />
<br />
* If requesting funds for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
<br />
* What is the benefit to the community?<br />
<br />
== Professional Services Funding ==<br />
<br />
Funding requests will be evaluated, if it is for professional services such as video editing, graphics design etc., according to the following (not necessarily complete) set of criteria:<br />
* What is the benefit to the community<br />
* At least one competitive bid<br />
** References for each vendor<br />
** Your recommendation for which vendor to select and why<br />
* Provide an estimate from the selected vendor in writing<br />
** The estimate should include exactly what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
<br />
We are *not* necessarily looking for the cheapest solution, but rather the overall *best* solution. We may be willing to pay more if a particular provider has a significantly superior track record (for example).<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=33033Funding Requests2019-02-09T14:22:19Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Funding ==<br />
<br />
'''Types of fund requests:'''<br />
<br />
Examples of Fundraising Group fund requests:<br />
<br />
* Travel to technical conferences or tradeshows <br />
** We have provided funds to assist speakers of various PostgreSQL related conferences with their travel expenses<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request funding, send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking funds for<br />
* Total estimated amount of requested funds<br />
<br />
== What is considered for Funding approval ==<br />
<br />
* If requesting funds to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk under a FOSS or Creative Commons license<br />
<br />
* If requesting funds for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
<br />
* What is the benefit to the community?<br />
<br />
== Professional Services Funding ==<br />
<br />
The below is how funding request will be evaluated if it is for professional services such as video editing, graphics design etc...<br />
* What is the benefit to the community<br />
* At least one competitive bid<br />
** References for each vendor<br />
** Your recommendation for which vendor to select and why<br />
* Provide an estimate from the selected vendor in writing<br />
** The estimate should include exactly what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
<br />
We are *not* necessarily looking for the cheapest solution, but rather the overall *best* solution. We may be willing to pay more if a particular provider has a significantly superior track record (for example).<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGMembers&diff=33032PGFGMembers2019-02-07T21:40:10Z<p>Jconway: Protected "PGFGMembers" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</p>
<hr />
<div>== Active PGFG Members ==<br />
* Andreas Scherbaum Germany Member<br />
* Christopher Browne Canada Member<br />
* Dave Cramer Canada Member<br />
* Dave Page U.K. Member<br />
* David Fetter U.S.A. Member<br />
* Devrim Gunduz Turkey Member<br />
* Greg Sabino Mullane U.S.A. Member<br />
* Hans-Jürgen Schönig Germany Member<br />
* Joe Conway U.S.A. Member<br />
* Jonathan Katz U.S.A. Member<br />
* Josh Berkus U.S.A. Member<br />
* Joshua Drake U.S.A. Member<br />
* Larry Rosenman U.S.A. Member<br />
* Marc Fournier Canada Member<br />
* Michael Meskes Germany Member<br />
* Oleg Bartunov Russian Fed. Member<br />
* Peter Eisentraut Germany Member<br />
* Robert Treat U.S.A Liaison<br />
<br />
== Past PGFG Members ==<br />
* A. Elein Mustain U.S.A. Member<br />
* Andrew Sullivan Canada Member<br />
* Gavin M. Roy U.S.A. Member<br />
* Lamar Owen U.S.A. Member<br />
* Rod Taylor Canada Member<br />
* Tatsuo Ishii Japan Member<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33031PGFGVotes2019-02-07T21:39:53Z<p>Jconway: Protected "PGFGVotes" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 48 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 7 voting members<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain". Votes of "abstain" are counted as participating for quorum purposes.<br />
** Will remain open for 72 hours from the end of debate.<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGCharter&diff=33030PGFGCharter2019-02-07T21:39:31Z<p>Jconway: Protected "PGFGCharter" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
'''Governance Charter of the Relationship<br />
between the PostgreSQL project<br />
and Software in the Public Interest, Inc.'''<br />
<br />
== Core Team Membership ==<br />
The Core Team of the PostgreSQL project currently consists of the following people:<br />
Peter Eisentraut, Magnus Hagander, Tom Lane, Bruce Momjian, Dave Page. The Core Team appoints its own members.<br />
<br />
== Fundraising Group Membership ==<br />
The Fundraising Group (a.k.a. Funds Group) of the PostgreSQL project initially consisted of the members of The PostgreSQL Foundation Inc. that were active at the time of its termination. Thereafter, the Fundraising Group appoints its own members using the normal procedures for proposals and votes, as described below. The current membership is shown here: [[PGFGMembers|Fundraising Group members]]<br />
<br />
== Fundraising Group Elected Positions ==<br />
The Fundraising Group elects an SPI Liaison and an Alternate SPI Liaison. The appointments are subject to the veto of the Core<br />
Team. The appointments do not have an explicit duration, but either may be replaced at any time using the normal procedures for proposals and votes, as described below.<br />
<br />
The duty of the SPI Liaison is primarily to represent the interests and decisions of the Fundraising Group to SPI. Additionally the SPI Liaison will submit to SPI on an ongoing basis a list of persons eligible for automatic SPI contributing membership in recognition of their contributions to the PostgreSQL project.<br />
<br />
The duty of the Alternate SPI Liaison is to perform the duties of the SPI Liaison in the case that the SPI Liaison is unavailable for a non-trivial amount of time, or upon explicit request of the SPI Liaison or the Fundraising Group.<br />
<br />
== Proposals and Voting ==<br />
Proposals must be made explicitly via email on the Funds Group mailing list, and be seconded prior to discussion and voting.<br />
<br />
Decisions require discussion and voting in accordance with [[PGFGVotes|How the Fundraising Group votes]] in order to be valid.<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33029PGFGVotes2019-02-07T20:40:59Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 48 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the Open Voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 7 voting members<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain". Votes of "abstain" are counted as participating for quorum purposes.<br />
** Will remain open for 72 hours from the end of debate.<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=33028PGFGVotes2019-02-07T20:35:33Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Motions and Votes ==<br />
<br />
=== Methods ===<br />
Votes may be collected using either of two methods:<br />
* Openly on the mailing list<br />
* Confidentially via private email to 2 selected members (Vote Collectors)<br />
<br />
=== Open Voting Details ===<br />
If the vote is determined to be done with the Open Voting method, all votes will be sent directly to the mailing list. Voting results should be summarized by the member making the motion once the voting period is closed. Any member can review the openly available votes for verification of the results.<br />
<br />
=== Confidential Voting Details ===<br />
If the vote is determined to be done with the Confidential Voting method, the member who makes the motion may propose the Vote Collectors. The Vote Collectors must agree to this responsibility. If they reject the request, other members must be selected until 2 are found which agree. If no members are specifically selected, the default Vote Collectors are the SPI Liaison and the Alternate SPI Liaison.<br />
* Members will send their ballot to both Vote Collectors using the email address subscribed to the Funds Group mailing list<br />
* Both Vote Collectors will tabulate the votes independently<br />
* Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote if possible.<br />
* Ballots are confidential. They may not be shared except by the Vote Collectors for verification purposes.<br />
* The Vote Collectors should post an email to the Funds Group mailing list no later then 24 hours before the end of the vote, listing who has voted, as a reminder to all to vote and notification those whose ballot may not have been received.<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
=== Process ===<br />
Funds Group members may submit a motion (a.k.a proposal, resolution), following these guidelines:<br />
* All current members of the Funds Group may submit a motion<br />
* Any other current member must second all motions<br />
* All current members of the Funds Group are eligible to vote<br />
* Debate:<br />
** Shall commence once the motion is seconded<br />
** Shall take place on the mailing list<br />
** Shall end no sooner than 48 hours after the motion was seconded<br />
** May be extended through a no-debate motion which is seconded and approved via the open voting method<br />
* Votes:<br />
** Shall take place on the mailing list or privately as discussed below<br />
** Quorum is 7 voting members<br />
** Determined by a simple majority vote, of the voting members<br />
** Allow the option to "abstain". Votes of "abstain" are counted as participating for quorum purposes.<br />
** Will remain open for 72 hours from the end of debate.<br />
* Method<br />
** The voting method may be determined by the member who makes the motion<br />
** If no voting method is thus determined, the vote takes place using the Open Voting method, on the mailing list<br />
** Only one method will be used per vote.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGCharter&diff=33027PGFGCharter2019-02-07T18:05:44Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
'''Governance Charter of the Relationship<br />
between the PostgreSQL project<br />
and Software in the Public Interest, Inc.'''<br />
<br />
== Core Team Membership ==<br />
The Core Team of the PostgreSQL project currently consists of the following people:<br />
Peter Eisentraut, Magnus Hagander, Tom Lane, Bruce Momjian, Dave Page. The Core Team appoints its own members.<br />
<br />
== Fundraising Group Membership ==<br />
The Fundraising Group (a.k.a. Funds Group) of the PostgreSQL project initially consisted of the members of The PostgreSQL Foundation Inc. that were active at the time of its termination. Thereafter, the Fundraising Group appoints its own members using the normal procedures for proposals and votes, as described below. The current membership is shown here: [[PGFGMembers|Fundraising Group members]]<br />
<br />
== Fundraising Group Elected Positions ==<br />
The Fundraising Group elects an SPI Liaison and an Alternate SPI Liaison. The appointments are subject to the veto of the Core<br />
Team. The appointments do not have an explicit duration, but either may be replaced at any time using the normal procedures for proposals and votes, as described below.<br />
<br />
The duty of the SPI Liaison is primarily to represent the interests and decisions of the Fundraising Group to SPI. Additionally the SPI Liaison will submit to SPI on an ongoing basis a list of persons eligible for automatic SPI contributing membership in recognition of their contributions to the PostgreSQL project.<br />
<br />
The duty of the Alternate SPI Liaison is to perform the duties of the SPI Liaison in the case that the SPI Liaison is unavailable for a non-trivial amount of time, or upon explicit request of the SPI Liaison or the Fundraising Group.<br />
<br />
== Proposals and Voting ==<br />
Proposals must be made explicitly via email on the Funds Group mailing list, and be seconded prior to discussion and voting.<br />
<br />
Decisions require discussion and voting in accordance with [[PGFGVotes|How the Fundraising Group votes]] in order to be valid.<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=33026Funding Requests2019-02-07T17:40:28Z<p>Jconway: </p>
<hr />
<div>== ''This page is currently undergoing significant revision and should be considered a DRAFT. Once finished and approved, this content will be permanently moving to www.postgresql.org'' ==<br />
<br />
== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Funding ==<br />
<br />
'''Types of fund requests:'''<br />
<br />
Examples of Fundraising Group fund requests:<br />
<br />
* Travel to technical conferences or tradeshows <br />
** We have provided funds to assist speakers of various PostgreSQL related conferences with their travel expenses<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request funding, send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking funds for<br />
* Total estimated amount of requested funds<br />
<br />
== What is considered for Funding approval ==<br />
<br />
* If requesting funds to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk under a FOSS or Creative Commons license<br />
<br />
* If requesting funds for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
<br />
* What is the benefit to the community?<br />
<br />
== Professional Services Funding ==<br />
<br />
The below is how funding request will be evaluated if it is for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include exactly what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* necessarily looking for the cheapest solution, but rather the overall *best* solution. We may be willing to pay more if a particular provider has a significantly superior track record (for example).<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Sponsorship&diff=33025Sponsorship2019-02-07T17:24:51Z<p>Jconway: Jconway moved page Sponsorship to Funding Requests: Confusingly named</p>
<hr />
<div>#REDIRECT [[Funding Requests]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=33024Funding Requests2019-02-07T17:24:51Z<p>Jconway: Jconway moved page Sponsorship to Funding Requests: Confusingly named</p>
<hr />
<div>== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Sponsorship ==<br />
<br />
'''Types of sponsorship:'''<br />
<br />
Examples of fundraising group sponsorship:<br />
<br />
* Travel to technical tradeshows <br />
** We have sponsored various speakers to various PostgreSQL related conferences<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request sponsorship send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking sponsorship for<br />
* Total estimated costs for sponsorship<br />
<br />
== What is considered for Sponsorship approval ==<br />
<br />
* If requesting sponsorship to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk as Foss or Creative Commons<br />
<br />
* If requesting sponsorship for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
*** Is it a PUG meeting, thus adding to the community as a whole?<br />
**** Will the talk from the PUG meeting be available as FOSS or Creative Commons<br />
<br />
* What is the benefit to the community?<br />
** Will there be other contributors present that can perform the same function?<br />
** Has the community shown an interest in extending whatever the task is?<br />
** Is there already an existing community sub project tasks with the process?<br />
<br />
== Professional Services sponsorship ==<br />
<br />
The below is how sponsorship will be determined if the sponsorship is going to be provided for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* looking for the cheapest solution. We are not the government. We are looking for TCO. That means we may be willing to pay more if the provider has a better track record (for example).<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=FOSDEM/PGDay_2019_Developer_Meeting&diff=32765FOSDEM/PGDay 2019 Developer Meeting2018-11-27T14:15:34Z<p>Jconway: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Thursday 31st January, 2019 at the Brussels Marriott Hotel, prior to FOSDEM/PGDay 2019. In order to keep the numbers manageable, this meeting is by '''invitation only'''. Unfortunately it is quite possible that we've overlooked important individuals during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (dpage@pgadmin.org).<br />
<br />
Please note that the attendee numbers have been kept low in order to keep the meeting more productive. Invitations have been sent only to developers that have been highly active on the database server over the 10 and 11 release cycles. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Review the progress of the 12.0 schedule, and formulate plans to address any issues<br />
* Address any proposed timing, policy, or procedure issues<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
* Commitfest Triage<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be:<br />
<br />
* 9:00AM to 5:00PM<br />
* Brussels Marriott Hotel<br />
<br />
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be provided.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname) and will be attending:<br />
<br />
* Joe Conway<br />
* Stephen Frost<br />
* Magnus Hagander<br />
* Thomas Munro<br />
* Dave Page<br />
* Tomas Vondra<br />
<br />
The following people have sent their apologies:<br />
<br />
* Peter Geoghegan<br />
* Kyotaro Horiguchi<br />
* Tatsuo Ishii<br />
* Amit Kapila<br />
* Jonathan Katz<br />
* Tom Lane<br />
* Noah Misch<br />
* Bruce Momjian<br />
* Craig Ringer<br />
* Simon Riggs, on holiday that week<br />
* Pavel Stehule<br />
<br />
==Agenda Items==<br />
<br />
Please add agenda items here!<br />
<br />
* <br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave<br />
<br />
|- <br />
|09:10 - 09:20<br />
|12.0 Release Review<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch<br />
|All<br />
<br />
|- <br />
|13:30 - 15:00<br />
|Commitfest Triage<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:00 - 15:30<br />
|Tea break<br />
|All<br />
<br />
|- <br />
|15:30 - 16:45<br />
|Commitfest Triage<br />
|All<br />
<br />
<br />
|- <br />
|16:45 - 17:00<br />
|Any other business<br />
|Dave<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
|<br />
|}<br />
<br />
== Minutes ==</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=32631Funding Requests2018-10-08T18:09:09Z<p>Jconway: /* Requesting Sponsorship */</p>
<hr />
<div>== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Sponsorship ==<br />
<br />
'''Types of sponsorship:'''<br />
<br />
Examples of fundraising group sponsorship:<br />
<br />
* Travel to technical tradeshows <br />
** We have sponsored various speakers to various PostgreSQL related conferences<br />
* SWAG (T-shirts, folders, flyers)<br />
* Cost of operations<br />
** PostgreSQL community infrastructure (for web, email, git, etc.)<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request sponsorship send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking sponsorship for<br />
* Total estimated costs for sponsorship<br />
<br />
== What is considered for Sponsorship approval ==<br />
<br />
* If requesting sponsorship to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk as Foss or Creative Commons<br />
<br />
* If requesting sponsorship for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
*** Is it a PUG meeting, thus adding to the community as a whole?<br />
**** Will the talk from the PUG meeting be available as FOSS or Creative Commons<br />
<br />
* What is the benefit to the community?<br />
** Will there be other contributors present that can perform the same function?<br />
** Has the community shown an interest in extending whatever the task is?<br />
** Is there already an existing community sub project tasks with the process?<br />
<br />
== Professional Services sponsorship ==<br />
<br />
The below is how sponsorship will be determined if the sponsorship is going to be provided for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* looking for the cheapest solution. We are not the government. We are looking for TCO. That means we may be willing to pay more if the provider has a better track record (for example).<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=SponsorShip&diff=32630SponsorShip2018-10-08T18:02:27Z<p>Jconway: Jconway moved page SponsorShip to Sponsorship: remove capitalization</p>
<hr />
<div>#REDIRECT [[Sponsorship]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=32629Funding Requests2018-10-08T18:02:27Z<p>Jconway: Jconway moved page SponsorShip to Sponsorship: remove capitalization</p>
<hr />
<div>== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Sponsorship ==<br />
<br />
'''Types of sponsorship:'''<br />
<br />
The fundraising group primarily sponsors the following:<br />
<br />
* Travel to technical tradeshows <br />
** We have sponsored various speakers to OSCON, PgCon, East, PHPDB, and various other shows<br />
* SWAG (Tshirts, folders, flyers)<br />
* Cost of operations<br />
** SPI has sponsored West and East (The bi-coastal PostgreSQL Community conferences)<br />
** PgDay.EU<br />
** OSCON PGDay expenses<br />
** LWE PGDay expenses<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request sponsorship send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking sponsorship for<br />
* Total estimated costs for sponsorship<br />
<br />
== What is considered for Sponsorship approval ==<br />
<br />
* If requesting sponsorship to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk as Foss or Creative Commons<br />
<br />
* If requesting sponsorship for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
*** Is it a PUG meeting, thus adding to the community as a whole?<br />
**** Will the talk from the PUG meeting be available as FOSS or Creative Commons<br />
<br />
* What is the benefit to the community?<br />
** Will there be other contributors present that can perform the same function?<br />
** Has the community shown an interest in extending whatever the task is?<br />
** Is there already an existing community sub project tasks with the process?<br />
<br />
== Professional Services sponsorship ==<br />
<br />
The below is how sponsorship will be determined if the sponsorship is going to be provided for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* looking for the cheapest solution. We are not the government. We are looking for TCO. That means we may be willing to pay more if the provider has a better track record (for example).<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=32628Funding Requests2018-10-08T18:01:05Z<p>Jconway: /* Requesting Sponsorship */</p>
<hr />
<div>== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Sponsorship ==<br />
<br />
'''Types of sponsorship:'''<br />
<br />
The fundraising group primarily sponsors the following:<br />
<br />
* Travel to technical tradeshows <br />
** We have sponsored various speakers to OSCON, PgCon, East, PHPDB, and various other shows<br />
* SWAG (Tshirts, folders, flyers)<br />
* Cost of operations<br />
** SPI has sponsored West and East (The bi-coastal PostgreSQL Community conferences)<br />
** PgDay.EU<br />
** OSCON PGDay expenses<br />
** LWE PGDay expenses<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request sponsorship send an email to funds-group <at> postgresql.org describing:'''<br />
<br />
* What you are seeking sponsorship for<br />
* Total estimated costs for sponsorship<br />
<br />
== What is considered for Sponsorship approval ==<br />
<br />
* If requesting sponsorship to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk as Foss or Creative Commons<br />
<br />
* If requesting sponsorship for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
*** Is it a PUG meeting, thus adding to the community as a whole?<br />
**** Will the talk from the PUG meeting be available as FOSS or Creative Commons<br />
<br />
* What is the benefit to the community?<br />
** Will there be other contributors present that can perform the same function?<br />
** Has the community shown an interest in extending whatever the task is?<br />
** Is there already an existing community sub project tasks with the process?<br />
<br />
== Professional Services sponsorship ==<br />
<br />
The below is how sponsorship will be determined if the sponsorship is going to be provided for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* looking for the cheapest solution. We are not the government. We are looking for TCO. That means we may be willing to pay more if the provider has a better track record (for example).<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=Funding_Requests&diff=32627Funding Requests2018-10-08T12:06:39Z<p>Jconway: </p>
<hr />
<div>== Sponsorship from the PostgreSQL.Org Fundraising Group ==<br />
<br />
[[PGFGCharter|The PostgreSQL SPI Charter]]<br />
<br />
[[PGFGVotes|How the Fundraising Group votes]]<br />
<br />
[[PGFGMembers|Fundraising Group members]]<br />
<br />
----<br />
<br />
== Requesting Sponsorship ==<br />
<br />
'''Types of sponsorship:'''<br />
<br />
The fundraising group primarily sponsors the following:<br />
<br />
* Travel to technical tradeshows <br />
** We have sponsored various speakers to OSCON, PgCon, East, PHPDB, and various other shows<br />
* SWAG (Tshirts, folders, flyers)<br />
* Cost of operations<br />
** SPI has sponsored West and East (The bi-coastal PostgreSQL Community conferences)<br />
** PgDay.EU<br />
** OSCON PGDay expenses<br />
** LWE PGDay expenses<br />
* Professional services (video editing, graphics)<br />
<br />
'''To request sponsorship send an email to jdrake <at> postgresql.org describing:'''<br />
<br />
* What you are seeking sponsorship for<br />
* Total estimated costs for sponsorship<br />
<br />
<br />
== What is considered for Sponsorship approval ==<br />
<br />
* If requesting sponsorship to provide a talk<br />
** Where the talk is being held<br />
** Expected attendance to the talk<br />
** Cost<br />
** Will you provide the talk as Foss or Creative Commons<br />
<br />
* If requesting sponsorship for an event<br />
** Are you charging for the event<br />
** Where are the proceeds going<br />
** What will the result of the event be?<br />
*** Is it a PUG meeting, thus adding to the community as a whole?<br />
**** Will the talk from the PUG meeting be available as FOSS or Creative Commons<br />
<br />
* What is the benefit to the community?<br />
** Will there be other contributors present that can perform the same function?<br />
** Has the community shown an interest in extending whatever the task is?<br />
** Is there already an existing community sub project tasks with the process?<br />
<br />
== Professional Services sponsorship ==<br />
<br />
The below is how sponsorship will be determined if the sponsorship is going to be provided for professional services such as video editing, graphics design etc...<br />
<br />
* Provide an estimate from the vendor in writing. <br />
** The estimate should include what will be provided<br />
** How much wiggle room we have (executive edits, moves, adds, changes)<br />
** When the services will be delivered <br />
** What the deliverable is<br />
* At least one competitive bid<br />
* References for each vendor<br />
* What is the benefit to the community<br />
* Your recommendation after receiving all materials.<br />
<br />
We are *not* looking for the cheapest solution. We are not the government. We are looking for TCO. That means we may be willing to pay more if the provider has a better track record (for example).<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGVotes&diff=32626PGFGVotes2018-10-08T11:26:46Z<p>Jconway: </p>
<hr />
<div>== Votes/Decisions ==<br />
<br />
The PostgreSQL fundraising group will typically decide matters via general consensus on our discussion list. However, should a matter be of enough concern group members may submit a motion and follow the guidelines as listed below.<br />
<br />
* All current members of the Fundraising Group are eligible to vote.<br />
* All current members of the Fundraising Group may submit a motion.<br />
* The chair is either the SPI Board Observer or the SPI Liason.<br />
* Deliberations shall occur once the motion is seconded.<br />
* Debate should take place in a new thread on the mailing list.<br />
* Debate should end no sooner than 3 days after the question has been stated by the chair.<br />
* Deliberations may be closed at the chair's discretion should the debate appear completed.<br />
* Resolutions shall be adopted by a simple majority vote.<br />
<br />
* Votes may be collected in either of two ways. The voting method may be determined by the member who makes the motion. If no voting method is thus determined, the chair must specify a method before the vote is opened. Only one method will be used per vote.<br />
<br />
* The possible voting methods are: Email Members will send their ballot to both the Liason and Observer using the email address subscribed to the Funds mailing list. Both Liason and observer will tabulate the votes independently. Votes which do not appear on both lists will be discarded after contacting the member involved to allow them to re-vote. Although not required, email voting should utilize use PGP to sign the vote. Web Members will log in and vote on an authenticated web interface.<br />
<br />
* A web vote is required should the vote pertain to one of the following:<br />
<br />
1. The appointment of a Fundraising Group representative.<br />
2. The removal of a Fundraising Group representative from their position.<br />
3. The chair determines that the vote is one of a controversial or sensitive nature.<br />
<br />
<br />
* Both voting methods will allow the option to "abstain". Members may abstain either by submitting a ballot indicating the abstention, or by not submitting a ballot. Votes of "abstain" are counted as participating only.<br />
<br />
* Voting will remain open for 7 days.<br />
<br />
* Ballots are confidential. They may not be shared except by the Liason and Board Advisor for verification purposes.<br />
<br />
* The Liason or Observer should post an email to the Funds mailing list no later then 48 hours before the end of the vote, listing who has voted as a reminder to all to vote and those whose ballot may not have been received.<br />
<br />
* The vote results should be posted to the mailing list within 24 hours of the vote closing.<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGMembers&diff=32625PGFGMembers2018-10-08T11:26:25Z<p>Jconway: </p>
<hr />
<div>== Active PGFG Members ==<br />
* Andreas Scherbaum Germany Member<br />
* Christopher Browne Canada Member<br />
* Dave Cramer Canada Member<br />
* Dave Page U.K. Member<br />
* David Fetter U.S.A. Member<br />
* Devrim Gunduz Turkey Member<br />
* Greg Sabino Mullane U.S.A. Member<br />
* Hans-Jürgen Schönig Germany Member<br />
* Joe Conway U.S.A. Member<br />
* Jonathan Katz U.S.A. Member<br />
* Josh Berkus U.S.A. Member<br />
* Joshua Drake U.S.A. Liason<br />
* Larry Rosenman U.S.A. Member<br />
* Marc Fournier Canada Member<br />
* Michael Meskes Germany Member<br />
* Oleg Bartunov Russian Fed. Member<br />
* Peter Eisentraut Germany Member<br />
* Robert Treat U.S.A Board Observer<br />
<br />
== Past PGFG Members ==<br />
* A. Elein Mustain U.S.A. Member<br />
* Andrew Sullivan Canada Member<br />
* Gavin M. Roy U.S.A. Member<br />
* Lamar Owen U.S.A. Member<br />
* Rod Taylor Canada Member<br />
* Tatsuo Ishii Japan Member<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=PGFGCharter&diff=32624PGFGCharter2018-10-08T11:25:55Z<p>Jconway: </p>
<hr />
<div> '''Governance Charter of the Relationship<br />
between the PostgreSQL project<br />
and Software in the Public Interest, Inc.'''<br />
<br />
The Core Team of the PostgreSQL project currently consists of the following people:<br />
Peter Eisentraut, Magnus Hagander, Tom Lane, Bruce Momjian, Dave Page. The Core Team appoints its own members.<br />
<br />
The Fundraising Group of the PostgreSQL project initially consists of the members of<br />
The PostgreSQL Foundation Inc. at the time of its termination. Thereafter, the<br />
Fundraising Group appoints its own members.<br />
<br />
The Fundraising Group elects the SPI Project Liason and the SPI Board Observer.<br />
These may be the same person. The appointments are subject to the veto of the Core<br />
Team. The appointments may be replaced by voting on new representatives at any time.<br />
The SPI Board Observer will submit to SPI on an ongoing basis a list of persons eligible<br />
for automatic SPI contributing membership in recognition of their contributions to the<br />
PostgreSQL project.<br />
<br />
Unless specified otherwise, decisions require a majority of votes.<br />
<br />
<br />
[[Category:PGFG]]<br />
[[Category:Funds]]<br />
[[Category:Donations]]</div>Jconwayhttps://wiki.postgresql.org/index.php?title=GCI_2018&diff=32559GCI 20182018-09-20T16:37:26Z<p>Jconway: /* Regarding Project Ideas */</p>
<hr />
<div>This page is for listing tasks and collecting ideas for the yearly Google Code-in contests. <br />
<br />
https://codein.withgoogle.com/<br />
<br />
https://developers.google.com/open-source/gci/how-it-works<br />
<br />
== Governance == <br />
<br />
=== Google Task Description ===<br />
<br />
A task is a small project that is expected to take between 3-5 hours of work to complete. Tasks are categorized with the following labels:<br />
<br />
* Code: Tasks related to writing or refactoring code<br />
* Documentation/Training: Tasks related to creating/editing documents and helping others learn more<br />
* Outreach/Research: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions<br />
* Quality Assurance: Tasks related to testing and ensuring code is of high quality<br />
* Design: Tasks related to user experience research or user interface design and interaction<br />
<br />
=== Regarding Project Ideas ===<br />
<br />
Project ideas are to be added below by community members.<br />
<br />
'''NOTE:''' Google looks for the following for each task:<br />
<br />
* A mix of tasks across multiple categories. (Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface)<br />
* Tasks of appropriate scope, length, and complexity.<br />
* Fully fleshed out descriptions with enough information to get started on.<br />
* Clear and understandable descriptions and titles.<br />
* Appropriate tags for searchability.<br />
<br />
Please add new sections following this format.<br />
<br />
=== Mentors (2018) ===<br />
<br />
The following individuals have been listed as possible mentors on the below projects, and/or offered to be mentors for student-proposed projects:<br />
<br />
* Renee Phillips<br />
* Corey Huinker<br />
* Lætitia Avrot<br />
* Stephen Frost<br />
* Sarah Conway<br />
* Vik Fearing<br />
* Evan Macbeth<br />
* Keith Fiske<br />
* Sunveer Singh<br />
<br />
== Tasks ==<br />
===Give a Local Presentation===<br />
<br />
=====Task Description=====<br />
<br />
PostgreSQL is a rapidly growing open source database, but one area that needs improvement is reaching outside of the internal community to the external open-source world to educate others about PostgreSQL and help them get started. Because of that, we can use your help to present a talk focused on PostgreSQL to an audience of your choosing. Examples would include local technology groups, technology user groups, a school, or clubs in your area. Some potential audiences can be found through Meetup: http://meetup.com/. The length of the talk can vary from a 5 minute lightning talk to a 30-60 minute long presentation or tutorial. <br />
<br />
The expected work to be uploaded will be a PDF version of the slides used during the presentation.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Research<br />
* Presentation<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Outreach/Research<br />
<br />
===Create an Educational Video===<br />
<br />
=====Task Description=====<br />
<br />
More online resources are always helpful for those learning PostgreSQL. Create a video demonstration illustrating a topic of your choosing in PostgreSQL; some examples would include a beginners introduction and history of PostgreSQL, how to get started in PostgreSQL, how to perform load balancing and high availability in a PostgreSQL cluster, how to run PostgreSQL within a Kubernetes or OpenShift environment, different monitoring statistics for your cluster, and so on.<br />
<br />
The video should be between 5-15 minutes, and must be your original work. <br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Video<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Developing a Lesson Plan===<br />
<br />
=====Task Description=====<br />
<br />
A major priority of the PostgreSQL organization is to expand awareness and education of PostgreSQL throughout the world, in a diverse and inclusive manner. One of our goals is to educate all groups, ranging from middle school, high school, and college students to adults from all ages and backgrounds, of open source technology and PostgreSQL.<br />
<br />
The expected outcome of this task is to draft sample training materials and a lesson plan for a younger age group (ranging from kids to teenagers) on getting started with PostgreSQL. It should be fun and engaging, with interactive tasks for hands-on learning. This can be submitted in any format, ranging from slides to a document-based format. The lesson plan should be prefaced with the intended audience, the difficulty level, and the estimated amount of time to complete the training. <br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Research<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Outreach/Research<br />
<br />
===Design a Logo for a Conference===<br />
<br />
=====Task Description=====<br />
<br />
PostgreSQL has several conferences that revolve around educating and discussing PostgreSQL within the community. One of these conferences, Postgres Open SV 2019, is in need of a new, updated, and high-resolution logo for next year's conference. The website from 2018 with the currently existing logo can be found here:<br />
<br />
https://2018.postgresopen.org/<br />
<br />
The requirements are as follows:<br />
<br />
1) Submissions should be high-resolution (PNG or SVG) and should include a source file.<br />
<br />
2) The logo should resonate well with the current website design, as next year's design will be similar to the existing.<br />
<br />
3) While it does not need to resemble the current logo, it does need to center around an elephant as the theme. The reasoning for this is the official logo for PostgreSQL itself is an elephant: https://www.postgresql.org/media/img/about/press/elephant.png<br />
<br />
4) Provide a brief summary of your logic behind the design of the logo and your approach.<br />
<br />
=====Tags=====<br />
<br />
* User Interface<br />
* Graphics<br />
* Design<br />
* Logo<br />
<br />
=====Categories=====<br />
<br />
User Interface<br />
<br />
===Reviewing Patches===<br />
<br />
=====Task Description=====<br />
<br />
PostgreSQL development revolves around [[CommitFest]] periods where any and all volunteers are needed to assist in reviewing proposed patches. Your task would be to select an open patch, evaluate it, and ensure it does what the author intends. <br />
<br />
Please demonstrate your testing process and include screenshots of the steps taken, along with the proof that it is working, in a document that will be submitted for evaluation as proof of completing the task.<br />
<br />
More information can be found here:<br />
<br />
https://wiki.postgresql.org/wiki/Reviewing_a_Patch<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* SQL<br />
* Databases<br />
* C<br />
* C-language<br />
<br />
=====Categories=====<br />
<br />
Quality Assurance<br />
<br />
Code<br />
<br />
===Improve PostgreSQL Regression Test Coverage===<br />
<br />
=====Task Description=====<br />
<br />
PostgreSQL can use additional development in the area of regression tests. Regression testing ensures that within PostgreSQL, new changes and additions aren't breaking existing functionality. Your task will be to introduce new regression tests for command line utilities and extensions that are poorly covered, as shown on https://coverage.postgresql.org/. <br />
<br />
The current regression test coverage for PostgreSQL isn't great, to the point where some areas of the code are covered only at single-digit-percent levels.<br />
<br />
Having good regression tests for such an important project as PostgreSQL is really key to minimizing the chance that any regressions are introduced. PostgreSQL's build system includes a "make coverage-html" to generate the report.<br />
<br />
Please note that this project involves writing SQL code and Perl code, at a minimum, to implement the tests necessary to increase the code coverage of the PostgreSQL regression tests.<br />
<br />
More information can be found in the [https://www.postgresql.org/docs/10/static/regress.html official documentation] on regression tasks.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* SQL<br />
* Perl<br />
* Databases<br />
* C<br />
* C-language<br />
* Development<br />
<br />
=====Categories=====<br />
<br />
Quality Assurance<br />
<br />
Code<br />
<br />
===pgAdmin 4 Bug - Setting up SMTP with Docker===<br />
<br />
=====Task Description=====<br />
<br />
There is no currently existing documentation for setting up SMTP when running the official Docker image for pgAdmin 4. Without SMTP, users cannot change their password or use the "forgot password" option. The expected outcome from this task would be to determine how to configure SMTP with the Docker container and write up documentation illustrating the steps. <br />
<br />
A requirement would be to create a PostgreSQL community account. The resulting documentation would be sent in to the pgadmin4-hackers mailing list for review, and uploaded as a file for proof of completion. https://www.postgresql.org/list/pgadmin-hackers/<br />
<br />
The original bug report can be found here: https://redmine.postgresql.org/issues/3599<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* SQL<br />
* Databases<br />
* Development<br />
* Documentation<br />
<br />
=====Categories=====<br />
<br />
Quality Assurance<br />
<br />
Code<br />
<br />
Documentation / Training<br />
<br />
===PostGIS Bug - Windows Installer===<br />
<br />
=====Task Description=====<br />
<br />
When installing PostGIS on Microsoft Windows, the installer shows a "Database Connection Information" dialog to supply User Name, Password, and Port. The installer will begin to install PostGIS, however, if there is a mistake in the connection information, the installer fails part-way in, requiring it to be run again from the beginning.<br />
<br />
It would be nice to allow multiple attempts to correct the connection information, if say, there was a typo with the password. This way the installer only needs to be run once (for example, using Application Stack Builder, which downloads the installer to %TEMP%).<br />
<br />
Not only should the connection info establish a connection to a database, but select count(*)=1 from pg_user where usename=$1 and usecreatedb;. If there is an error, the user should be able to go back and correct, try again, repeat or cancel. Correct connection info should be established before starting the install process.<br />
<br />
A requirement would be to create a PostgreSQL community account. The resulting documentation would be sent in to the postgis-devel mailing list for review, and uploaded as a file for proof of completion. https://lists.osgeo.org/mailman/listinfo/postgis-devel<br />
<br />
The original bug report can be found here: https://trac.osgeo.org/postgis/ticket/516<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* Authentication<br />
* SQL<br />
* Databases<br />
* Development<br />
* Documentation<br />
<br />
=====Categories=====<br />
<br />
Quality Assurance<br />
<br />
Code<br />
<br />
Documentation / Training<br />
<br />
===Learn about pgsql-bugs===<br />
<br />
=====Task Description=====<br />
<br />
The purpose of this task is to introduce you to community involvement and participation. <br />
<br />
Please review the pgsql-bugs mailing list archives, located [https://www.postgresql.org/list/pgsql-bugs/ here], and look for recently reported bugs. Your task will be to pick a recently reported issue and recreate it on your own system. <br />
<br />
The expected submission for this task will be a link to the mailing list archive for the relevant thread and a screenshot of the reproduced problem on your machine, showing the problem reported by the original user. Please additionally include the operating system and version of PostgreSQL you are running, in addition to the steps taken to reproduce the original issue.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* Quality Assurance<br />
* SQL<br />
* Databases<br />
* Development<br />
* Testing<br />
<br />
=====Categories=====<br />
<br />
Quality AssuranceParticipate in Mailing Lists<br />
<br />
Code<br />
<br />
===Learn about pgsql-performance===<br />
<br />
=====Task Description=====<br />
<br />
The purpose of this task is to introduce you to community involvement and participation. <br />
<br />
Please review the pgsql-performance mailing list archives, located [https://www.postgresql.org/list/pgsql-performance/ here], and look for recently reported bugs. Your task will be to pick a recently reported issue and recreate it on your own system. <br />
<br />
The expected submission for this task will be a link to the mailing list archive for the relevant thread and a screenshot of the reproduced problem on your machine, showing the problem reported by the original user. Please additionally include the operating system and version of PostgreSQL you are running, in addition to the steps taken to reproduce the original issue.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Review<br />
* Bug fixing<br />
* Patch<br />
* Quality Assurance<br />
* SQL<br />
* Databases<br />
* Development<br />
* Testing<br />
<br />
=====Categories=====<br />
<br />
Quality Assurance<br />
<br />
Code<br />
<br />
===PostgreSQL US - Develop an Integrated Form===<br />
<br />
=====Task Description=====<br />
<br />
The United States PostgreSQL Association, affectionately known as PgUS, is a IRS 501(c)(3) non-profit public charity that has the intention of supporting the growth and education of PostgreSQL, The World's Most Advanced Open Source Database, throughout the United States. <br />
<br />
Your task will be to fork the [https://github.com/pg-us/pgusweb official repository] hosting the PostgreSQL US website and propose a patch / pull request that integrates the currently existing Diversity Scholarship form hosted [https://docs.google.com/forms/d/1dgFUVXHgJ0sLAETJaAciLFetvFq5_S0-juZ3g8QyeVc/edit?ts=58f14198 on Google Forms] into a web page of its own.<br />
<br />
A further description of the Diversity Scholarship and its purpose can be found [https://postgresql.us/diversity/ here].<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Design<br />
* User Interface<br />
* HTML<br />
* CSS<br />
* Bootstrap<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
User Interface<br />
<br />
===PostgreSQL US - Develop a Resolution Tracker===<br />
<br />
=====Task Description=====<br />
<br />
The United States PostgreSQL Association, affectionately known as PgUS, is a IRS 501(c)(3) non-profit public charity that has the intention of supporting the growth and education of PostgreSQL, The World's Most Advanced Open Source Database, throughout the United States. <br />
<br />
Your task will be to fork the [https://github.com/pg-us/pgusweb official repository] hosting the [https://postgresql.us/ PostgreSQL US website] and propose a patch / pull request that contains a form in which board members can record resolutions in addition to information relating to who voted on the resolution, what the resolution is along with a description, and what the resulting votes are.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* Design<br />
* User Interface<br />
* HTML<br />
* CSS<br />
* Bootstrap<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
User Interface<br />
<br />
===PostgreSQL US - Draft a new Website Design===<br />
<br />
=====Task Description=====<br />
<br />
The United States PostgreSQL Association, affectionately known as PgUS, is a IRS 501(c)(3) non-profit public charity that has the intention of supporting the growth and education of PostgreSQL, The World's Most Advanced Open Source Database, throughout the United States. <br />
<br />
The [https://postgresql.us/ official website] could use a design refresh. Your task will be to redesign one front page and one side page in Photoshop, GIMP, or some other such editing software. <br />
<br />
The requirements for the submission will be as follows:<br />
<br />
1) There should be high resolution images attached for each page (SVG, PNG, or PDF). <br />
<br />
2) Additional designs should be created for both the tablet and mobile views of the website, for both the front page and the chosen side page.<br />
<br />
3) The design should incorporate elephants in some way, in addition to using the hex color #336791 in the general color scheme. It does not need to be the primary color.<br />
<br />
4) Provide a brief summary of your logic behind the design of the webpages and your approach.<br />
<br />
=====Tags=====<br />
<br />
* User Interface<br />
* Graphics<br />
* Design<br />
* Logo<br />
* Frontend<br />
<br />
=====Categories=====<br />
<br />
User Interface<br />
<br />
===Enhancing amcheck for all AMs===<br />
<br />
=====Task Description=====<br />
<br />
Amcheck is a PostgreSQL extension to verify the integrity of index against invariants that should always hold in the valid index. This tool is designed to diagnose corruption and help developers during the implementation of new features in access methods. Currently, amcheck supports only B-tree. Also, work on GiST is in progress https://github.com/petergeoghegan/amcheck/pull/11<br />
But amcheck could be used for many other indexes: GIN, SP-GiST, BRIN, RUM.<br />
For each AM it is necessary to deduce invariants to check, implement this checks and test against various index states.<br />
Also, it would be useful to unite all AM check methods in a single entry point for checking index.<br />
The interface of check functions can also be enhanced in favor of more detailed corruption information. It would be useful to model various corruptions, including both those which can be found by data_checksums and those which cannot.<br />
<br />
The project requires a good grasp of algorithms behind very sophisticated data structures, along with concurrency and recovery over them.<br />
<br />
The expected outcome would be to introduce support for a major PostgreSQL AM in amcheck as a proposed patch.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* C<br />
* C-language<br />
* SQL<br />
* Programming<br />
* Algorithms<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
===Interview PostgreSQL Contributors===<br />
<br />
=====Task Description=====<br />
<br />
The purpose of this task would be for you to reach out to various PostgreSQL community contributors and perform a remote interview with one or more contributors. Some example questions could include:<br />
<br />
* how they got started with PostgreSQL<br />
* what they enjoy most about working with PostgreSQL<br />
* how they got involved in the community<br />
* what challenges are involved<br />
* how the community has evolved over time and where it is headed<br />
* what their advice is to someone looking to begin learning about PostgreSQL or contribute to the project<br />
<br />
and so on. <br />
<br />
The ultimate goal would be to develop a blogpost based on the interview that could be published through [https://planet.postgresql.org/ Planet PostgreSQL]. The result would be uploaded as a text file or PDF.<br />
<br />
The list of community contributors can be found [https://www.postgresql.org/community/contributors/ here].<br />
<br />
<br />
=====Tags=====<br />
<br />
* Blogpost<br />
* Outreach<br />
* Research<br />
* Interview<br />
* Writing<br />
<br />
=====Categories=====<br />
<br />
Outreach / Research<br />
<br />
===Review and improve the "Getting Started" tutorial in the PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a set of existing tutorials, one of which is "Getting Started". Attempt to follow this tutorial to install PostgreSQL, create a PostgreSQL database and then access that database. Make notes of issues trying to follow the tutorial, areas where the tutorial lacks specific information to be able to accomplish the task, places where the tutorial doesn't provide information about how to tell if a given step was successful or not, and other items which could be improved.<br />
<br />
Using these notes, make changes to the PostgreSQL tutorial in its source format to address the deficiencies and submit these changes as patches to the PostgreSQL source tree so that they can be included in PostgreSQL in the future. These changes must be able to be patched to the PostgreSQL source code and the resulting changes built using the PostgreSQL build tool-chain.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Review and improve the "SQL Language" tutorial in the PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a set of existing tutorials, one of which is "SQL Language". Attempt to follow this tutorial, after installing PostgreSQL and creating a database, to use and learn SQL with PostgreSQL. Make notes of issues trying to follow the tutorial, areas where the tutorial lacks specific information to be able to accomplish the task, places where the tutorial doesn't provide information about how to tell if a given step was successful or not, and other items which could be improved.<br />
<br />
Using these notes, make changes to the PostgreSQL tutorial in its source format to address the deficiencies and submit these changes as patches to the PostgreSQL source tree so that they can be included in PostgreSQL in the future. These changes must be able to be patched to the PostgreSQL source code and the resulting changes built using the PostgreSQL build tool-chain.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Review and improve the "Advanced Features" tutorial in the PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a set of existing tutorials, one of which is "Advanced Features". Attempt to follow this tutorial, after installing PostgreSQL and creating a database and learning some SQL, to work with some of the Advanced Features of PostgreSQL including creating views, foreign keys, transactions, window functions, and inheritance. Make notes of issues trying to follow the tutorial, areas where the tutorial lacks specific information to be able to accomplish the task, places where the tutorial doesn't provide information about how to tell if a given step was successful or not, and other items which could be improved.<br />
<br />
Using these notes, make changes to the PostgreSQL tutorial in its source format to address the deficiencies and submit these changes as patches to the PostgreSQL source tree so that they can be included in PostgreSQL in the future. These changes must be able to be patched to the PostgreSQL source code and the resulting changes built using the PostgreSQL build tool-chain.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Add tutorial on partitioning to PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a section for tutorials, but lacks a tutorial which covers partitioning of a PostgreSQL table.<br />
<br />
The tutorial should be in the same format as the PostgreSQL documentation and should be submitted as a patch to the PostgreSQL source code and successfully built using the PostgreSQL build tool-chain. The simplest approach to writing this documentation is to pull down the PostgreSQL source code, build all of PostgreSQL, including the documentation, then work with PostgreSQL to set up partitioning following the existing documentation and ultimately make a copy of an existing tutorial section and then rewrite it to be the partitioning tutorial.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Add tutorial on physical Replication to PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a section for tutorials, but lacks a tutorial which covers physical replication between instances.<br />
<br />
The tutorial should be in the same format as the PostgreSQL documentation and should be submitted as a patch to the PostgreSQL source code and successfully built using the PostgreSQL build tool-chain. The simplest approach to writing this documentation is to pull down the PostgreSQL source code, build all of PostgreSQL, including the documentation, then work with PostgreSQL to set up physical replication following the existing documentation and ultimately make a copy of an existing tutorial section and then rewrite it to be the physical replication tutorial.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Add tutorial on logical Replication to PostgreSQL Documentation===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation has a section for tutorials, but lacks a tutorial which covers logical replication between PostgreSQL systems.<br />
<br />
The tutorial should be in the same format as the PostgreSQL documentation and should be submitted as a patch to the PostgreSQL source code and successfully built using the PostgreSQL build tool-chain. The simplest approach to writing this documentation is to pull down the PostgreSQL source code, build all of PostgreSQL, including the documentation, then work with PostgreSQL to set up logical replication following the existing documentation and ultimately make a copy of an existing tutorial section and then rewrite it to be the logical replication tutorial.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Documentation<br />
* Tutorial<br />
* Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
===Add pg_copy utility to properly handle WAL archiving===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL documentation uses cp as an example of an archive_command. This is not safe because cp does not sync the file or directory before returning success.<br />
<br />
Write a new utility called pg_copy that will copy a file and ensure it is durable before returning success. Existing files should not be overwritten, but the command may optionally calculate the SHA1 checksum of the destination file and return success if the source file has the same checksum.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* C<br />
* C-language<br />
* Programming<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
===Find & Post Job Listings===<br />
<br />
=====Task Description=====<br />
<br />
There are several entry-level technology job openings for PostgreSQL; your task would be to search for all relevant listings in your local area such as from newspapers and newspaper websites, Facebook groups, and websites of companies based in your area or those offering remote positions and compile them into a list. This list would then be provided to local high schools and community colleges in your area on their job postings board. <br />
<br />
Some examples of PostgreSQL job listings can be found in the pgsql-jobs mailing list archives, found here: <br />
<br />
https://www.postgresql.org/list/pgsql-jobs/<br />
<br />
https://www.postgresql-archive.org/PostgreSQL-jobs-f2207519.html<br />
<br />
The expected submission for this task would be the list itself as well as a list of the high schools and colleges where it was posted.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Research<br />
* Jobs<br />
<br />
=====Categories=====<br />
<br />
Outreach / Research<br />
<br />
===Help ESL Students with Job Applications===<br />
<br />
=====Task Description=====<br />
<br />
As a follow-up to "Find and Post Job Listings", you can additionally volunteer to assist with spell/grammar/language checking resumes and cover letters for ESL students applying for PostgreSQL job listings. This can extend to assisting ESL students draft their resumes. <br />
<br />
The expected submission would be the original posting advertising your services, where the posting was published (in-person at high schools/colleges, and/or online) the number of students that contacted you, and the number of students you were able to help.<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Research<br />
* Jobs<br />
<br />
=====Categories=====<br />
<br />
Outreach / Research<br />
<br />
===Add autovacuum work queue view===<br />
<br />
=====Task Description=====<br />
<br />
It is not at all clear which relations the autovacuum process will work on next. It would be good to know what jobs are coming up and also the length of the queue.<br />
<br />
Add a system view that exposes the autovacuum queue so it can be queried by a system administrator. Autovacuum should also be modified to use the new system view.<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* C<br />
* C-language<br />
* Programming<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
===Setup a Coffee Meet===<br />
<br />
=====Task Description=====<br />
<br />
Find a willing PostgreSQL contributor or committer in your area and arrange a coffee-shop meeting where young people or students of diverse backgrounds can come and have coffee with them to discuss PostgreSQL and ask questions about how to get started learning the technology. <br />
<br />
HINT: A meetup of this kind can be advertised to local audiences through [http://meetup.com/ Meetup], Facebook, Twitter (using appropriate hashtags), local high schools, or community colleges, as some examples. Try to schedule it out between 2-4 weeks in advance. <br />
<br />
The expected submission for this task would be to provide a link to the advertised meetup as well as the name of the contributor or committer that is willing to participate in the meeting. It would be preferred to include a summary of how the meeting went overall, how many attendees there were, and what kinds of questions were asked.<br />
<br />
The list of community contributors and committers can be found here:<br />
<br />
https://www.postgresql.org/community/contributors/<br />
<br />
https://wiki.postgresql.org/wiki/Committers<br />
<br />
=====Tags=====<br />
<br />
* Outreach<br />
* Research<br />
* Jobs<br />
* Trainng<br />
* Interview<br />
<br />
=====Categories=====<br />
<br />
Outreach / Research<br />
<br />
===Add documentation for JDBC driver CopyManager API===<br />
<br />
=====Task Description=====<br />
<br />
The PostgreSQL JDBC driver, pgjdbc, supports COPY commands to both STDIN and STDOUT via a non-JDBC extension, the CopyManager interface. While the driver has supported this functionality for many years, it's not documented in the official docs.<br />
<br />
The purpose of this task is to add some basic documentation of how to use the CopyManager interface to the official pgjdbc docs. The test suite for the pgjdbc driver includes examples of how to use the CopyManager interface and would a good resource for real world usage.<br />
<br />
The expected submission for this task will be a pull request on the pgjdbc GitHub page, https://github.com/pgjdbc/pgjdbc, for the documentation patch.<br />
<br />
=====Tags=====<br />
<br />
* JDBC<br />
* COPY<br />
* Documentation<br />
<br />
=====Categories=====<br />
<br />
Code<br />
<br />
Documentation / Training<br />
<br />
===Review and improve the documentation for PG Partition Manager===<br />
<br />
=====Task Description=====<br />
<br />
The pg_partman documenation has grown quite extensive over the years since it was released. Looking for a basic review of the top level README and files contained in the docs folder for grammar and clarity. Any other recommendations to improve documentation are welcome as well.<br />
<br />
Using Github, fork the repository and submit documentation improvements back via a pull request.<br />
<br />
https://github.com/pgpartman/pg_partman<br />
<br />
=====Tags=====<br />
<br />
* Documentation/ Training<br />
* SQL<br />
* Databases<br />
<br />
=====Categories=====<br />
<br />
Documentation/Training<br />
<br />
<br />
===Replace use of SplitIdentifierString with SplitGUCList in PG Partition Manager ===<br />
<br />
=====Task Description=====<br />
<br />
pg_partman has very minimal C code, but it should still be kept up to date to use new APIs when they become available. A small fix would be to see if it can take advantage of a new function to properly split a comma separated custom variable used in the postgresql.conf file. It currently uses SplitIdentifierString() to do this and PostgreSQL 10.5 introduced the new functions SplitGUCList().<br />
<br />
Code still needs to be kept backward compatible with older versions that don't have this function yet for a little while. Ensure this is done properly.<br />
<br />
Either provide a Github pull request adding this feature or provide reasons why this new function may not be appropriate to use in this case.<br />
<br />
https://github.com/pgpartman/pg_partman<br />
<br />
=====Tags=====<br />
<br />
* Code<br />
* C<br />
* C-language<br />
* SQL<br />
* Programming<br />
<br />
=====Categories=====<br />
<br />
Code</div>Jconway