Re: 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(at)gmx(dot)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(at)momjian(dot)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(at)gmx(dot)net> wrote:
>
> > It will mostly look like a beta release
>
> No pgindent run I assume?

I don't think so.

--
Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)momjian(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)momjian(dot)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.