Обсуждение: Linux Downloads page change

On Sat, Jul 7, 2012 at 6:26 PM, Scott Mead <scottm@openscg.com> wrote:
> Hey all,
>
>     The Linux binary downloads page seems to have changed, eliminating the
> cross-distribution, unified RPM's as a download option.  Is this something
> simple that got missed in a recent check-in?

Hi!

They are all on the general download page, under third party distributions.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Sat, Jul 7, 2012 at 6:26 PM, Scott Mead <scottm@openscg.com> wrote:
> Hey all,
>
>     The Linux binary downloads page seems to have changed, eliminating the
> cross-distribution, unified RPM's as a download option.  Is this something
> simple that got missed in a recent check-in?

Hi!

They are all on the general download page, under third party distributions.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Sat, 2012-07-07 at 13:06 -0400, Scott Mead wrote:
> > They are all on the general download page, under third party
> distributions.
>
>
>  Those are our developer bundles that include postgres along with
> different application servers.  We also have production/ops server
> rpms that used to appear on the Linux download page.

That reminds me... Why do we give link to some binary RPMs, where SRPMs
are not available?

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Jul 7, 2012, at 4:23 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:

> On Sat, 2012-07-07 at 13:06 -0400, Scott Mead wrote:
>>> They are all on the general download page, under third party
>> distributions.
>>
>>
>> Those are our developer bundles that include postgres along with
>> different application servers.  We also have production/ops server
>> rpms that used to appear on the Linux download page.
>
> That reminds me... Why do we give link to some binary RPMs, where SRPMs
> are not available?

Those RPMs are built using the certified binaries that the community distributes already, but simplifies installation
indeeply firewalled / headless server environments.  They also allow for side-by-side installs of major versions (
pg_upgradecompatible ) and have since their inception.    

--Scott

>
> Regards,
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Sat, Jul 7, 2012 at 7:06 PM, Scott Mead <scottm@openscg.com> wrote:
>
>
> On Saturday, July 7, 2012, Magnus Hagander wrote:
>>
>> On Sat, Jul 7, 2012 at 6:26 PM, Scott Mead <scottm@openscg.com> wrote:
>> > Hey all,
>> >
>> >     The Linux binary downloads page seems to have changed, eliminating
>> > the
>> > cross-distribution, unified RPM's as a download option.  Is this
>> > something
>> > simple that got missed in a recent check-in?
>>
>> Hi!
>>
>> They are all on the general download page, under third party
>> distributions.
>
>
>  Those are our developer bundles that include postgres along with different
> application servers.  We also have production/ops server rpms that used to
> appear on the Linux download page.

I wasn't even aware there were different ones - there's your explanation.

These are the ones listed on the same page, right?

Is there a documentation page somewhere outlining the differences
between these and the community binaries?

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>
> > That reminds me... Why do we give link to some binary RPMs, where
> SRPMs
> > are not available?
>
> Those RPMs are built using the certified binaries that the community
> distributes already, but simplifies installation in deeply
> firewalled / headless server environments.  They also allow for
> side-by-side installs of major versions ( pg_upgrade compatible ) and
> have since their inception.

That is not an answer to my question. Why don't you distribute the SRPM?
How can someone make sure that the RPMs do not include some more extra
code?
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>>
>> > That reminds me... Why do we give link to some binary RPMs, where
>> SRPMs
>> > are not available?
>>
>> Those RPMs are built using the certified binaries that the community
>> distributes already, but simplifies installation in deeply
>> firewalled / headless server environments.  They also allow for
>> side-by-side installs of major versions ( pg_upgrade compatible ) and
>> have since their inception.
>
> That is not an answer to my question. Why don't you distribute the SRPM?
> How can someone make sure that the RPMs do not include some more extra
> code?

