Обсуждение: Alpha release process
For those of you who weren't involved in the Ottawa developer meeting, I think we should start by explaining that beginning with the 8.5 development cycle, we are planning to make regular alpha releases, to make early testing easier for more users. This will happen at the end of every commit fest. It will mostly look like a beta release, except that it will be called alpha and will at times perhaps not be as polished as a beta. (Among other things, it will also give as the opportunity to practice the release bundling procedures.) I have written down the details of the alpha release preparation process based on the meeting discussions at <http://wiki.postgresql.org/wiki/Alpha_release_process>, reproduced here for convenience: """ == Prerequisites == * Commit fest manager declares commit fest closed * Build farm is green, or failures are adequately explained (if widespread breakage, wait for a few days until fixed) == Naming == * 8.5alpha1, 8.5alpha2, etc. == Release preparation == src/tools/RELEASE_CHANGES applies Roughly: * Release version number changes * Release notes [Note: We'll have to work out exactly how to do this one as we go.] * Optional: Update timezone data * Optional: Translation updates (probably not useful until the last or next to last alpha) * Tag in CVS * Build the actual release tarball: make distcheck * Ask -hackers to check the tarball for sanity * Upload to ftp server [details?] == Announcing == Announce to: * PostgreSQL News * pgsql-hackers * pgsql-general(?) * pgsql-packagers For this one, we don't wait for the binaries to be built before announcing. Just make sure that the source tarballs are in place before the announcements go out. This way take a day or three; doesn't really matter. [[ReleasePrep]] contains notes about how to announce a release, which <em>do not apply</em> in their entirety to the alpha process, but are still worth digesting. """ Please discuss this now if you want changes. I personally plan to put some time and effort into making this happen, but I'm not sure who else will be involved. In case the traditional release team is not available, this would of course also provide opportunities for new people to get involved.
Peter Eisentraut <peter_e@gmx.net> wrote: > It will mostly look like a beta release No pgindent run I assume? -Kevin
Peter Eisentraut wrote: > == Release preparation == > src/tools/RELEASE_CHANGES applies No library soname bumps, right? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Peter Eisentraut wrote: > * Release notes [Note: We'll have to work out exactly how to do this one as we > go.] I am not planning to assist with this item for alpha releases. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Kevin Grittner wrote: > Peter Eisentraut <peter_e@gmx.net> wrote: > > > It will mostly look like a beta release > > No pgindent run I assume? I don't think so. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > == Release preparation == > > src/tools/RELEASE_CHANGES applies > > No library soname bumps, right? No, I doubt it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Peter Eisentraut <peter_e@gmx.net> wrote:
>> It will mostly look like a beta release
> No pgindent run I assume?
No, that would tend to break pending patches.
There's been some talk of pgindenting just new code added by patches
at the time they're committed. We don't seem to have the infrastructure
for a selective pgindent run, though, so I'm not sure quite how that'd
work. Anything more global should only happen at release times, when
(hopefully) there is the smallest volume of open patches to adjust.
regards, tom lane
On Monday 13 July 2009 22:49:21 Bruce Momjian wrote: > Kevin Grittner wrote: > > Peter Eisentraut <peter_e@gmx.net> wrote: > > > It will mostly look like a beta release > > > > No pgindent run I assume? > > I don't think so. No, certainly not.
On Monday 13 July 2009 22:47:40 Alvaro Herrera wrote: > Peter Eisentraut wrote: > > == Release preparation == > > src/tools/RELEASE_CHANGES applies > > No library soname bumps, right? The soname, which is name + major version number, is only bumped when the ABI changes. Perhaps you refer to the minor version number, but we don't bump those for betas either, so certainly not for alphas.
On Mon, Jul 13, 2009 at 3:57 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Peter Eisentraut <peter_e@gmx.net> wrote: >>> It will mostly look like a beta release > >> No pgindent run I assume? > > No, that would tend to break pending patches. > > There's been some talk of pgindenting just new code added by patches > at the time they're committed. We don't seem to have the infrastructure > for a selective pgindent run, though, so I'm not sure quite how that'd > work. Anything more global should only happen at release times, when > (hopefully) there is the smallest volume of open patches to adjust. The problem is that if you do a pgindent run with every commit, you'll break any the case where someone has developed a series of patches where each depends on the preceding one in the series. On the other hand, the longer you wait to run pgindent, the more people have a chance to start doing work that will eventually have to be rebased over the whitespace change. What would be really nice is to provide an easy and PORTABLE way for patch submitters to run pgindent themselves. Then you can pgindent on every commit, and if you break somebody's patch series, it's there own fault for not pgindenting it correctly before they submitted it. I have no idea how to make that work, however. It seems like a hard problem. ...Robert
Robert Haas escribió: > What would be really nice is to provide an easy and PORTABLE way for > patch submitters to run pgindent themselves. Then you can pgindent on > every commit, and if you break somebody's patch series, it's there own > fault for not pgindenting it correctly before they submitted it. +1 (in fact I said the same thing some time ago) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Robert Haas <robertmhaas@gmail.com> writes:
> What would be really nice is to provide an easy and PORTABLE way for
> patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good reason we couldn't distribute pgindent in source form.
There just hasn't been a motivation to do so. Maybe we should put it
into CVS in src/tools?
regards, tom lane
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > What would be really nice is to provide an easy and PORTABLE way for > > patch submitters to run pgindent themselves. > > AFAIK it's just BSD indent plus some private patches of Bruce's, so > there's no good reason we couldn't distribute pgindent in source form. > There just hasn't been a motivation to do so. Maybe we should put it > into CVS in src/tools? My patched version is on our ftp server: http://wwwmaster.postgresql.org/download/mirrors-ftp/dev/indent.netbsd.patched.tgz -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane escribió: > Robert Haas <robertmhaas@gmail.com> writes: > > What would be really nice is to provide an easy and PORTABLE way for > > patch submitters to run pgindent themselves. > > AFAIK it's just BSD indent plus some private patches of Bruce's, so > there's no good reason we couldn't distribute pgindent in source form. > There just hasn't been a motivation to do so. Maybe we should put it > into CVS in src/tools? The main roadblock is getting an "official" typedef list though ... -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Tom Lane escribi?: > > Robert Haas <robertmhaas@gmail.com> writes: > > > What would be really nice is to provide an easy and PORTABLE way for > > > patch submitters to run pgindent themselves. > > > > AFAIK it's just BSD indent plus some private patches of Bruce's, so > > there's no good reason we couldn't distribute pgindent in source form. > > There just hasn't been a motivation to do so. Maybe we should put it > > into CVS in src/tools? > > The main roadblock is getting an "official" typedef list though ... Yep, that's an Andrew issue now. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> == Announcing == > Announce to: > * PostgreSQL News > * pgsql-hackers > * pgsql-general(?) > * pgsql-packagers Also pgsql-announce, no? I'm happy to write announcements. I'm also happy to give someone else some practice ... I'll see if anyone is interested on -advocacy. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
On 7/13/09 12:49 PM, Bruce Momjian wrote: > Peter Eisentraut wrote: >> * Release notes [Note: We'll have to work out exactly how to do this one as we >> go.] > > I am not planning to assist with this item for alpha releases. Anyone want to volunteer to organize the alpha release notes? This seems like a golden opportuntity to shorten the release note process for the final release. I'd see Alpha release notes looking like: IN THIS ALPHA ... things added since last alpha ... IN 8.5 ... everything else, cumulative ... Also, what about producing Docs? I suppose we have the developer docs ... -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
On Tuesday 14 July 2009 21:20:51 Josh Berkus wrote: > Also, what about producing Docs? I'm working on making the documentation build part of the normal release building rules.
On Tuesday 14 July 2009 21:17:14 Josh Berkus wrote: > > == Announcing == > > Announce to: > > * PostgreSQL News > > * pgsql-hackers > > * pgsql-general(?) > > * pgsql-packagers > > Also pgsql-announce, no? Yes.