I assume the SRPM isn't provided because the binaries that are
packaged are actually the ones that EDB build (and I wouldn't be
surprised if they're generated with BitRock InstallBuilder, so there
wouldn't be an SRPM anyway).

That aside though, the code must be 100% open source to be listed on
those download pages; Scottie, where can people find the spec files,
BitRock XML files or whatever?

Also, I took a quick look at the GIT history for the download pages,
and as far as I can see there weren't any links to these RPMs in the
past, so I'm not sure what has been removed exactly. Scott; can you
point me at the commit that changed what you're referring to please?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 10:31 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>>>
>>> > That reminds me... Why do we give link to some binary RPMs, where
>>> SRPMs
>>> > are not available?
>>>
>>> Those RPMs are built using the certified binaries that the community
>>> distributes already, but simplifies installation in deeply
>>> firewalled / headless server environments.  They also allow for
>>> side-by-side installs of major versions ( pg_upgrade compatible ) and
>>> have since their inception.
>>
>> That is not an answer to my question. Why don't you distribute the SRPM?
>> How can someone make sure that the RPMs do not include some more extra
>> code?
>
> I assume the SRPM isn't provided because the binaries that are
> packaged are actually the ones that EDB build (and I wouldn't be
> surprised if they're generated with BitRock InstallBuilder, so there
> wouldn't be an SRPM anyway).

BitRock can generate RPMs these days? Neat!


> That aside though, the code must be 100% open source to be listed on
> those download pages; Scottie, where can people find the spec files,
> BitRock XML files or whatever?

While I agree with that requirement in general, we should apply it
fairly. AFAICT the latest release of the EDB installers that had
sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
would've changed since... None of the changes that have been discussed
on the lists here in the past couple of months are anywhere to be
seen.. So should we remove the EDB installers from the page as well?


> Also, I took a quick look at the GIT history for the download pages,
> and as far as I can see there weren't any links to these RPMs in the
> past, so I'm not sure what has been removed exactly. Scott; can you
> point me at the commit that changed what you're referring to please?

I assume he's referring to:
-<p><a href="http://www.openscg.org/postgresql/packages">Download</a>
the packages from OpenSCG.<
-<p><i>The multi-platform binary packages are maintained by <a
href="http://www.openscg.org">Open

from commit b282714a097f767b258e469fb80225b638864a19. They used to be
on the "generic linux" page, as well as on the "generic downloads
page". They are now only on the "generic downloads page".

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Mon, Jul 9, 2012 at 9:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jul 9, 2012 at 10:31 AM, Dave Page <dpage@pgadmin.org> wrote:
>> On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>>> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>>>>
>>>> > That reminds me... Why do we give link to some binary RPMs, where
>>>> SRPMs
>>>> > are not available?
>>>>
>>>> Those RPMs are built using the certified binaries that the community
>>>> distributes already, but simplifies installation in deeply
>>>> firewalled / headless server environments.  They also allow for
>>>> side-by-side installs of major versions ( pg_upgrade compatible ) and
>>>> have since their inception.
>>>
>>> That is not an answer to my question. Why don't you distribute the SRPM?
>>> How can someone make sure that the RPMs do not include some more extra
>>> code?
>>
>> I assume the SRPM isn't provided because the binaries that are
>> packaged are actually the ones that EDB build (and I wouldn't be
>> surprised if they're generated with BitRock InstallBuilder, so there
>> wouldn't be an SRPM anyway).
>
> BitRock can generate RPMs these days? Neat!

It's been able to do RPMs and DEBs as long as I've been using it. I
tried generating them from our builds, but there's too much
interactivity at different points in the installers, and neither the
RPM or DEB formats can handle it.

>> That aside though, the code must be 100% open source to be listed on
>> those download pages; Scottie, where can people find the spec files,
>> BitRock XML files or whatever?
>
> While I agree with that requirement in general, we should apply it
> fairly. AFAICT the latest release of the EDB installers that had
> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
> would've changed since... None of the changes that have been discussed
> on the lists here in the past couple of months are anywhere to be
> seen.. So should we remove the EDB installers from the page as well?

The EDB installers are open source, and have been since they were
first published. You can get the code for all branches from
http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and
that includes not just the installer files, but the entire build
framework. The most recent commit is to the 9.2 branch, from Friday.

I'm not sure why you would think I'd push for a different rule for
OpenSCG than EDB - I've always made a point of trying to apply the
same standards to all our corporate contributors - as a core team
member and a senior member of staff at EDB not only is it the right
thing to do, but it's the only way I can function in both roles. I'm a
little offended that you would suggest otherwise.

>> Also, I took a quick look at the GIT history for the download pages,
>> and as far as I can see there weren't any links to these RPMs in the
>> past, so I'm not sure what has been removed exactly. Scott; can you
>> point me at the commit that changed what you're referring to please?
>
> I assume he's referring to:
> -<p><a href="http://www.openscg.org/postgresql/packages">Download</a>
> the packages from OpenSCG.<
> -<p><i>The multi-platform binary packages are maintained by <a
> href="http://www.openscg.org">Open
>
> from commit b282714a097f767b258e469fb80225b638864a19. They used to be
> on the "generic linux" page, as well as on the "generic downloads
> page". They are now only on the "generic downloads page".

Oh, I see it now. Not sure how I missed that.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

<p><br /> On Jul 9, 2012 4:42 AM, "Magnus Hagander" <<a
href="mailto:magnus@hagander.net">magnus@hagander.net</a>>wrote:<br /> ><br /> > On Mon, Jul 9, 2012 at 10:31
AM,Dave Page <<a href="mailto:dpage@pgadmin.org">dpage@pgadmin.org</a>> wrote:<br /> > > On Sun, Jul 8,
2012at 9:56 PM, Devrim GÜNDÜZ <<a href="mailto:devrim@gunduz.org">devrim@gunduz.org</a>> wrote:<br /> >
>>On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:<br /> > >>><br /> > >>> > That
remindsme... Why do we give link to some binary RPMs, where<br /> > >>> SRPMs<br /> > >>> >
arenot available?<br /> > >>><br /> > >>> Those RPMs are built using the certified binaries
thatthe community<br /> > >>> distributes already, but simplifies installation in deeply<br /> >
>>>firewalled / headless server environments.  They also allow for<br /> > >>> side-by-side
installsof major versions ( pg_upgrade compatible ) and<br /> > >>> have since their inception.<br /> >
>><br/> > >> That is not an answer to my question. Why don't you distribute the SRPM?<br /> >
>>How can someone make sure that the RPMs do not include some more extra<br /> > >> code?<br /> >
><br/> > > I assume the SRPM isn't provided because the binaries that are<br /> > > packaged are
actuallythe ones that EDB build (and I wouldn't be<br /> > > surprised if they're generated with BitRock
InstallBuilder,so there<br /> > > wouldn't be an SRPM anyway).<br /> ><p>+1<p>> BitRock can generate RPMs
thesedays? Neat!<br /> ><br /> ><br /> > > That aside though, the code must be 100% open source to be
listedon<br /> > > those download pages; Scottie, where can people find the spec files,<br /> > > BitRock
XMLfiles or whatever?<p>  In the past we have always provided them upon request ( we were asked only nce :).  But we
canwork that out, no problem.<br /><p>><br /> > While I agree with that requirement in general, we should apply
it<br/> > fairly. AFAICT the latest release of the EDB installers that had<br /> > sourcecode with it was 9.0.2 -
Ihave a hard time seeing that nothing<br /> > would've changed since... None of the changes that have been
discussed<br/> > on the lists here in the past couple of months are anywhere to be<br /> > seen.. So should we
removethe EDB installers from the page as well?<br /> ><br /> ><br /> > > Also, I took a quick look at the
GIThistory for the download pages,<br /> > > and as far as I can see there weren't any links to these RPMs in
the<br/> > > past, so I'm not sure what has been removed exactly. Scott; can you<br /> > > point me at the
committhat changed what you're referring to please?<br /> ><br /> > I assume he's referring to:<br /> >
-<p><ahref="<a
href="http://www.openscg.org/postgresql/packages">http://www.openscg.org/postgresql/packages</a>">Download</a><br
/>> the packages from OpenSCG.<<br /> > -<p><i>The multi-platform binary packages are maintained
by<a<br /> > href="<a href="http://www.openscg.org">http://www.openscg.org</a>">Open<br /> ><br /> >
fromcommit b282714a097f767b258e469fb80225b638864a19. They used to be<br /> > on the "generic linux" page, as well as
onthe "generic downloads<br /> > page". They are now only on the "generic downloads page".<p>Exactly, this is the
linkI was talking about.<br /><p>--Scottie<p>><br /> > --<br /> >  Magnus Hagander<br /> >  Me: <a
href="http://www.hagander.net/">http://www.hagander.net/</a><br/> >  Work: <a
href="http://www.redpill-linpro.com/">http://www.redpill-linpro.com/</a><br/> 

On Mon, Jul 9, 2012 at 11:13 AM, Scott Mead <scottm@openscg.com> wrote:
>
>> > That aside though, the code must be 100% open source to be listed on
>> > those download pages; Scottie, where can people find the spec files,
>> > BitRock XML files or whatever?
>
>   In the past we have always provided them upon request ( we were asked only
> nce :).  But we can work that out, no problem.

Yes, please look into that.


>> While I agree with that requirement in general, we should apply it
>> fairly. AFAICT the latest release of the EDB installers that had
>> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
>> would've changed since... None of the changes that have been discussed
>> on the lists here in the past couple of months are anywhere to be
>> seen.. So should we remove the EDB installers from the page as well?
>>
>>
>> > Also, I took a quick look at the GIT history for the download pages,
>> > and as far as I can see there weren't any links to these RPMs in the
>> > past, so I'm not sure what has been removed exactly. Scott; can you
>> > point me at the commit that changed what you're referring to please?
>>
>> I assume he's referring to:
>> -<p><a href="http://www.openscg.org/postgresql/packages">Download</a>
>> the packages from OpenSCG.<
>> -<p><i>The multi-platform binary packages are maintained by <a
>> href="http://www.openscg.org">Open
>>
>> from commit b282714a097f767b258e469fb80225b638864a19. They used to be
>> on the "generic linux" page, as well as on the "generic downloads
>> page". They are now only on the "generic downloads page".
>
> Exactly, this is the link I was talking about.

Given that the whole idea of the redesign is to help people figure out
why they should choose the different options, can you provide a patch
to that page that actually includes a good description of *why* these
would be preferable to the standard RPMs?

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

<p><br /> On Jul 9, 2012 5:31 AM, "Magnus Hagander" <<a
href="mailto:magnus@hagander.net">magnus@hagander.net</a>>wrote:<br /> ><br /> > On Mon, Jul 9, 2012 at 11:13
AM,Scott Mead <<a href="mailto:scottm@openscg.com">scottm@openscg.com</a>> wrote:<br /> > ><br /> >
>>> That aside though, the code must be 100% open source to be listed on<br /> > >> > those
downloadpages; Scottie, where can people find the spec files,<br /> > >> > BitRock XML files or
whatever?<br/> > ><br /> > >   In the past we have always provided them upon request ( we were asked
only<br/> > > nce :).  But we can work that out, no problem.<br /> ><br /> > Yes, please look into that.<br
/>><br /> ><br /> > >> While I agree with that requirement in general, we should apply it<br /> >
>>fairly. AFAICT the latest release of the EDB installers that had<br /> > >> sourcecode with it was
9.0.2- I have a hard time seeing that nothing<br /> > >> would've changed since... None of the changes that
havebeen discussed<br /> > >> on the lists here in the past couple of months are anywhere to be<br /> >
>>seen.. So should we remove the EDB installers from the page as well?<br /> > >><br /> > >><br
/>> >> > Also, I took a quick look at the GIT history for the download pages,<br /> > >> > and
asfar as I can see there weren't any links to these RPMs in the<br /> > >> > past, so I'm not sure what has
beenremoved exactly. Scott; can you<br /> > >> > point me at the commit that changed what you're referring
toplease?<br /> > >><br /> > >> I assume he's referring to:<br /> > >> -<p><a
href="<a
href="http://www.openscg.org/postgresql/packages">http://www.openscg.org/postgresql/packages</a>">Download</a><br
/>> >> the packages from OpenSCG.<<br /> > >> -<p><i>The multi-platform binary
packagesare maintained by <a<br /> > >> href="<a
href="http://www.openscg.org">http://www.openscg.org</a>">Open<br/> > >><br /> > >> from commit
b282714a097f767b258e469fb80225b638864a19.They used to be<br /> > >> on the "generic linux" page, as well as on
the"generic downloads<br /> > >> page". They are now only on the "generic downloads page".<br /> > ><br
/>> > Exactly, this is the link I was talking about.<br /> ><br /> > Given that the whole idea of the
redesignis to help people figure out<br /> > why they should choose the different options, can you provide a
patch<br/> > to that page that actually includes a good description of *why* these<br /> > would be preferable to
thestandard RPMs?<p>Absolutely, I'm boarding a flight now, but will work on it once I hit 10,000
ft.<p>--Scottie<p>><br/> > --<br /> >  Magnus Hagander<br /> >  Me: <a
href="http://www.hagander.net/">http://www.hagander.net/</a><br/> >  Work: <a
href="http://www.redpill-linpro.com/">http://www.redpill-linpro.com/</a><br/> 

Pah, got denied-post on -www for that email due to it being too large.
Sorry about that - repost, with a link instead - the referenced image
can be found at
http://www.hagander.net/tmp/s_2012-07-09-01-3c6e87.png.

//Magnus

On Mon, Jul 9, 2012 at 11:30 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jul 9, 2012 at 11:09 AM, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Jul 9, 2012 at 9:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Mon, Jul 9, 2012 at 10:31 AM, Dave Page <dpage@pgadmin.org> wrote:
>>>> On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>>>>> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>>>>>>
>>>>>> > That reminds me... Why do we give link to some binary RPMs, where
>>>>>> SRPMs
>>>>>> > are not available?
>>>>>>
>>>>>> Those RPMs are built using the certified binaries that the community
>>>>>> distributes already, but simplifies installation in deeply
>>>>>> firewalled / headless server environments.  They also allow for
>>>>>> side-by-side installs of major versions ( pg_upgrade compatible ) and
>>>>>> have since their inception.
>>>>>
>>>>> That is not an answer to my question. Why don't you distribute the SRPM?
>>>>> How can someone make sure that the RPMs do not include some more extra
>>>>> code?
>>>>
>>>> I assume the SRPM isn't provided because the binaries that are
>>>> packaged are actually the ones that EDB build (and I wouldn't be
>>>> surprised if they're generated with BitRock InstallBuilder, so there
>>>> wouldn't be an SRPM anyway).
>>>
>>> BitRock can generate RPMs these days? Neat!
>>
>> It's been able to do RPMs and DEBs as long as I've been using it. I
>> tried generating them from our builds, but there's too much
>> interactivity at different points in the installers, and neither the
>> RPM or DEB formats can handle it.
>
> Cool. I had no idea :) But yah, particularly the RPMs are pretty picky
> about interactivity (for good reasons from their perspective, of
> course, but nevertheless quite picky)
>
>
>>>> That aside though, the code must be 100% open source to be listed on
>>>> those download pages; Scottie, where can people find the spec files,
>>>> BitRock XML files or whatever?
>>>
>>> While I agree with that requirement in general, we should apply it
>>> fairly. AFAICT the latest release of the EDB installers that had
>>> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
>>> would've changed since... None of the changes that have been discussed
>>> on the lists here in the past couple of months are anywhere to be
>>> seen.. So should we remove the EDB installers from the page as well?
>>
>> The EDB installers are open source, and have been since they were
>> first published. You can get the code for all branches from
>> http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and
>> that includes not just the installer files, but the entire build
>> framework. The most recent commit is to the 9.2 branch, from Friday.
>
> Attached is a screenshot showing what this page looked like when I
> sent that email. So someone pushed all those changes *after* I sent
> that email, in what looks like an attempt to dispute that statement.
> While we don't have log extracts showing the exact times (should
> probably fix that in the pggit code), there is certainly a push shown
> around 9AM UTC this morning... (and it shows that between this push
> and the previous *of any activity at all* on that repository, there
> have been another 5189 operations on git.postgresql.org - around 3500
> pushes, though that includes pushes from the mirror of the main
> postgresql git repo, so it's a little bit inflated. but it pretty
> clearly matches up to the "no activity in 18 months" that the web
> interface showed)
>
> I know they're *intended* to be opensource. But the normal status is
> they're lagging behind a year or more, so I'm not sure I consider it
> open... My experience shows that whenever I'm looking for something,
> it's not up to date, and it's only pushed when I point it out. It may
> well be that it's pushed at other times as wel of course - but you
> can't really claim it's pushed regularly.
>
>> I'm not sure why you would think I'd push for a different rule for
>> OpenSCG than EDB - I've always made a point of trying to apply the
>> same standards to all our corporate contributors - as a core team
>> member and a senior member of staff at EDB not only is it the right
>> thing to do, but it's the only way I can function in both roles. I'm a
>> little offended that you would suggest otherwise.
>
> I normally wouldn't think you would, but it certainly sounded like
> that, given exactly what that repository looked like this morning -
> and has looked like pretty much every time I've looked at it recently.
> Which was "the installers were once dumped as opensource to make it
> look good, but we don't really care about them being open".
>
> And frankly, I'm a little offended by whomever made that push into the
> repository to dispute my statement, without claiming responsibility
> for doing so. To me, it's rather obvious it was done as a direct
> response to my email. Given the perfect timing. Whoever did it.
>
> So what *is* the intended policy for that repo? It's clearly not the
> primary repo for the edb installers but just a mirror. Which has
> received a total of 50 pushes *since the creation of the new
> git.postgresql.org*, years ago.  So it's clearly not mirrored in
> anything near real time. So when *does* it get pushed, aside from when
> somebody complains?
>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/

On Mon, Jul 9, 2012 at 10:30 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jul 9, 2012 at 11:09 AM, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Jul 9, 2012 at 9:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Mon, Jul 9, 2012 at 10:31 AM, Dave Page <dpage@pgadmin.org> wrote:
>>>> On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>>>>> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
>>>>>>
>>>>>> > That reminds me... Why do we give link to some binary RPMs, where
>>>>>> SRPMs
>>>>>> > are not available?
>>>>>>
>>>>>> Those RPMs are built using the certified binaries that the community
>>>>>> distributes already, but simplifies installation in deeply
>>>>>> firewalled / headless server environments.  They also allow for
>>>>>> side-by-side installs of major versions ( pg_upgrade compatible ) and
>>>>>> have since their inception.
>>>>>
>>>>> That is not an answer to my question. Why don't you distribute the SRPM?
>>>>> How can someone make sure that the RPMs do not include some more extra
>>>>> code?
>>>>
>>>> I assume the SRPM isn't provided because the binaries that are
>>>> packaged are actually the ones that EDB build (and I wouldn't be
>>>> surprised if they're generated with BitRock InstallBuilder, so there
>>>> wouldn't be an SRPM anyway).
>>>
>>> BitRock can generate RPMs these days? Neat!
>>
>> It's been able to do RPMs and DEBs as long as I've been using it. I
>> tried generating them from our builds, but there's too much
>> interactivity at different points in the installers, and neither the
>> RPM or DEB formats can handle it.
>
> Cool. I had no idea :) But yah, particularly the RPMs are pretty picky
> about interactivity (for good reasons from their perspective, of
> course, but nevertheless quite picky)
>
>
>>>> That aside though, the code must be 100% open source to be listed on
>>>> those download pages; Scottie, where can people find the spec files,
>>>> BitRock XML files or whatever?
>>>
>>> While I agree with that requirement in general, we should apply it
>>> fairly. AFAICT the latest release of the EDB installers that had
>>> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
>>> would've changed since... None of the changes that have been discussed
>>> on the lists here in the past couple of months are anywhere to be
>>> seen.. So should we remove the EDB installers from the page as well?
>>
>> The EDB installers are open source, and have been since they were
>> first published. You can get the code for all branches from
>> http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and
>> that includes not just the installer files, but the entire build
>> framework. The most recent commit is to the 9.2 branch, from Friday.
>
> Attached is a screenshot showing what this page looked like when I
> sent that email. So someone pushed all those changes *after* I sent
> that email, in what looks like an attempt to dispute that statement.
> While we don't have log extracts showing the exact times (should
> probably fix that in the pggit code), there is certainly a push shown
> around 9AM UTC this morning... (and it shows that between this push
> and the previous *of any activity at all* on that repository, there
> have been another 5189 operations on git.postgresql.org - around 3500
> pushes, though that includes pushes from the mirror of the main
> postgresql git repo, so it's a little bit inflated. but it pretty
> clearly matches up to the "no activity in 18 months" that the web
> interface showed)

It gets pushed periodically when I remember to do it (or someone
reminds me), which I guess you've forgotten given that we've had this
exact same discussion before. Yes, I pushed it when you reminded me a
moment ago - and this time remembered to also push the 9.2 branch
which previously hadn't been pushed because it needs to be done
explicitly the first time which I had forgotten to do in the past.
That's where the vast majority of activity has been over recent
months, except the last 3 weeks or so where there have been numerous
bug fixes in the back branches as we've been updating the add-ons that
are available through StackBuilder.

> I know they're *intended* to be opensource. But the normal status is
> they're lagging behind a year or more, so I'm not sure I consider it
> open... My experience shows that whenever I'm looking for something,
> it's not up to date, and it's only pushed when I point it out. It may
> well be that it's pushed at other times as wel of course - but you
> can't really claim it's pushed regularly.

No, I never have claimed it's pushed regularly. I've always said it's
pushed when I remember or when someone reminds me. The point is that
it is pushed, and has been on more than one occasion since 9.0.2 was
released - which should be obvious if you look towards the bottom of
your screenshot.

>> I'm not sure why you would think I'd push for a different rule for
>> OpenSCG than EDB - I've always made a point of trying to apply the
>> same standards to all our corporate contributors - as a core team
>> member and a senior member of staff at EDB not only is it the right
>> thing to do, but it's the only way I can function in both roles. I'm a
>> little offended that you would suggest otherwise.
>
> I normally wouldn't think you would, but it certainly sounded like
> that, given exactly what that repository looked like this morning -
> and has looked like pretty much every time I've looked at it recently.
> Which was "the installers were once dumped as opensource to make it
> look good, but we don't really care about them being open".
>
> And frankly, I'm a little offended by whomever made that push into the
> repository to dispute my statement, without claiming responsibility
> for doing so. To me, it's rather obvious it was done as a direct
> response to my email. Given the perfect timing. Whoever did it.

It was. You reminded me. As you've done in the past. I made no claim
that I push that repo on any regular schedule - merely that I try to
remember to keep it up to date, and the code is available under an
open source licence.

> So what *is* the intended policy for that repo? It's clearly not the
> primary repo for the edb installers but just a mirror. Which has
> received a total of 50 pushes *since the creation of the new
> git.postgresql.org*, years ago.  So it's clearly not mirrored in
> anything near real time. So when *does* it get pushed, aside from when
> somebody complains?

As I said, when I remember to do it. As I've told you in the past.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 10:44 AM, Dave Page <dpage@pgadmin.org> wrote:
>
> No, I never have claimed it's pushed regularly. I've always said it's
> pushed when I remember or when someone reminds me. The point is that
> it is pushed, and has been on more than one occasion since 9.0.2 was
> released - which should be obvious if you look towards the bottom of
> your screenshot.

BTW; the reason that you see 9.0.2 in the commit log there is that
right after 9.0.2 was released, we stopped using the master branch for
anything. We now use named branches for all versions, so there is no
recent activity in master, only in the REL-X_Y branches.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 11:44 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 10:30 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>>> That aside though, the code must be 100% open source to be listed on
>>>>> those download pages; Scottie, where can people find the spec files,
>>>>> BitRock XML files or whatever?
>>>>
>>>> While I agree with that requirement in general, we should apply it
>>>> fairly. AFAICT the latest release of the EDB installers that had
>>>> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
>>>> would've changed since... None of the changes that have been discussed
>>>> on the lists here in the past couple of months are anywhere to be
>>>> seen.. So should we remove the EDB installers from the page as well?
>>>
>>> The EDB installers are open source, and have been since they were
>>> first published. You can get the code for all branches from
>>> http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and
>>> that includes not just the installer files, but the entire build
>>> framework. The most recent commit is to the 9.2 branch, from Friday.
>>
>> Attached is a screenshot showing what this page looked like when I
>> sent that email. So someone pushed all those changes *after* I sent
>> that email, in what looks like an attempt to dispute that statement.
>> While we don't have log extracts showing the exact times (should
>> probably fix that in the pggit code), there is certainly a push shown
>> around 9AM UTC this morning... (and it shows that between this push
>> and the previous *of any activity at all* on that repository, there
>> have been another 5189 operations on git.postgresql.org - around 3500
>> pushes, though that includes pushes from the mirror of the main
>> postgresql git repo, so it's a little bit inflated. but it pretty
>> clearly matches up to the "no activity in 18 months" that the web
>> interface showed)
>
> It gets pushed periodically when I remember to do it (or someone
> reminds me), which I guess you've forgotten given that we've had this
> exact same discussion before. Yes, I pushed it when you reminded me a
> moment ago - and this time remembered to also push the 9.2 branch
> which previously hadn't been pushed because it needs to be done
> explicitly the first time which I had forgotten to do in the past.
> That's where the vast majority of activity has been over recent
> months, except the last 3 weeks or so where there have been numerous
> bug fixes in the back branches as we've been updating the add-ons that
> are available through StackBuilder.

We have had the discussion before, and I was pretty sure it ended up
in "yes, it should be fixed". But it doesn't change the fact that the
repository claimed there had been no changes for *7 months*, certainly
not 3 days. Which also agrees very well with the logs on
git.postgresql.org.

So clearly there is something that doesn't work in this process.


>> I know they're *intended* to be opensource. But the normal status is
>> they're lagging behind a year or more, so I'm not sure I consider it
>> open... My experience shows that whenever I'm looking for something,
>> it's not up to date, and it's only pushed when I point it out. It may
>> well be that it's pushed at other times as wel of course - but you
>> can't really claim it's pushed regularly.
>
> No, I never have claimed it's pushed regularly. I've always said it's
> pushed when I remember or when someone reminds me. The point is that

In that case, can we get it done regularly, so it can actually be
considered open?


> it is pushed, and has been on more than one occasion since 9.0.2 was
> released - which should be obvious if you look towards the bottom of
> your screenshot.

Yeah. I guess you're just not bothering to tag releases anymore? that
confused me on that point.


>> And frankly, I'm a little offended by whomever made that push into the
>> repository to dispute my statement, without claiming responsibility
>> for doing so. To me, it's rather obvious it was done as a direct
>> response to my email. Given the perfect timing. Whoever did it.
>
> It was. You reminded me. As you've done in the past. I made no claim
> that I push that repo on any regular schedule - merely that I try to
> remember to keep it up to date, and the code is available under an
> open source licence.

Well, IMNSHO, just being available under an open source license *if
asked for*, should be well below where a reasonable bar would be put
for this.

But in treating people the same - I just asked Scottie to make sure
that they're not available just when asked for, but all the time. Can
you do the same?

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Mon, Jul 9, 2012 at 10:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> We have had the discussion before, and I was pretty sure it ended up
> in "yes, it should be fixed". But it doesn't change the fact that the
> repository claimed there had been no changes for *7 months*, certainly
> not 3 days. Which also agrees very well with the logs on
> git.postgresql.org.

I'm not disputing that, and never have.

> So clearly there is something that doesn't work in this process.

It works exactly as it always has. No, I haven't got round to
automating the pushes yet, largely because I've had 1001 other things
to do, the vast majority of which will benefit far more users and
community members in one way or another. I wasn't aware that you
considered this to be such a high priority item compared to all the
other tasks I have on my plate.

> Yeah. I guess you're just not bothering to tag releases anymore? that
> confused me on that point.

Yes, we tag them. I just forgot that GIT pulls tags automatically, but
doesn't push them. I've corrected that now.

> Well, IMNSHO, just being available under an open source license *if
> asked for*, should be well below where a reasonable bar would be put
> for this.

Maybe, but that's a different discussion. By your own admission you've
been well aware that we made the installers available under an OSS
licence in this way for a long time which implies consent, casual
discussion about improving the push frequency aside - as is the norm
in community matters. You certainly haven't nudged me about this, or
made me aware (until now) that you consider it to be a high priority.

> But in treating people the same - I just asked Scottie to make sure
> that they're not available just when asked for, but all the time. Can
> you do the same?

Sure, I'll bump it up the list and try to do it today. What do you
consider more important, this or the CFP?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 12:13 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 10:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>
>> So clearly there is something that doesn't work in this process.
>
> It works exactly as it always has. No, I haven't got round to
> automating the pushes yet, largely because I've had 1001 other things
> to do, the vast majority of which will benefit far more users and
> community members in one way or another. I wasn't aware that you
> considered this to be such a high priority item compared to all the
> other tasks I have on my plate.

Given that I don't know what else is on your plate (except for some
tiny parts), that's kind of hard to state. I *have* asked for it for
years...


>> Yeah. I guess you're just not bothering to tag releases anymore? that
>> confused me on that point.
>
> Yes, we tag them. I just forgot that GIT pulls tags automatically, but
> doesn't push them. I've corrected that now.

Ah, that explains it even better.


>> Well, IMNSHO, just being available under an open source license *if
>> asked for*, should be well below where a reasonable bar would be put
>> for this.
>
> Maybe, but that's a different discussion. By your own admission you've
> been well aware that we made the installers available under an OSS
> licence in this way for a long time which implies consent, casual
> discussion about improving the push frequency aside - as is the norm
> in community matters. You certainly haven't nudged me about this, or
> made me aware (until now) that you consider it to be a high priority.

I have said many times that I don't consider it open enough if it's
only published "every now and then". Mainly in discussions about
*other* products, of course, but in this relation as well. And I have
said that it's a problem referring people to a repository that's not
up to date when they ask for how things are built and/or intended to
work.


>> But in treating people the same - I just asked Scottie to make sure
>> that they're not available just when asked for, but all the time. Can
>> you do the same?
>
> Sure, I'll bump it up the list and try to do it today. What do you
> consider more important, this or the CFP?

The cfp, for short term, since it's more time critical. If getting it
done properly is just on your list, that's good enough for me - since
clearly it wasn't on your list earlier, even though I thought it was.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Mon, Jul 9, 2012 at 11:22 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jul 9, 2012 at 12:13 PM, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Jul 9, 2012 at 10:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>
>>> So clearly there is something that doesn't work in this process.
>>
>> It works exactly as it always has. No, I haven't got round to
>> automating the pushes yet, largely because I've had 1001 other things
>> to do, the vast majority of which will benefit far more users and
>> community members in one way or another. I wasn't aware that you
>> considered this to be such a high priority item compared to all the
>> other tasks I have on my plate.
>
> Given that I don't know what else is on your plate (except for some
> tiny parts), that's kind of hard to state. I *have* asked for it for
> years...

Well, just things like my parts in PostgreSQL 9.2, pgAdmin 1.16,
PGConf.EU, pgFoundry etc. most of which I'm sure you're aware of. I
wouldn't call them tiny though, when totalled up.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 9 July 2012 10:44, Dave Page <dpage@pgadmin.org> wrote:

> It gets pushed periodically when I remember to do it (or someone
> reminds me), which I guess you've forgotten given that we've had this
> exact same discussion before.

That highlights a key flaw.

If we distribute RPMs then the SRPMs should exactly match. If they
don't, that's a pretty serious set of bugs we're introducing.

Can I suggest that the process be changed? Push the SRPM code, then
generate RPMs from the released SRPM code. That way there is no
opportunity to forget anything. This is a substantial security
concern, not just a forgotten task.

Perhaps it would be useful to have a "build farm" that builds the RPMs
from SRPMs automatically, then we will have no need for manually
updating the RPMs at all. (And I mean build all binaries from publicly
available build scripts).

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Jul 9, 2012 at 12:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 9 July 2012 10:44, Dave Page <dpage@pgadmin.org> wrote:
>
>> It gets pushed periodically when I remember to do it (or someone
>> reminds me), which I guess you've forgotten given that we've had this
>> exact same discussion before.
>
> That highlights a key flaw.
>
> If we distribute RPMs then the SRPMs should exactly match. If they
> don't, that's a pretty serious set of bugs we're introducing.
>
> Can I suggest that the process be changed? Push the SRPM code, then
> generate RPMs from the released SRPM code. That way there is no
> opportunity to forget anything. This is a substantial security
> concern, not just a forgotten task.
>
> Perhaps it would be useful to have a "build farm" that builds the RPMs
> from SRPMs automatically, then we will have no need for manually
> updating the RPMs at all. (And I mean build all binaries from publicly
> available build scripts).

We're not talking about RPMs here.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 1:21 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 12:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 9 July 2012 10:44, Dave Page <dpage@pgadmin.org> wrote:
>>
>>> It gets pushed periodically when I remember to do it (or someone
>>> reminds me), which I guess you've forgotten given that we've had this
>>> exact same discussion before.
>>
>> That highlights a key flaw.
>>
>> If we distribute RPMs then the SRPMs should exactly match. If they
>> don't, that's a pretty serious set of bugs we're introducing.
>>
>> Can I suggest that the process be changed? Push the SRPM code, then
>> generate RPMs from the released SRPM code. That way there is no
>> opportunity to forget anything. This is a substantial security
>> concern, not just a forgotten task.
>>
>> Perhaps it would be useful to have a "build farm" that builds the RPMs
>> from SRPMs automatically, then we will have no need for manually
>> updating the RPMs at all. (And I mean build all binaries from publicly
>> available build scripts).
>
> We're not talking about RPMs here.

FWIW, the RPMs already do this, I believe.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On 9 July 2012 12:21, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 12:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 9 July 2012 10:44, Dave Page <dpage@pgadmin.org> wrote:
>>
>>> It gets pushed periodically when I remember to do it (or someone
>>> reminds me), which I guess you've forgotten given that we've had this
>>> exact same discussion before.
>>
>> That highlights a key flaw.
>>
>> If we distribute RPMs then the SRPMs should exactly match. If they
>> don't, that's a pretty serious set of bugs we're introducing.
>>
>> Can I suggest that the process be changed? Push the SRPM code, then
>> generate RPMs from the released SRPM code. That way there is no
>> opportunity to forget anything. This is a substantial security
>> concern, not just a forgotten task.
>>
>> Perhaps it would be useful to have a "build farm" that builds the RPMs
>> from SRPMs automatically, then we will have no need for manually
>> updating the RPMs at all. (And I mean build all binaries from publicly
>> available build scripts).
>
> We're not talking about RPMs here.

I am discussing the relationship of SRPMs and RPMs, which is a valid
point on this thread given the point that the RPMs and SRPMs have been
mismatched for some time and that the current process calls for manual
rather than automatic synchronisation.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Jul 9, 2012 at 12:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 9 July 2012 12:21, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Jul 9, 2012 at 12:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On 9 July 2012 10:44, Dave Page <dpage@pgadmin.org> wrote:
>>>
>>>> It gets pushed periodically when I remember to do it (or someone
>>>> reminds me), which I guess you've forgotten given that we've had this
>>>> exact same discussion before.
>>>
>>> That highlights a key flaw.
>>>
>>> If we distribute RPMs then the SRPMs should exactly match. If they
>>> don't, that's a pretty serious set of bugs we're introducing.
>>>
>>> Can I suggest that the process be changed? Push the SRPM code, then
>>> generate RPMs from the released SRPM code. That way there is no
>>> opportunity to forget anything. This is a substantial security
>>> concern, not just a forgotten task.
>>>
>>> Perhaps it would be useful to have a "build farm" that builds the RPMs
>>> from SRPMs automatically, then we will have no need for manually
>>> updating the RPMs at all. (And I mean build all binaries from publicly
>>> available build scripts).
>>
>> We're not talking about RPMs here.
>
> I am discussing the relationship of SRPMs and RPMs, which is a valid
> point on this thread given the point that the RPMs and SRPMs have been
> mismatched for some time and that the current process calls for manual
> rather than automatic synchronisation.

I have no idea if that is true for the RPMs - as I said, we haven't
been discussing them.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi Simon,

On Mon, 2012-07-09 at 12:25 +0100, Simon Riggs wrote:

> I am discussing the relationship of SRPMs and RPMs, which is a valid
> point on this thread given the point that the RPMs and SRPMs have been
> mismatched for some time and that the current process calls for manual
> rather than automatic synchronisation.

Which SRPMs are you talking about? Community SRPMs? If so, they have
been always available on the website. If you are talking about OpenSCG
RPMs, that is a different thing.
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On 9 July 2012 12:31, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>
> Hi Simon,
>
> On Mon, 2012-07-09 at 12:25 +0100, Simon Riggs wrote:
>
>> I am discussing the relationship of SRPMs and RPMs, which is a valid
>> point on this thread given the point that the RPMs and SRPMs have been
>> mismatched for some time and that the current process calls for manual
>> rather than automatic synchronisation.
>
> Which SRPMs are you talking about? Community SRPMs? If so, they have
> been always available on the website. If you are talking about OpenSCG
> RPMs, that is a different thing.

My words were a little unclear all round, please accept my apologies.

IMHO we should only list binaries on the postgresql.org website if
they are derived from build information that is owned by the PGDG, or
at very least publicly available at the time of the build and likely
to remain so afterwards. That process should be automatic as far as
possible, to minimise error, since the number of users of those
binaries is now very large.

Unverifiable binaries are a quality and security risk to the project.

Companies are welcome to provide value-added binaries to their
customers if they choose to do so but that should be a private matter.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Jul 9, 2012 at 12:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 9 July 2012 12:31, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>>
>> Hi Simon,
>>
>> On Mon, 2012-07-09 at 12:25 +0100, Simon Riggs wrote:
>>
>>> I am discussing the relationship of SRPMs and RPMs, which is a valid
>>> point on this thread given the point that the RPMs and SRPMs have been
>>> mismatched for some time and that the current process calls for manual
>>> rather than automatic synchronisation.
>>
>> Which SRPMs are you talking about? Community SRPMs? If so, they have
>> been always available on the website. If you are talking about OpenSCG
>> RPMs, that is a different thing.
>
> My words were a little unclear all round, please accept my apologies.
>
> IMHO we should only list binaries on the postgresql.org website if
> they are derived from build information that is owned by the PGDG, or
> at very least publicly available at the time of the build and likely
> to remain so afterwards. That process should be automatic as far as
> possible, to minimise error, since the number of users of those
> binaries is now very large.

Right - that's more or less what's been discussed and agreed. The
issue with the installers that Magnus raised, is that at present I
manually push the canonical GIT repo to git.postgresql.org, and often
forget to do it until reminded. That was raised in response to my
comment that the OpenSCG build scripts are not currently public at all
as far as I could see, and should be if their work is to be listed on
postgresql.org's primary downloads page.

> Unverifiable binaries are a quality and security risk to the project.

In theory. In practice it seems unlikely anyone would ever take the
time and energy to build them themselves and actually verify them -
the effort to do so would be huge (for example, assembling the 9.2
build machine for the installers and building all the necessary
dependencies for all the supported platforms etc. has so far taken a
number of man weeks). To verify the binaries we put out, someone would
have to build an exact mirror of that environment. That's not to say
it shouldn't be possible of course. In fact, it wouldn't even be
possible, as we digitally sign some of the executables to appease
Windows, and we obviously cannot share that certificate.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi

On Mon, 2012-07-09 at 12:41 +0100, Simon Riggs wrote:

> IMHO we should only list binaries on the postgresql.org website if
> they are derived from build information that is owned by the PGDG, or
> at very least publicly available at the time of the build and likely
> to remain so afterwards.

I agree with this.

> That process should be automatic as far as possible, to minimise
> error, since the number of users of those binaries is now very large.

*Community RPMs* are more or less automated: There are some steps that
has to be done manually: Updating spec files, signing RPMs, performing
QA and then pushing to the repositories. Currently, when we build an
RPM, it passes through 3 separate tubes until it reaches final position.
We do the QA on first two tubes, since the last rsync is just a mirror
of the staging repository.

> Unverifiable binaries are a quality and security risk to the project.

Agreed -- and that is what me, Dave, etc., also think.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Mon, Jul 9, 2012 at 2:05 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 12:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 9 July 2012 12:31, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Mon, 2012-07-09 at 12:25 +0100, Simon Riggs wrote:
>>>
>>>> I am discussing the relationship of SRPMs and RPMs, which is a valid
>>>> point on this thread given the point that the RPMs and SRPMs have been
>>>> mismatched for some time and that the current process calls for manual
>>>> rather than automatic synchronisation.
>>>
>>> Which SRPMs are you talking about? Community SRPMs? If so, they have
>>> been always available on the website. If you are talking about OpenSCG
>>> RPMs, that is a different thing.
>>
>> My words were a little unclear all round, please accept my apologies.
>>
>> IMHO we should only list binaries on the postgresql.org website if
>> they are derived from build information that is owned by the PGDG, or
>> at very least publicly available at the time of the build and likely
>> to remain so afterwards. That process should be automatic as far as
>> possible, to minimise error, since the number of users of those
>> binaries is now very large.
>
> Right - that's more or less what's been discussed and agreed. The
> issue with the installers that Magnus raised, is that at present I
> manually push the canonical GIT repo to git.postgresql.org, and often
> forget to do it until reminded. That was raised in response to my
> comment that the OpenSCG build scripts are not currently public at all
> as far as I could see, and should be if their work is to be listed on
> postgresql.org's primary downloads page.

FWIW, the listing they have *now* is cleraly under "third party
distributions", so I don't think there's a problem with that one. It
also holds bitnami stuff. The point here is the *primary* download
pages (i'll make that plural since it was broken up a bit extra
lately).


>> Unverifiable binaries are a quality and security risk to the project.
>
> In theory. In practice it seems unlikely anyone would ever take the
> time and energy to build them themselves and actually verify them -
> the effort to do so would be huge (for example, assembling the 9.2
> build machine for the installers and building all the necessary
> dependencies for all the supported platforms etc. has so far taken a
> number of man weeks). To verify the binaries we put out, someone would
> have to build an exact mirror of that environment. That's not to say
> it shouldn't be possible of course. In fact, it wouldn't even be
> possible, as we digitally sign some of the executables to appease
> Windows, and we obviously cannot share that certificate.

It should be possible, and it's a much smaller (though not necessarily
small) effort if you only want to verify *one* version on *one*
platform with *one* subset of modules.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

Hi

On Mon, 2012-07-09 at 12:41 +0100, Simon Riggs wrote:

> IMHO we should only list binaries on the postgresql.org website if
> they are derived from build information that is owned by the PGDG, or
> at very least publicly available at the time of the build and likely
> to remain so afterwards.

I agree with this.

> That process should be automatic as far as possible, to minimise
> error, since the number of users of those binaries is now very large.

*Community RPMs* are more or less automated: There are some steps that
has to be done manually: Updating spec files, signing RPMs, performing
QA and then pushing to the repositories. Currently, when we build an
RPM, it passes through 3 separate tubes until it reaches final position.
We do the QA on first two tubes, since the last rsync is just a mirror
of the staging repository.

> Unverifiable binaries are a quality and security risk to the project.

Agreed -- and that is what me, Dave, etc., also think.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Mon, Jul 9, 2012 at 1:10 PM, Magnus Hagander <magnus@hagander.net> wrote:
>
>> In theory. In practice it seems unlikely anyone would ever take the
>> time and energy to build them themselves and actually verify them -
>> the effort to do so would be huge (for example, assembling the 9.2
>> build machine for the installers and building all the necessary
>> dependencies for all the supported platforms etc. has so far taken a
>> number of man weeks). To verify the binaries we put out, someone would
>> have to build an exact mirror of that environment. That's not to say
>> it shouldn't be possible of course. In fact, it wouldn't even be
>> possible, as we digitally sign some of the executables to appease
>> Windows, and we obviously cannot share that certificate.
>
> It should be possible, and it's a much smaller (though not necessarily
> small) effort if you only want to verify *one* version on *one*
> platform with *one* subset of modules.

Putting aside the signed binaries, which clearly cannot be reproduced
bit-perfect, it's really not that much smaller - versions don't matter
that much as we use the same env for each major version, and most
packages are dependent on the server build, which requires the
majority of dependencies. The only real time saver would be to only
try to reproduce a subset of the supported platforms.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 11:22 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
>>> But in treating people the same - I just asked Scottie to make sure
>>> that they're not available just when asked for, but all the time. Can
>>> you do the same?
>>
>> Sure, I'll bump it up the list and try to do it today. What do you
>> consider more important, this or the CFP?
>
> The cfp, for short term, since it's more time critical. If getting it
> done properly is just on your list, that's good enough for me - since
> clearly it wasn't on your list earlier, even though I thought it was.

After much arguing with ssh, this is now automated, and pushing every
5 minutes to git.postgresql.org. The CFP reminder also went out as you
probably noticed.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 6:14 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Jul 9, 2012 at 11:22 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>
>>>> But in treating people the same - I just asked Scottie to make sure
>>>> that they're not available just when asked for, but all the time. Can
>>>> you do the same?
>>>
>>> Sure, I'll bump it up the list and try to do it today. What do you
>>> consider more important, this or the CFP?
>>
>> The cfp, for short term, since it's more time critical. If getting it
>> done properly is just on your list, that's good enough for me - since
>> clearly it wasn't on your list earlier, even though I thought it was.
>
> After much arguing with ssh, this is now automated, and pushing every
> 5 minutes to git.postgresql.org. The CFP reminder also went out as you
> probably noticed.

Yup, thanks.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Mon, Jul  9, 2012 at 11:13:18AM +0100, Dave Page wrote:
> On Mon, Jul 9, 2012 at 10:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
> >
> > We have had the discussion before, and I was pretty sure it ended up
> > in "yes, it should be fixed". But it doesn't change the fact that the
> > repository claimed there had been no changes for *7 months*, certainly
> > not 3 days. Which also agrees very well with the logs on
> > git.postgresql.org.
> 
> I'm not disputing that, and never have.
> 
> > So clearly there is something that doesn't work in this process.
> 
> It works exactly as it always has. No, I haven't got round to
> automating the pushes yet, largely because I've had 1001 other things
> to do, the vast majority of which will benefit far more users and
> community members in one way or another. I wasn't aware that you
> considered this to be such a high priority item compared to all the
> other tasks I have on my plate.

I believe the significant point is that should Dave, EnterpriseDB, etc.
disappear tomorrow, the community _must_ have the instructions available
to continue producing binary releases.  "Asking for updated
instructions" is obviously impossible if those people/entities
disappear, so having current instructions always publicly available is a
requirement.

My point is that this not something that gets mixed in with other things
someone does for the community --- it is a requirement, and if it can't
be guaranteed, the community needs to rethink these binaries.  I am fine
with people forgetting stuff, but when someone says it is on my list of
other things I do --- that is unacceptable.

As I understand it now, the system is automated so the instructions will
always be current, right?  Are there any other "primary"
(non-thrird-party) downloads on our website that don't have current
build instructions?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Mon, Jul  9, 2012 at 10:30:12AM -0400, Scott Mead wrote:
>     > Given that the whole idea of the redesign is to help people figure out
>     > why they should choose the different options, can you provide a patch
>     > to that page that actually includes a good description of *why* these
>     > would be preferable to the standard RPMs?
> 
>     Absolutely, I'm boarding a flight now, but will work on it once I hit
>     10,000 ft.
> 
> PFA a patch for the linux download pages 

> They are designed for production server installation where a GUI is not
> available and consistency across multiple distributions is a
> requirement.

What installers require a GUI?  I thought the EnterpriseDB installers
have a no-gui option?  Do you mean they include no GUI binaries like
PGAdmin?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Mon, Jul 9, 2012 at 6:47 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> As I understand it now, the system is automated so the instructions will
> always be current, right?  Are there any other "primary"
> (non-thrird-party) downloads on our website that don't have current
> build instructions?

Pretty much all of them I believe. I *think* Devrim has documented the
RPM build process, but I've never seen anything for Debian/Ubuntu, or
FreeBSD or Solaris etc. Of course, some of them are built in the same
way as any other package on their platform which makes them somewhat
easier to deal with.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul 9, 2012 at 6:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Jul  9, 2012 at 10:30:12AM -0400, Scott Mead wrote:
>>     > Given that the whole idea of the redesign is to help people figure out
>>     > why they should choose the different options, can you provide a patch
>>     > to that page that actually includes a good description of *why* these
>>     > would be preferable to the standard RPMs?
>>
>>     Absolutely, I'm boarding a flight now, but will work on it once I hit
>>     10,000 ft.
>>
>> PFA a patch for the linux download pages
>
>> They are designed for production server installation where a GUI is not
>> available and consistency across multiple distributions is a
>> requirement.
>
> What installers require a GUI?  I thought the EnterpriseDB installers
> have a no-gui option?

They do. They have silent and command line modes, and can be
controlled interactively in the shell or GUI, from the command line,
or using response files.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jul  9, 2012 at 06:54:21PM +0100, Dave Page wrote:
> On Mon, Jul 9, 2012 at 6:47 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > As I understand it now, the system is automated so the instructions will
> > always be current, right?  Are there any other "primary"
> > (non-thrird-party) downloads on our website that don't have current
> > build instructions?
> 
> Pretty much all of them I believe. I *think* Devrim has documented the
> RPM build process, but I've never seen anything for Debian/Ubuntu, or
> FreeBSD or Solaris etc. Of course, some of them are built in the same
> way as any other package on their platform which makes them somewhat
> easier to deal with.

Agreed.  Someday we might want to actually test to see that these can be
built by a new person, but that seems overkill at this point.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On 9 July 2012 18:47, Bruce Momjian <bruce@momjian.us> wrote:

> I believe the significant point is that should Dave, EnterpriseDB, etc.
> disappear tomorrow, the community _must_ have the instructions available
> to continue producing binary releases.  "Asking for updated
> instructions" is obviously impossible if those people/entities
> disappear, so having current instructions always publicly available is a
> requirement.

+1

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On Tue, Jul 10, 2012 at 3:25 PM, Scott Mead <scottm@openscg.com> wrote:
>
>
>   1) A no-gui option
>     The bitrock installers do have this, but at times, the technology isn't
> perfect.  Many times, people want to just run a command and have it install.
> The idea with an RPM of these binaries is that we get the benefit of the
> same binaries across installers, AND lower the barrier to entry by making
> rpm -ivh ... just work.

No technology is perfect, but we have numerous users utilising text,
silent and response file installations quite successfully, including
all the additional post-copy steps the installers undertake. We also
have an unpack mode which is much more like an RPM install in that it
just lays down the binaries. Simply put, you can just run a command
and have it install.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Jul 10, 2012 at 03:39:54PM +0100, Dave Page wrote:
> On Tue, Jul 10, 2012 at 3:25 PM, Scott Mead <scottm@openscg.com> wrote:
> >
> >
> >   1) A no-gui option
> >     The bitrock installers do have this, but at times, the technology isn't
> > perfect.  Many times, people want to just run a command and have it install.
> > The idea with an RPM of these binaries is that we get the benefit of the
> > same binaries across installers, AND lower the barrier to entry by making
> > rpm -ivh ... just work.
> 
> No technology is perfect, but we have numerous users utilising text,
> silent and response file installations quite successfully, including
> all the additional post-copy steps the installers undertake. We also
> have an unpack mode which is much more like an RPM install in that it
> just lays down the binaries. Simply put, you can just run a command
> and have it install.

Agreed.  If the non-GUI mode of the Bitrock installers is broken, please
report it and let's fix it.  If it can't be fixed, maybe we need to use
another installer, but it is not clear what is broken.  Are you saying
it is better for non-GUI installs because they don't need to supply a
flag for non-GUI mode?  Shouldn't we just document the flag better?

The smaller download does make sense --- it is a leaner install.

I wonder if the OpenSCG text should more clearly state is doesn't
include any GUI componients.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Tue, Jul 10, 2012 at 4:25 PM, Scott Mead <scottm@openscg.com> wrote:
>
> On Mon, Jul 9, 2012 at 1:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> On Mon, Jul  9, 2012 at 10:30:12AM -0400, Scott Mead wrote:
>> >     > Given that the whole idea of the redesign is to help people figure
>> > out
>> >     > why they should choose the different options, can you provide a
>> > patch
>> >     > to that page that actually includes a good description of *why*
>> > these
>> >     > would be preferable to the standard RPMs?
>> >
>> >     Absolutely, I'm boarding a flight now, but will work on it once I
>> > hit
>> >     10,000 ft.
>> >
>> > PFA a patch for the linux download pages
>>
>> > They are designed for production server installation where a GUI is not
>> > available and consistency across multiple distributions is a
>> > requirement.
>>
>> What installers require a GUI?  I thought the EnterpriseDB installers
>> have a no-gui option?  Do you mean they include no GUI binaries like
>> PGAdmin?
>
>
> Two things specifically:
>
>   1) A no-gui option
>     The bitrock installers do have this, but at times, the technology isn't
> perfect.  Many times, people want to just run a command and have it install.
> The idea with an RPM of these binaries is that we get the benefit of the
> same binaries across installers, AND lower the barrier to entry by making
> rpm -ivh ... just work.
>
>   2) no GUI binaries
>      This package is a 'server-only' install.  Same binaries, smaller
> download size, quick and simple install / start / up and running.

So it's the binaries that come out of the EnterpriseDB installers? In
that case, it should at the very least reproduce the warnings we have
about those not integrating with the local packaging system (which I
realize *is* the point of them, but that should be stated more
clearly).

And I still don't really understand why you'd *want* this over the EDB
installers, but that's being discussed elsewhere in the thread, so I'm
not going to restart it here.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Tue, Jul 10, 2012 at 5:45 PM, Scott Mead <scottm@openscg.com> wrote:
> On Tue, Jul 10, 2012 at 10:47 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> On Tue, Jul 10, 2012 at 03:39:54PM +0100, Dave Page wrote:
>> > On Tue, Jul 10, 2012 at 3:25 PM, Scott Mead <scottm@openscg.com> wrote:
>> > >
>> > >
>> > >   1) A no-gui option
>> > >     The bitrock installers do have this, but at times, the technology
>> > > isn't
>> > > perfect.  Many times, people want to just run a command and have it
>> > > install.
>> > > The idea with an RPM of these binaries is that we get the benefit of
>> > > the
>> > > same binaries across installers, AND lower the barrier to entry by
>> > > making
>> > > rpm -ivh ... just work.
>> >
>> > No technology is perfect, but we have numerous users utilising text,
>> > silent and response file installations quite successfully, including
>> > all the additional post-copy steps the installers undertake. We also
>> > have an unpack mode which is much more like an RPM install in that it
>> > just lays down the binaries. Simply put, you can just run a command
>> > and have it install.
>>
>> Agreed.  If the non-GUI mode of the Bitrock installers is broken, please
>> report it and let's fix it.  If it can't be fixed, maybe we need to use
>> another installer, but it is not clear what is broken.  Are you saying
>> it is better for non-GUI installs because they don't need to supply a
>> flag for non-GUI mode?  Shouldn't we just document the flag better?
>
>
> Sorry I'm not being clear here (I've switched timezones just yesterday ).
> I'm not saying that it's broken, just that, from a 'barriers' perspective,
> many customers end up building their own server-only RPM.  They need
> something that is consistent across the many disparate linux distro's (and
> even just versions of the same distro) that they are running.
>
> Some people do it to distribute through their own repository, some just
> don't want to stay beholden to the linux distro's themselves.  Others just
> need a consistent directory structure across distributions so that their
> teams have one less thing to worry about.  The community yum repository and
> binaries are a great thing, and in shops where linux the distributions are
> consistent and version-ing is well managed, I would recommend them every
> time.  The generic RPM option let's us fill a gap between the two; when it
> comes to Small-Mid enterprise, it's very hard to stay consistent across all
> distributions all the time while still making budget and timelines.  The
> generic RPM/DEB allows for that middle-ground and lowers barriers in
> mid-sized enterprises that haven't completely gotten their head around all
> the different aspects of internal distribution.
>
>>
>>
>> The smaller download does make sense --- it is a leaner install.
>>
>> I wonder if the OpenSCG text should more clearly state is doesn't
>> include any GUI componients.
>
>
> Patch attached.

I noticed two quick things: according to the page, you provide RPMs
for RedHat and SuSE (per the logos - I assume Fedora is included in
the RedHat part), and DEBs for Ubuntu.

Why do the patches suggest adding it to Debian (not listed) and to "other"?

I also for the first time clicked one of those links. To me, the way
that those pages request a login and registratoin to download them is
completely unacceptable. Yes, I realize there is a "there's a download
link at the bottom if you don't want to" (or as you like to phrase it,
"feel anti-social", which is clearly designed to make people sign up).
But I don't think that's acceptable for something to be listed on our
primary download pages. I'm ok (but not with a big margin) with how
EnterpriseDB does it - which is that they deliver your download and
*then* suggest you register as well. (Actually, I see now that they
have stopped doing that completely and instead throw some marketing
and ads for their cloud product at you)

I'd like to see that fixed for the developer bundles as well.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On 9 July 2012 13:05, Dave Page <dpage@pgadmin.org> wrote:

> Right - that's more or less what's been discussed and agreed. The
> issue with the installers that Magnus raised, is that at present I
> manually push the canonical GIT repo to git.postgresql.org, and often
> forget to do it until reminded. That was raised in response to my
> comment that the OpenSCG build scripts are not currently public at all
> as far as I could see, and should be if their work is to be listed on
> postgresql.org's primary downloads page.

It's not more or less. What you have said is not the same thing as I
have requested.

If it was done as I suggest, when you forget a step in the process
then the process would fail.

If you build from the public repo then you simply can't forget.


>> Unverifiable binaries are a quality and security risk to the project.
>
> In theory. In practice it seems unlikely anyone would ever take the
> time and energy to build them themselves and actually verify them -
> the effort to do so would be huge (for example, assembling the 9.2
> build machine for the installers and building all the necessary
> dependencies for all the supported platforms etc. has so far taken a
> number of man weeks). To verify the binaries we put out, someone would
> have to build an exact mirror of that environment. That's not to say
> it shouldn't be possible of course. In fact, it wouldn't even be
> possible, as we digitally sign some of the executables to appease
> Windows, and we obviously cannot share that certificate.

I know multiple users (aside from 2ndQuadrant) that re-build their own
binaries as a safety barrier in their release process, so I don't
believe the effort level is that high, nor do I believe people won't
do it. I take your point that it is maybe only 1% of people, but those
are the ones that report all the bugs.

The most important thing is that people can see the ingredients before
they eat the food.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On Mon, Jul 9, 2012 at 3:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 9 July 2012 13:05, Dave Page <dpage@pgadmin.org> wrote:
>
>> Right - that's more or less what's been discussed and agreed. The
>> issue with the installers that Magnus raised, is that at present I
>> manually push the canonical GIT repo to git.postgresql.org, and often
>> forget to do it until reminded. That was raised in response to my
>> comment that the OpenSCG build scripts are not currently public at all
>> as far as I could see, and should be if their work is to be listed on
>> postgresql.org's primary downloads page.
>
> It's not more or less. What you have said is not the same thing as I
> have requested.
>
> If it was done as I suggest, when you forget a step in the process
> then the process would fail.
>
> If you build from the public repo then you simply can't forget.

The security issue you quote is precisely why we built from the
canonical source, and not a secondary mirror.

You also wouldn't see a failure as you suggest - you'd probably see a
successful build that you later discover is missing recent bug fixes.

>>> Unverifiable binaries are a quality and security risk to the project.
>>
>> In theory. In practice it seems unlikely anyone would ever take the
>> time and energy to build them themselves and actually verify them -
>> the effort to do so would be huge (for example, assembling the 9.2
>> build machine for the installers and building all the necessary
>> dependencies for all the supported platforms etc. has so far taken a
>> number of man weeks). To verify the binaries we put out, someone would
>> have to build an exact mirror of that environment. That's not to say
>> it shouldn't be possible of course. In fact, it wouldn't even be
>> possible, as we digitally sign some of the executables to appease
>> Windows, and we obviously cannot share that certificate.
>
> I know multiple users (aside from 2ndQuadrant) that re-build their own
> binaries as a safety barrier in their release process, so I don't
> believe the effort level is that high, nor do I believe people won't
> do it. I take your point that it is maybe only 1% of people, but those
> are the ones that report all the bugs.

Well if you believe it's that easy, then I'd suggest you try for
yourself. Building the installers is *not* trivial, and building the
installers with an identical dependency tree to verify everything
we've built is a huge undertaking - and as I mentioned, not actually
possible on Windows because you would have no way to sign the binaries
you create with our certificate.

Note again though that we're talking *installers* here, and not RPMs
or other types of packages. The installers are *very* different from
other packages because we have to build so many of the dependencies
ourselves to ensure they'll run successfully on all the supported
platforms.

> The most important thing is that people can see the ingredients before
> they eat the food.

You're welcome to see the code - it's on git.postgresql.org. But that
doesn't mean it would be easy to build a bit-level verifiable copy of
our binaries.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Aug  3, 2012 at 04:08:18PM -0400, Scott Mead wrote:
>     I'll update our site and get back to you.
>      
> 
> 
>         I also for the first time clicked one of those links. To me, the way
>         that those pages request a login and registratoin to download them is
>         completely unacceptable. Yes, I realize there is a "there's a download
>         link at the bottom if you don't want to" (or as you like to phrase it,
>         "feel anti-social", which is clearly designed to make people sign up).
>         But I don't think that's acceptable for something to be listed on our
>         primary download pages. I'm ok (but not with a big margin) with how
>         EnterpriseDB does it - which is that they deliver your download and
>         *then* suggest you register as well. (Actually, I see now that they
>         have stopped doing that completely and instead throw some marketing
>         and ads for their cloud product at you)
> 
> 
>     Okay, we'll talk about this internally, but I'm thinking that we'll
>     probably kick the download off and then leave a register page up
>     underneath.
> 
> 
> It took a while, but we updated the downloads that are launched from:
> http://www.openscg.com/se/postgresql/packages.jsp
> 
> Once you drill into a platform, it will launch the download, and leave the
> registration page up underneath.

I just clicked on:
http://www.openscg.com/se/oscg_download.jsp?file=packages/postgres_9.1.4-1.i386.openscg.deb&user=

and my download did _not_ start automatically.  The "click here" link
does work.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Fri, Aug  3, 2012 at 05:14:30PM -0400, Scott Mead wrote:
>     I just clicked on:
> 
>             http://www.openscg.com/se/oscg_download.jsp?file=packages/
>     postgres_9.1.4-1.i386.openscg.deb&user=
> 
>     and my download did _not_ start automatically.  The "click here" link
>     does work.
> 
> 
> Eek, missed a comment! 
> 
>   All fixed now, thanks Bruce.

I can confirm it worked.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Mon, Aug 6, 2012 at 9:06 PM, Scott Mead <scottm@openscg.com> wrote:
>
> On Fri, Aug 3, 2012 at 6:23 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> On Fri, Aug  3, 2012 at 05:14:30PM -0400, Scott Mead wrote:
>> >     I just clicked on:
>> >
>> >             http://www.openscg.com/se/oscg_download.jsp?file=packages/
>> >     postgres_9.1.4-1.i386.openscg.deb&user=
>> >
>> >     and my download did _not_ start automatically.  The "click here"
>> > link
>> >     does work.
>> >
>> >
>> > Eek, missed a comment!
>> >
>> >   All fixed now, thanks Bruce.
>>
>> I can confirm it worked.
>
>
> Magnus, Any thoughts?

Hi!

Sorry for the delay - I was away for 3 weeks of vacatoin, and have
been working my way through the email backlog.

Those download pages look fine to me, and I'll work on integrating the
links to the download site today.

Thanks for dealing with our complaints :)

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/